Topic: [GUIDE] GridSeed 5-Chip USB, Blade & Black Miner Support/Tuning - page 21. (Read 308807 times)
For those who had a high reject rate since v0.9e, you should try v0.9g. It has an additional command line parameter to only send work when a new block is detected (--no-refresh), by default it always sends new work as previously, so there should be much less rejects. You may enable this if your G-Blade is having trouble keeping up with the work sent.
cpuminer-gc3355 v0.9g
* Failover pool strategy is supported
* Low reject rate (--no-refresh -> disabled)
Will add support for config file soon.
Binaries have been updated.
Windows: https://www.dropbox.com/s/ttqa9p851siz8oi/minerd-gc3355.zip
Raspberry PI: https://www.dropbox.com/s/xc3lvysi8vtrt00/minerd-gc3355
* Failover pool strategy is supported
* Low reject rate (--no-refresh -> disabled)
Code:
--url=stratum+tcp://pool1:port --userpass=user1:pass1 --url=stratum+tcp://pool2:port --userpass=user2:pass2 --url=stratum+tcp://pool3:port --userpass=user3:pass3
Pool 1 is the main pool, if it is down, it will try to connect to the backup pool(s) and query the main pool until it is back up and switch pools automatically.Will add support for config file soon.
Binaries have been updated.
Windows: https://www.dropbox.com/s/ttqa9p851siz8oi/minerd-gc3355.zip
Raspberry PI: https://www.dropbox.com/s/xc3lvysi8vtrt00/minerd-gc3355
API access and JSON commands keep failing
any idea why?
Quote
API: Client 192.168.1.9 connected
API: JSON decode failed(1): '[' or '{' expected near '/' (/x-xbitmap, */*;q=0.1)
API: Client 192.168.1.9 connected
API: JSON decode failed(1): '[' or '{' expected near '0.1' (0.1)
API: JSON decode failed(1): '[' or '{' expected near '/' (/x-xbitmap, */*;q=0.1)
API: Client 192.168.1.9 connected
API: JSON decode failed(1): '[' or '{' expected near '0.1' (0.1)
any idea why?
It would be great if someone could modify this code to include per chip freq settings 
https://github.com/girnyau/cgminer-gc3355/commit/ac7ee8b084abcffc8b8431eb515c62ed3e891fb1
...might be easy for someone but over my skill set
https://github.com/girnyau/cgminer-gc3355/commit/ac7ee8b084abcffc8b8431eb515c62ed3e891fb1
...might be easy for someone but over my skill set
I actually gave it a try based off of Sandor's code. It's fairly easy to read. I was able to set the per chip frequency command but my Gridseeds wouldnt hash afterwards. I didn't bother looking into this further, if Sandor adds the failover functionality, I'm all set.
It would be great if someone could modify this code to include per chip freq settings
https://github.com/girnyau/cgminer-gc3355/commit/ac7ee8b084abcffc8b8431eb515c62ed3e891fb1
...might be easy for someone but over my skill set
https://github.com/girnyau/cgminer-gc3355/commit/ac7ee8b084abcffc8b8431eb515c62ed3e891fb1
...might be easy for someone but over my skill set
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?
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?
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.
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.
Still not getting how to swap frequencies on the fly with this new cpuminer, any ideas?
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.
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
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.
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.
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.
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. 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.
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.
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
* 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)
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!
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.
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.
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.
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.
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.
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.
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.
And the output:
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:
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
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!
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.
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).
Jump to: