[GUIDE] GridSeed 5-Chip USB, Blade & Black Miner Support/Tuning

[unamis76]

No problem. Also, remember it is normal to see a number of HW errors while the autotune is ongoing. With the above script you can also see the individual chip frequencies it settles at and then set those via the command. That way you should see close to zero errors.

I haven't got autotune enabled anymore, autotune already finished and I'm using the frequencies it gave me. Already got the php working, at least kind of. The information appears a bit scattered and it gives me 700+ HW errors for some chips (30 showing up on cpuminer), I'm trying to see what I can do to make it display the info in a better, easier way to read...

[sandor111]

No problem. Also, remember it is normal to see a number of HW errors while the autotune is ongoing. With the above script you can also see the individual chip frequencies it settles at and then set those via the command. That way you should see close to zero errors.

I haven't got autotune enabled anymore, autotune already finished and I'm using the frequencies it gave me. Already got the php working, at least kind of. The information appears a bit scattered and it gives me 700+ HW errors for some chips (30 showing up on cpuminer), I'm trying to see what I can do to make it display the info in a better, easier way to read...

700 HW errors definitely isn't normal, the frequency is set waaaay too high.

[unamis76]

No problem. Also, remember it is normal to see a number of HW errors while the autotune is ongoing. With the above script you can also see the individual chip frequencies it settles at and then set those via the command. That way you should see close to zero errors.

I haven't got autotune enabled anymore, autotune already finished and I'm using the frequencies it gave me. Already got the php working, at least kind of. The information appears a bit scattered and it gives me 700+ HW errors for some chips (30 showing up on cpuminer), I'm trying to see what I can do to make it display the info in a better, easier way to read...

700 HW errors definitely isn't normal, the frequency is set waaaay too high.

This is the php for my gridseed cpuminer test unit:

stdClass Object ( [t] => 1399449980 [d] => stdClass Object ( [ttyACM0] => stdClass Object ( [c] => Array (

• => stdClass Object ( [fr] => 875 [ac] => 760 [hw] => 19 [re] => 2 [ha] => 72116 [sh] => 53320 [l] => 1399498805 ) [1] => stdClass Object ( [fr] => 875 [ac] => 768 [hw] => 0 [re] => 3 [ha] => 74060 [sh] => 53520 [l] => 1399498845 ) [2] => stdClass Object ( [fr] => 875 [ac] => 821 [hw] => 21 [re] => 1 [ha] => 72161 [sh] => 57432 [l] => 1399498827 ) [3] => stdClass Object ( [fr] => 825 [ac] => 771 [hw] => 0 [re] => 0 [ha] => 69816 [sh] => 54632 [l] => 1399498800 ) [4] => stdClass Object ( [fr] => 850 [ac] => 788 [hw] => 0 [re] => 2 [ha] => 71933 [sh] => 58288 [l] => 1399498831 ) ) ) ) [err] => 0 )

cpuminer reports 40 HW errors...

and still not finding a way to make it easier to read the php, am I missing anything?

PS: using frequencies given to me by autotune

[toxic0n]

I don't see 700 errors in there, some chips do have around 20

Code:

[hw] => 21

[unamis76]

I don't see 700 errors in there, some chips do have around 20

Code:

[hw] => 21

Thank you! Was reading this completely wrong. I can now see that my weakest chip isn't actually the one sending out hardware errors, as I suspected... Will try to tune these chips beyond autotune, and I guess I will finally move more units to cpuminer. Thanks again!

EDIT: updated cpuminer, let's see how it goes. Also trying to learn how to use JSON so I can update my test machine on the fly

[edonkey]

Is there a way to have cpuminer automatically find all of the Gridseed 5-chip devices rather than specify each one via the --gc3355=/dev option?

If you're on Linux, you can use this command:

Code:

minerd -o stratum+tcp://pool.com -u USERNAME -p PASSWORD --gc3355-autotune --gc3355=`ls -m /dev/ttyACM* | sed -e 's/, /,/g' | tr -d '\n'` --freq=1200

Thanks! I'm on a Raspberry Pi, so it's Linux.

