[ANN] Spondoolies-Tech - carrier grade, data center ready mining rigs

[jtoomim]

Two of my new SP-30's are not going over 2TH for some reason. I have spoke to my hosting in Michagan and he says this seems to be an issue with many of the SP30's they've received. Are SP looking into this issue? We are losing out on the mining.

First, check the PSUs. Do a long power cycle (remove power for 30 seconds, plug back in). If one of the Emerson PSUs has a flashing green or flashing orange light consistently, then it needs to be replaced. If you have Murata PSUs, then I don't know offhand what the failure mode LED pattern is, but it's probably similar. If it's consistently one board that's not starting up, and you suspect the PSU is the problem (e.g. if you see "Board not present" messages in the event log), then you can try swapping the top and bottom PSUs with each other to see if the problem follows the PSUs or if the problem stays with the board.

If the temperature is low, then the DC2DC converters might be suffering from the temp underflow bug and falsely reporting a temperature around 250°C. Take a look at the ASIC stats page and look at the number on each line before  "] ASIC:[". If any are above 240c, read https://bitcointalk.org/index.php?topic=521520.msg9158199#msg9158199.

Occasionally, a machine will have a bad loop or ASIC that causes the whole board to malfunction. You can often rescue these machines by marking the ASIC as disabled or (in the 2.4 firmware series) marking all three ASICs in the affected loop as removed. You can sometimes find out which ASIC or loop is the problem by reading the events log closely (usually the stuff near the bottom, which is the output of miner_gate_arm) or by watching the ASIC stats screen closely. If that isn't informative, then the other strategy is to simply mark everything but one loop as "removed", and test the machine. If it hashes stably (but slowly) for a few minutes, then try enabling another loop, and another, and another, until you find the one that causes problems. Mark that one loop as removed and then go through the rest. After you've finished identifying the fully-functional loops, you can try enabling one ASIC at a time within the bad loop (make sure to mark the other ASICs as disabled if they're not enabled; only mark an ASIC as removed if you're doing that to all three within one loop).

While the vast majority of SP30s we've received have worked fine, here at http://toom.im we've had quite a few SP30s with problems of some sort or another. We've been able to get almost all of them hashing at 4.0-4.4 TH/s by identifying the problematic ASICs and loops and disabling them.

[1714122014]

1714122014

[1714122014]

1714122014

[rammy2k2]

is local pickup an option ?

[wh00per]

The SP30 firmware has a bug which stops them currently reporting the correct speed, however SP-tech are aware of this and it is planned to be patched soon.  That is why my SP30's may look a little slow (1Th/s)

Wishful thinking. I hope it gets patched tho' .. again, reading the info via CGminer API is nice, but you need to open the API to the local network. Then, if hosted, you have to make sure no one switches your pools from your accounts to theirs with it ..  You can read more from SP30 than from the average cgminer rig ::>> http://powerprice.info/SPT/graphic.php

[nwoolls]

reading the info via CGminer API is nice, but you need to open the API to the local network. Then, if hosted, you have to make sure no one switches your pools from your accounts to theirs with it .

You can open the RPC API in CGMiner and BFGMiner to a single IP or only the local IP. There's no need to open it up to the entire network. In addition, you can specify which IPs and IP ranges are actually allowed write-access (for things like changing pools).

[Minor Miner]

has anyone had problems where the miners just seem to shut down in the graphs and then become erratic and then seem to recover but only to about 3,200 GH/s until you reboot them?   We have about 12 that are real pains in the butt whereas the majority are very stable (or have become stable over the last couple weeks after changing settings.   
Also, we are running 208V so we are setting at 1300 / 1300 as we were told but notice that the many have 1330 /1330 even though we have set them back to 1300 /1300.

have also noticed some variability in power draw (two to a breaker (208V 30 AMP)) trips every now and then on some machines.  (208V 30 AMP plugs are cutting it close but 6kW / 7.2kW leaves enough not to trip usually).   I expected we would be lower than this since we set the max's at 1300 / 1300.

In general would have to say I am again impressed in the equipment though.   Just like the SP10s, get them stable and forget about them.   Kind of like where the Jupiters got to after months of tweaking (painful tweaking and painful RMAs for bad boards and melted plugs)....     Definitely blow away the cointerras.

[HeadsOrTails]

Can you tell me why this is self moderated?

[Bicknellski]

Can you tell me why this is self moderated?

Yet rarely actually moderated.

One of the few that doesn't remove customers complaints.

Given the spam that often occurs in these forums it is really mandatory for fabricators to set up a moderated thread.

It is not an indicator of a scam or trying to bend the discussion away from problems in this thread.

[Guy Corem]

... We have about 12 that are real pains in the butt whereas the majority are very stable ...

Please contact support@ on Sunday (after our last holiday weekend). Set remote ssh and https access in advance. Remo will take a look.

[Guy Corem]

Can you tell me why this is self moderated?

The only posts I removed (total of about 3 posts) are completely off topic posts, usually political in nature. This is done only after fair warning.
I do report to moderators some other extremely trolling posts, but I don't remove them. The moderators may, but usually don't.

Guy

[Collider]

is local pickup an option ?

You would need to pay VAT then  

The shipping rates are very fair in my opinion, FedEx shipping from Israel to US takes only around 48hours, and for 300$ on a 19kg package, it is provided at cost.

Nobody makes money on shipping nowadays.

[QuiveringGibbage]

...

Occasionally, a machine will have a bad loop or ASIC that causes the whole board to malfunction. You can often rescue these machines by marking the ASIC as disabled or (in the 2.4 firmware series) marking all three ASICs in the affected loop as removed. You can sometimes find out which ASIC or loop is the problem by reading the events log closely (usually the stuff near the bottom, which is the output of miner_gate_arm) or by watching the ASIC stats screen closely. If that isn't informative, then the other strategy is to simply mark everything but one loop as "removed", and test the machine. If it hashes stably (but slowly) for a few minutes, then try enabling another loop, and another, and another, until you find the one that causes problems. Mark that one loop as removed and then go through the rest. After you've finished identifying the fully-functional loops, you can try enabling one ASIC at a time within the bad loop (make sure to mark the other ASICs as disabled if they're not enabled; only mark an ASIC as removed if you're doing that to all three within one loop).

...

ah!! i just started doing this, i c i am on the right track. but I've only just Disabled the asic, not set to Removed. Is it necessary to set to Removed (for the whole loop)? and is only a few min.s enough to test each loop? i've been testing each for ~40mins.

Cheers,
QG

[RoadStress]

ah!! i just started doing this, i c i am on the right track. but I've only just Disabled the asic, not set to Removed. Is it necessary to set to Removed (for the whole loop)? and is only a few min.s enough to test each loop? i've been testing each for ~40mins.

Cheers,
QG

I have read that you don't use the Removed option. Only if the physical chip has been extracted. Use Disable!

[-ck]

Binary built from the latest git cgminer for the sp30 for testing:

http://ck.kolivas.org/apps/cgminer/sp30/141016/cgminer

There are some minor changes to improve CPU usage which should help when you first connect to pools that start from a low diff, and if you're reading the hashrate from the cgminer API, it's now share based instead of work based. The web interface will NOT display anything differently since it doesn't display hashrate by the cgminer API (yet?). This might help you pick up when one board stops producing shares, and you're only submitting half the hashrate, but the web interface still shows everything normal.

ssh into your machine and copy the file into /etc/bin to replace the existing binary to try it and chmod +x to make it executable.

I believe the storage space there isn't permanent so if you reboot it will restore the old binary, but just in case, backup your old one.

EDIT: Instructions for copying to it assumed you had wget which it doesn't. Use something like scp or rsync on linux or winscp on windows to overwrite the old binary. Then kill cgminer via the command line. (The watchdog will automatically restart cgminer for you)

Assuming all goes well and the spondoolies team like the changes, they should be incorporated into new firmware, and ideally the web interface will be changed to use the API's hashrate meter too.

[wh00per]

ckolivas: Besides the low average hash rates being reported by CGminer 2.6.0 on the SP30 (about 1Gh/s), there is/was an issue with the pools switch .. i.e. when "promoting" a pool via CGminer API, the ID of the pool should change too, together with the priority. I'm not sure if that's fixed now (i've seen some posts on the cgminer thread), however, with respect to the watchdog on the SP30, if the pool ID does not change when promoted, the CGminer gets restarted with the initial configuration mining on the 1st defined pool in the config file (ID 0). This whole setup renders the "promote pool" functionality unusable on the SP30. As a matter of fact, the code to change the pools is coded into the units but presently commented out. I have no issues with the watchdog restart, but CGminer should mine on the newly promoted pool after it happens.

You are correct, the /usr/bin is not persistent after reboot. However, the cgminer runs from /etc/bin which looks to be persistent !!!

[-ck]

You want cgminer to automatically save changes done on the fly to the pool configuration itself?...

[jtoomim]

ah!! i just started doing this, i c i am on the right track. but I've only just Disabled the asic, not set to Removed. Is it necessary to set to Removed (for the whole loop)? and is only a few min.s enough to test each loop? i've been testing each for ~40mins.

If all three ASICs in a loop are set to "Removed", then minergate will not attempt to initialize the DC2DC converters on that loop. Occasionally, there will be problems in that initialization process that can cause startup of minergate to fail if they're set to Disabled and not Removed. We've got a couple machines here that are that way. Usually Disabled is enough, though. Only use Removed if you're marking all three ASICs as Removed, as marking a single asic Removed instead of Disabled may cause issues, I think.

If you have a machine that shows problems within 5 minutes, then you don't need to test for 40 each time. A common problem results in the vlt1 values for all ASICs decreasing over time instead of increasing if one bad ASIC is enabled. You can often see if that's happening within 45 seconds.

[wh00per]

ckolivas: in short, yes ..

The cgminer api is used to add the pools in cgminer on the SP30, so we already use the API to modify the configuration when we define the pools. Presently the switchpool|N (*) API command (when called) changes only the pool priority. Can it change also the pool ID and update the cfg file accordingly?

Ex: There is no reply section just the STATUS section stating the results of switching pool N to the highest priority (the pool is also enabled) The Msg includes the pool URL.

[-ck]

ckolivas: in short, yes ..

The cgminer api is used to add the pools in cgminer on the SP30, so we already use the API to modify the configuration when we define the pools. Presently the switchpool|N (*) API command (when called) changes only the pool priority. Can it change also the pool ID and update the cfg file accordingly?

Ex: There is no reply section just the STATUS section stating the results of switching pool N to the highest priority (the pool is also enabled) The Msg includes the pool URL.

That would completely change the semantics of cgminer which has never written to/modified the config file without being expressly asked to. Sorry, no.

[wh00per]

Understood. Thanks for looking into it. If the switchpool|N will also change eventually the pool ID , I can issue an API command to rewrite/update the CFG file explicitly.
I guess I can modify the CFG file directly using a PHP script ..  was trying to avoid that though.

[RoadStress]

Assuming all goes well and the spondoolies team like the changes, they should be incorporated into new firmware, and ideally the web interface will be changed to use the API's hashrate meter too.

If this gets incorporated in the firmware does this mean that the miner will auto restart when only one board is hashing?