But when I do the following command on my current GridSeed rig (running cgminer; haven't moved over to minerd yet), I get an error:

Code:

sudo ls -m /dev/ttyACM*
ls: cannot access /dev/ttyACM*: No such file or directory

But in checking the siklon/cpuminer-gc3355 read me on github it appears that cgminer is somehow responsible for preventing ttyUSB or ttyACM devices from being visible. I guess I need to quit cgminer and reboot in order to work around it. I'll try that on my test rig when I get home tonight.

But wouldn't it be a nice feature to have minerd just find all of the GSDs on its own? Maybe something like this syntax: "--gc3355=ALL". Seems like a natural compliment to the auto tune feature.

Also, the competition (like cgminer) finds all the units simply enough. And I think bfgminer supports a similar "ALL" syntax (although I could be misremembering).

[sandor111]

Is there a way to have cpuminer automatically find all of the Gridseed 5-chip devices rather than specify each one via the --gc3355=/dev option?

If you're on Linux, you can use this command:

Code:

minerd -o stratum+tcp://pool.com -u USERNAME -p PASSWORD --gc3355-autotune --gc3355=`ls -m /dev/ttyACM* | sed -e 's/, /,/g' | tr -d '\n'` --freq=1200

Thanks! I'm on a Raspberry Pi, so it's Linux.

But when I do the following command on my current GridSeed rig (running cgminer; haven't moved over to minerd yet), I get an error:

Code:

sudo ls -m /dev/ttyACM*
ls: cannot access /dev/ttyACM*: No such file or directory

But in checking the siklon/cpuminer-gc3355 read me on github it appears that cgminer is somehow responsible for preventing ttyUSB or ttyACM devices from being visible. I guess I need to quit cgminer and reboot in order to work around it. I'll try that on my test rig when I get home tonight.

But wouldn't it be a nice feature to have minerd just find all of the GSDs on its own? Maybe something like this syntax: "--gc3355=ALL". Seems like a natural compliment to the auto tune feature.

Also, the competition (like cgminer) finds all the units simply enough. And I think bfgminer supports a similar "ALL" syntax (although I could be misremembering).

This feature is just recently added, the command is --gc3355-detect.

[edonkey]

This feature is just recently added, the command is --gc3355-detect.

Awesome! That's great news.

I'm looking forward to trying out your latest version, and Minera.

Thanks for the great work!

[toxic0n]

I didn't want to do autotune every time the miner restarted and manually entering the values every time was tedious. For some reason, the device names changed after upgrading the miner version.
I wrote a little PHP script that will query all the frequencies for the chips and format them into a command string to use with cpuminer. Now I can just wait for the autotune to finish and then copy and paste the output into the command string.

Code:

<?php
if(!($fp = fsockopen("127.0.0.1", 4028, $errno, $errstr, 0)))
{
    echo("Failed to open socket");
}
stream_set_blocking($fp, false);
$out = json_encode(array("get" => "stats"))."\n";
fwrite($fp, $out);
usleep(100000);
$out = "";
while(!feof($fp))
{
    if(!($str = fgets($fp, 2048))) break;
    $out .= $str;
}
fclose($fp);
$arr = json_decode($out,true);

$cm_string = "--gc3355-freq=";
foreach(array_keys($arr['devices']) as $devices){

foreach(array_keys($arr['devices'][$devices]['chips']) as $chips){
$fr = $arr['devices'][$devices]['chips'][$chips]['frequency'];
$cm_string = $cm_string."/dev/".$devices.":".$fr.":".$chips.",";

}
}
echo rtrim($cm_string,",");

And the output:

Code:

--gc3355-freq=/dev/ttyACM0:875:0,/dev/ttyACM0:875:1,/dev/ttyACM0:850:2,/dev/ttyACM0:875:3,......etc

[edonkey]

I didn't want to do autotune every time the miner restarted and manually entering the values every time was tedious. For some reason, the device names changed after upgrading the miner version.
I wrote a little PHP script that will query all the frequencies for the chips and format them into a command string to use with cpuminer. Now I can just wait for the autotune to finish and then copy and paste the output into the command string.

Wow, that's neat. But I have a couple of questions.

How can you tell when the auto tune process is complete? Never mind. Looks like you have to pass the --debug option.

Does any other factor affect auto-tuning, like a coin switch on a multi-pool?

I'm just wondering if it makes sense to bypass auto tuning in all cases, or if it's better to leave it on and let it react to pool changes.

Sorry in advance if I don't understand how the auto tune feature really works.

[fivejonnyfive]

I didn't want to do autotune every time the miner restarted and manually entering the values every time was tedious. For some reason, the device names changed after upgrading the miner version.
I wrote a little PHP script that will query all the frequencies for the chips and format them into a command string to use with cpuminer. Now I can just wait for the autotune to finish and then copy and paste the output into the command string.

Wow, that's neat. But I have a couple of questions.

How can you tell when the auto tune process is complete? Never mind. Looks like you have to pass the --debug option.

Does any other factor affect auto-tuning, like a coin switch on a multi-pool?

I'm just wondering if it makes sense to bypass auto tuning in all cases, or if it's better to leave it on and let it react to pool changes.

Sorry in advance if I don't understand how the auto tune feature really works.

Auto tune isn't going to affect or be affected by any pool changes - all it's really doing is optimizing the settings for your specific hardware, and those settings will be the same regardless of pool or coin.

Basically, each gridseed chip on the miner can be told to run at a different rate. Higher rates mean more hashpower, but too high for the chip and you'll just get errors and not actually see any results for your hashpower.

The simplified explanation of how auto tune works is it slowly increases the operating speed of each chip until it starts to see errors and then backs off a bit until the error rate is stable. The result is your hardware will be operating at the highest speed it is capable of without producing errors.

I thought it was a gimmick when I first started using it - my miner would autotune and stay at 850 where i started it - BUT when I bought two more, one comfortably runs at 930-950 sometimes nudging above 400kh. Go figure.

Anyway - once you autotune once, the numbers per device and chip are basically established and aren't going to really change boot to boot. The idea is by starting with those instead of autotuning, you aren't wasting time running at subprime efficiency until the tuning process completes.

[fivejonnyfive]

You just need a webserver with php installed and put that script in your /var/www directory and give it a .php extension

Code:

sudo apt-get install lighttpd php5-cgi
sudo service lighttpd force-reload

By the way in case anyone gets a 403 error right off the bat accessing the PHP you might also need to enable cgi

Code:

sudo lighty-enable-mod fastcgi 
sudo lighty-enable-mod fastcgi-php 
sudo service lighttpd force-reload

That made it work for me!

[reactor]

cpuminer-gc3355 v0.9f

* Automatic detection of GC3355 miners (not for Windows): --gc3355-detect
* API: on the fly frequency setting
* API: allow simulaneous connections

Binaries have been updated.
Windows: https://www.dropbox.com/s/ttqa9p851siz8oi/minerd-gc3355.zip
Raspberry PI: https://www.dropbox.com/s/xc3lvysi8vtrt00/minerd-gc3355

Out of curiosity, did get on the latest and even though I've been building all these locally, this time I get this:

echo './'`cpu-miner.c
cpu-miner.c:1751:1: fatal error: opening dependency file .deps/minerd-cpu-miner.Tpo: Permission denied

And compilation terminates after that.  Grabbing latest rpi compiled version instead.

...

Using the precompiled RPi version and things aren't looking good (on my machine, anyway) for f.  I switched my instances so I could split the 5-chips and blades to separate pools based on diff, but now I'm seeing long screens of this on my blades.  Been running for five minutes, zero accepted shares.

Code:

 [2014-05-08 13:29:00] 1: Dispatching new work to GC3355 cores (0x869cbba6)
 [2014-05-08 13:29:00] 3: Dispatching new work to GC3355 cores (0x869cbba6)
 [2014-05-08 13:29:00] 2: Dispatching new work to GC3355 cores (0x869cbba6)
 [2014-05-08 13:29:00] 0: Dispatching new work to GC3355 cores (0x869cbba6)
 [2014-05-08 13:29:04] 2@38: Work_id differs (869ce392 != 869cbba6)
 [2014-05-08 13:29:14] 3@2: Work_id differs (869ce392 != 869cbba6)
 [2014-05-08 13:29:30] 3@1: Work_id differs (869ce392 != 869cbba6)
 [2014-05-08 13:29:33] 2@32: Work_id differs (869ce392 != 869cbba6)
 [2014-05-08 13:29:50] 1@1: Work_id differs (869ce392 != 869cbba6)
 [2014-05-08 13:29:50] 3@1: Work_id differs (869ce392 != 869cbba6)
 [2014-05-08 13:29:51] New job_id: 246 Diff: 850
 [2014-05-08 13:29:51] Stratum detected new block
 [2014-05-08 13:29:51] 0: Dispatching new work to GC3355 cores (0x86cf58ea)
 [2014-05-08 13:29:52] 2: Dispatching new work to GC3355 cores (0x86cf58ea)
 [2014-05-08 13:29:52] 3: Dispatching new work to GC3355 cores (0x86cf58ea)
 [2014-05-08 13:29:52] 1: Dispatching new work to GC3355 cores (0x86cf58ea)
 [2014-05-08 13:30:08] 1@2: Work_id differs (86cf12a0 != 86cf58ea)
 [2014-05-08 13:30:24] 1@0: Work_id differs (86cf12a0 != 86cf58ea)
 [2014-05-08 13:30:51] New job_id: 247 Diff: 850
 [2014-05-08 13:30:54] 1@3: Work_id differs (86cf12a0 != 86cf58ea)
 [2014-05-08 13:30:58] 1@0: Work_id differs (86cf12a0 != 86cf58ea)
 [2014-05-08 13:31:06] New job_id: 248 Diff: 850
 [2014-05-08 13:31:06] Stratum detected new block
 [2014-05-08 13:31:06] 0: Dispatching new work to GC3355 cores (0x871a181e)
 [2014-05-08 13:31:06] 3: Dispatching new work to GC3355 cores (0x871a181e)
 [2014-05-08 13:31:06] 1: Dispatching new work to GC3355 cores (0x871a181e)
 [2014-05-08 13:31:07] 2: Dispatching new work to GC3355 cores (0x871a181e)
 [2014-05-08 13:32:06] New job_id: 249 Diff: 850
 [2014-05-08 13:32:07] 3@1: Work_id differs (871aa570 != 871a181e)

[edonkey]

Auto tune isn't going to affect or be affected by any pool changes - all it's really doing is optimizing the settings for your specific hardware, and those settings will be the same regardless of pool or coin.

Basically, each gridseed chip on the miner can be told to run at a different rate. Higher rates mean more hashpower, but too high for the chip and you'll just get errors and not actually see any results for your hashpower.

The simplified explanation of how auto tune works is it slowly increases the operating speed of each chip until it starts to see errors and then backs off a bit until the error rate is stable. The result is your hardware will be operating at the highest speed it is capable of without producing errors.

I thought it was a gimmick when I first started using it - my miner would autotune and stay at 850 where i started it - BUT when I bought two more, one comfortably runs at 930-950 sometimes nudging above 400kh. Go figure.

Anyway - once you autotune once, the numbers per device and chip are basically established and aren't going to really change boot to boot. The idea is by starting with those instead of autotuning, you aren't wasting time running at subprime efficiency until the tuning process completes.

Thanks for getting back to me. That's a good explanation. For some reason I thought that some hardware errors could be the result of pool changes.

I've got the latest version running under Ubuntu on a test rig with 3 GSDs with auto tune on and it's set frequencies between 895 and 930 MHz. Looking good so far.

This is far easier than cgminer. It took me something like a week to tune my other rig, and I only bothered to tune per unit, not per chip, because it was too time consuming.

I plan to move to minerd and Minera on my main rig this weekend.

[reactor]

So to update on progress w/ versions...

Five chip units are running flawlessly on Scryptguild (vardiff since it is multipool), fastest I've ever seen them move.  They're working on 0.9e right now.  Tried having them on WeMineLtc but kept getting stratum interruption/drop messages.

0.9f completely destabilized my blades, for lack of a better description.  They appeared to hit a deadlock state where they would only report work ids differing but not actually being replaced by good work.  Tested this for over 20 minutes and never got a share out of them, was hoping there might be some flush > restart type process in effect but I never got them back.  Ended up completely unplugging the blades, checking the new locations, and spinning up a new instance (freq:850, v:0.9e) and they're flying again.  

Not sure if there is anything unique about my hardware.  Of course my dumbass doesn't having logging turned on, but I did notice upon one of the restarts of cpuminer it was giving a message that it couldn't get device id and the message indicated chips=5, but the device was definitely a blade.  Not sure if that info can help, next time I rewrite my scripts I will include logging on everything.

Edit: Just to update, weirdness continues.  It seems that since switching to .9e I have to completely unplug hardware between running instances of cpuminer in order to re-enable hashing.  A few days ago I was throwing new instances up every few minutes and hashing started immediately every time, now I get a lot of work being dispatched, old job ids, and basically a nice display of when new blocks are detected.   Not sure what changed if anything in getting the re-enable functionality to work, but hardware-wise nothing has changed on my end, just version of cpuminer I'm using.

[edonkey]

A couple of feature requests for Sandor's cpuminer.

It would be great if cpuminer directly supported failover to other pools, with the option to return to the primary pool. As it is, it looks like the dev suggests a script with multiple calls to minerd, where a different pool is specified on each command line. While I can see that this kind of works, the result is that the miner will be stuck on alternate pools until those pools fail.

In my case with cgminer, I have my primary pool set to a multi-pool. When fails, the rig points at a fixed coin pool. When the primary comes back online, it points back to the primary.

The reason why I have it configured this way is because I prefer the multi-pool for profitability. But when it's down I don't want to point the rig at another multi pool because it's usually for only a brief time, which often results in not meeting the minimum payout, and dust sitting in the secondary pool forever. It's much cleaner to just mine a single coin for a brief time while the primary is out. That way there are no exchange issues.

The second feature request is for support of a config file. It would be great to be able to specify options in a JSON config file rather than on the raw command line. This would especially be useful to specify auto tune derived frequencies (which can be large for bigger rigs).

Also, if the failover feature is implemented at some point, it's cleaner to specify multiple pools and user credentials in a config file rather than on the command line.

[MatthewBCF]

A couple of feature requests for Sandor's cpuminer.

It would be great if cpuminer directly supported failover to other pools, with the option to return to the primary pool. As it is, it looks like the dev suggests a script with multiple calls to minerd, where a different pool is specified on each command line. While I can see that this kind of works, the result is that the miner will be stuck on alternate pools until those pools fail.

In my case with cgminer, I have my primary pool set to a multi-pool. When fails, the rig points at a fixed coin pool. When the primary comes back online, it points back to the primary.

The reason why I have it configured this way is because I prefer the multi-pool for profitability. But when it's down I don't want to point the rig at another multi pool because it's usually for only a brief time, which often results in not meeting the minimum payout, and dust sitting in the secondary pool forever. It's much cleaner to just mine a single coin for a brief time while the primary is out. That way there are no exchange issues.

The second feature request is for support of a config file. It would be great to be able to specify options in a JSON config file rather than on the raw command line. This would especially be useful to specify auto tune derived frequencies (which can be large for bigger rigs).

Also, if the failover feature is implemented at some point, it's cleaner to specify multiple pools and user credentials in a config file rather than on the command line.

I have to say that this is where cgminer excels..json conf file, multiple pools, multiple modes of running those pools..quotas even..

Definitely not knocking cpuminer tho!  I'm using it for 90% of my hash now..

And features often come down to motivation right - The more who donate to Sandor the more likely we are to see any of these nice-to-haves..I for one made sure to..always good to feed the programmers now and again

[unamis76]

Still not getting how to swap frequencies on the fly with this new cpuminer, any ideas?

[sandor111]

A couple of feature requests for Sandor's cpuminer.

It would be great if cpuminer directly supported failover to other pools, with the option to return to the primary pool. As it is, it looks like the dev suggests a script with multiple calls to minerd, where a different pool is specified on each command line. While I can see that this kind of works, the result is that the miner will be stuck on alternate pools until those pools fail.

In my case with cgminer, I have my primary pool set to a multi-pool. When fails, the rig points at a fixed coin pool. When the primary comes back online, it points back to the primary.

The reason why I have it configured this way is because I prefer the multi-pool for profitability. But when it's down I don't want to point the rig at another multi pool because it's usually for only a brief time, which often results in not meeting the minimum payout, and dust sitting in the secondary pool forever. It's much cleaner to just mine a single coin for a brief time while the primary is out. That way there are no exchange issues.

The second feature request is for support of a config file. It would be great to be able to specify options in a JSON config file rather than on the raw command line. This would especially be useful to specify auto tune derived frequencies (which can be large for bigger rigs).

Also, if the failover feature is implemented at some point, it's cleaner to specify multiple pools and user credentials in a config file rather than on the command line.

I have to say that this is where cgminer excels..json conf file, multiple pools, multiple modes of running those pools..quotas even..

Definitely not knocking cpuminer tho!  I'm using it for 90% of my hash now..

And features often come down to motivation right - The more who donate to Sandor the more likely we are to see any of these nice-to-haves..I for one made sure to..always good to feed the programmers now and again

I'm testing the failover code ATM, will be released soon.

[RowanX]

I'm still getting lots of rejects with cpuminer 0.9d onwards so I'm going to try a different pool to see if that helps. Is there a switch in cpuminer to set the diff? cex.io (GHash.IO - same thing?) does not seem to use vardiff and its default 16 seems a bit low. My main pool (give-me-coins) starts at 16 but usually goes up to 96-128+ within minutes.

And FWIW the rejects I get from give-me-coins pool only start to happen when diff goes up to 64+. What diff are you guys getting/setting?