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

[ManeBjorn]

I like the new readout on version D.
Thanks.
So far I am not running into the slow death of hashing speed on my blades.
Great work.
I sent a tip your way.   

in the actual version of cpuminer ... the autotune feature doesn't log when it changes a per chip frequency nor the steps to go .. right?
any way to re-add that log output which showed which chip running at which freq?

Hum, does that auto tune work for the blade?
I have only used bfgminer so far with the blade unit, had issues trying to get cgminer working keeps kicking me out?

Here are my bfgminer settings, it runs around 50C right now in the basement, can run from 4.8-5.4hps max so far.

Bfgminer -S gridseed:all --set-device gridseed:clock=850:BTC=0:chips=40:modules=1:usefifo=0 --scrypt -o stratum+tcp://east1.us.stratum.dedicatedpool.com:3350 -u user -p password

Anyone have a cgminer configuration file that I can use to get this going with other mining software?

Of course it works for the Blade, it autotunes each chip individually.

[msb17]

Important! You MUST update to the latest binaries (Download on Github)

Just donwloaded another version of the source from your GitHub repo, and recompiled on Ubuntu and still am getting version 0.9c instead of ...d.

Maybe I've done something wrong but just double chekcking; is the new source up on GitHub also?

[toxic0n]

Sandor, any chance of adding an option to switch back to the primary pool after failover to backup? I rent my hash power out on Betarigs and can't do it with this cpuminer.

[thearcticcat]

here is the debug

https://dl.dropboxusercontent.com/u/109298881/cpuminer-gc3355-debug.log

Your pool is sending a new job like every second, could you please try a different pool?

I think you may have found my issue as I switched it to clevermining pool which seems to be giving the miners a difficulty of 512. I had been using difficulty of 128 with my gridseeds on multipool and never modified this for the blade. Seems to not be an issue with the 5 chip gridseeds, but it must be sending work too quickly for the blades to handle. Its been up and running for over 10 minutes now so I will let you know how it goes.

Ya I think sending work too quickly will corrupt the Gridseed registers, anyhow I'm making some modifications now so that it will prevent that.

It must be the way multipool is sending the work as I changed my difficulty to 512 and it still stops hashing on that pool. I see differences in my logs that I attached.

https://dl.dropboxusercontent.com/u/109298881/cpuminer-gc3355%20Multipool.log

https://dl.dropboxusercontent.com/u/109298881/cpuminer-gc3355%20Clevermining.log

https://dl.dropboxusercontent.com/u/109298881/cpuminer-gc3355Cleverming2.log

With clevermining I see this DEBUG: reject reason: job not found. When connecting to multipool that message never appears

i am having the same problem as this guy i have two 5 chip gc3355 on 0.9d and im just getting new work ids very frequently but no accepted shares, even only at 128 diff. --debug did not generate a file or do you have to close the console first because i changed GSD 1 down from 99mhz to 875mhz and i'm actually getting shares.

it is also displaying Got nonce xxxxxxxx, hash <= Htarget when it wasn't when i was mining on rapidhash. only displaying that on the multipool and only when it actually starts accepting shares, which albeit they are shares they seem to be fewer and my reported hashrate is lower then when i was on rapidhash. something with these pools maybe i don't know. the multipool was mining LTC at the time of this report.

thanks for all of your hard work sandor!

EDIT: Does your TUI work with single chip gridseed DUALMINERS? The USB sticks. If so that would be extremely convenient as I could have all of my gridseed chips on one console. I figured if you could implement a diff number support for the blade it wouldn't be hard to implement a single gc3355 chip com port into your miner? correct me if i am wrong!

[toxic0n]

Is there any way to check what the per chip frequency is after the autotune is done? Some of my Gridseeds are at frequencies such as 865, 830, 895 Mhz, Im assuming it's displaying the average frequency of the 5 chips per device.

[organofcorti]

Is there any way to check what the per chip frequency is after the autotune is done? Some of my Gridseeds are at frequencies such as 865, 830, 895 Mhz, Im assuming it's displaying the average frequency of the 5 chips per device.

I've just been using the output piped to a text file. You can process it to find the frequency change messages and assign the correct chips and devices. Interestingly, for one of my gridseeds, three chips autotuned to 900MHz, one to 875MHz, and one to 700 MHz. It took an hour for most of them to autotune but the chip that ended up on 700MHz took about nine hours. The other nine devices had chips that had autotuned frequencies ranging from 800 to 925 MHz.

EDIT: There's an API but I have no idea how to make it work.

[sandor111]

Here is an example for PHP:

Code:

<?php
define("API_MINER_START_TIME", "t");
define("API_DEVICES", "d");
define("API_CHIPS", "c");
define("API_LAST_SHARE", "l");
define("API_CHIP_ACCEPTED", "ac");
define("API_CHIP_REJECTED", "re");
define("API_CHIP_HW_ERRORS", "hw");
define("API_CHIP_FREQUENCY", "fr");
define("API_CHIP_HASHRATE", "ha");
define("API_CHIP_SHARES", "sh");
if(!($fp = fsockopen("127.0.0.1", 4028, $errno, $errstr, 0)))
{
    die("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);
print_r($arr);

This will print the JSON array.
To get the list of devices you would simply do

Code:

$devs = $arr[API_DEVICES];

[csmflynt3]

here is the debug

https://dl.dropboxusercontent.com/u/109298881/cpuminer-gc3355-debug.log

Your pool is sending a new job like every second, could you please try a different pool?

I think you may have found my issue as I switched it to clevermining pool which seems to be giving the miners a difficulty of 512. I had been using difficulty of 128 with my gridseeds on multipool and never modified this for the blade. Seems to not be an issue with the 5 chip gridseeds, but it must be sending work too quickly for the blades to handle. Its been up and running for over 10 minutes now so I will let you know how it goes.

Ya I think sending work too quickly will corrupt the Gridseed registers, anyhow I'm making some modifications now so that it will prevent that.

It must be the way multipool is sending the work as I changed my difficulty to 512 and it still stops hashing on that pool. I see differences in my logs that I attached.

https://dl.dropboxusercontent.com/u/109298881/cpuminer-gc3355%20Multipool.log

https://dl.dropboxusercontent.com/u/109298881/cpuminer-gc3355%20Clevermining.log

https://dl.dropboxusercontent.com/u/109298881/cpuminer-gc3355Cleverming2.log

With clevermining I see this DEBUG: reject reason: job not found. When connecting to multipool that message never appears

i am having the same problem as this guy i have two 5 chip gc3355 on 0.9d and im just getting new work ids very frequently but no accepted shares, even only at 128 diff. --debug did not generate a file or do you have to close the console first because i changed GSD 1 down from 99mhz to 875mhz and i'm actually getting shares.

it is also displaying Got nonce xxxxxxxx, hash <= Htarget when it wasn't when i was mining on rapidhash. only displaying that on the multipool and only when it actually starts accepting shares, which albeit they are shares they seem to be fewer and my reported hashrate is lower then when i was on rapidhash. something with these pools maybe i don't know. the multipool was mining LTC at the time of this report.

thanks for all of your hard work sandor!

EDIT: Does your TUI work with single chip gridseed DUALMINERS? The USB sticks. If so that would be extremely convenient as I could have all of my gridseed chips on one console. I figured if you could implement a diff number support for the blade it wouldn't be hard to implement a single gc3355 chip com port into your miner? correct me if i am wrong!

On version .09d I have been running stable for 15+hrs with 10 5 Chip gridseeds and 1 blade using multipool. All of the issues have been fixed in this version although I never had any problem on the 5 chip gridseeds. You may want to create a new worker on multipool as sometimes they get banned due to the DDOS protections and you will never see accepted shares, but it will send you work

[thearcticcat]

here is the debug

https://dl.dropboxusercontent.com/u/109298881/cpuminer-gc3355-debug.log

Your pool is sending a new job like every second, could you please try a different pool?

I think you may have found my issue as I switched it to clevermining pool which seems to be giving the miners a difficulty of 512. I had been using difficulty of 128 with my gridseeds on multipool and never modified this for the blade. Seems to not be an issue with the 5 chip gridseeds, but it must be sending work too quickly for the blades to handle. Its been up and running for over 10 minutes now so I will let you know how it goes.

Ya I think sending work too quickly will corrupt the Gridseed registers, anyhow I'm making some modifications now so that it will prevent that.

It must be the way multipool is sending the work as I changed my difficulty to 512 and it still stops hashing on that pool. I see differences in my logs that I attached.

https://dl.dropboxusercontent.com/u/109298881/cpuminer-gc3355%20Multipool.log

https://dl.dropboxusercontent.com/u/109298881/cpuminer-gc3355%20Clevermining.log

https://dl.dropboxusercontent.com/u/109298881/cpuminer-gc3355Cleverming2.log

With clevermining I see this DEBUG: reject reason: job not found. When connecting to multipool that message never appears

i am having the same problem as this guy i have two 5 chip gc3355 on 0.9d and im just getting new work ids very frequently but no accepted shares, even only at 128 diff. --debug did not generate a file or do you have to close the console first because i changed GSD 1 down from 99mhz to 875mhz and i'm actually getting shares.

it is also displaying Got nonce xxxxxxxx, hash <= Htarget when it wasn't when i was mining on rapidhash. only displaying that on the multipool and only when it actually starts accepting shares, which albeit they are shares they seem to be fewer and my reported hashrate is lower then when i was on rapidhash. something with these pools maybe i don't know. the multipool was mining LTC at the time of this report.

thanks for all of your hard work sandor!

EDIT: Does your TUI work with single chip gridseed DUALMINERS? The USB sticks. If so that would be extremely convenient as I could have all of my gridseed chips on one console. I figured if you could implement a diff number support for the blade it wouldn't be hard to implement a single gc3355 chip com port into your miner? correct me if i am wrong!

On version .09d I have been running stable for 15+hrs with 10 5 Chip gridseeds and 1 blade using multipool. All of the issues have been fixed in this version although I never had any problem on the 5 chip gridseeds. You may want to create a new worker on multipool as sometimes they get banned due to the DDOS protections and you will never see accepted shares, but it will send you work

this worked. thanks. poolside hashrate seems to always be off quite a bit up or down but maybe that's just multipool for you.

[ny2cafuse]

Sandor,

   It seems the optimizations you made to tuning have actually decreased performance on my 20 5-chip units.  My graphs were hitting upper limits of 7.7MH for 20 units, were now they are only hitting 7.1MH.  Rejects/HW errors are about the same.  That's a pretty big dip.

    Just thought I would report what I'm seeing on my end.  I might recompile the older version and roll with that for the time being.

-Fuse

[sandor111]

Sandor,

   It seems the optimizations you made to tuning have actually decreased performance on my 20 5-chip units.  My graphs were hitting upper limits of 7.7MH for 20 units, were now they are only hitting 7.1MH.  Rejects/HW errors are about the same.  That's a pretty big dip.

    Just thought I would report what I'm seeing on my end.  I might recompile the older version and roll with that for the time being.

-Fuse

The only change in autotuning is the time needed to make adjustments, so autotune will take longer to finish.

[racebyu]

This software works great!!! Thanks Sandor111.
Question, I set the com ports in my file to reflect a one blade miner.

minerd.exe --freq=800 --gc3355=\\.\COM3,\\.\COM4 --gc3355-chips=40 --url=stratum+tcp://usde.poolerino.com:3341 --userpass=username:password


If I have two blades how would I configure for this if on the same computer but each blade on a different pool?
Is this how I would configure or is it not possible?

minerd.exe --freq=800 --gc3355=\\.\COM3,\\.\COM4 --gc3355-chips=40 --url=stratum+tcp://usde.poolerino.com:3341 --userpass=username:password --freq=800 --gc3355=\\.\COM5,\\.\COM6 --gc3355-chips=40 --url=stratum+tcp://de2.miningpool.co:3399 --userpass=username:password

Thanks again for your help, still reading and learning....

[sandor111]

This software works great!!! Thanks Sandor111.
Question, I set the com ports in my file to reflect a one blade miner.

minerd.exe --freq=800 --gc3355=\\.\COM3,\\.\COM4 --gc3355-chips=40 --url=stratum+tcp://usde.poolerino.com:3341 --userpass=username:password


If I have two blades how would I configure for this if on the same computer but each blade on a different pool?
Is this how I would configure or is it not possible?

minerd.exe --freq=800 --gc3355=\\.\COM3,\\.\COM4 --gc3355-chips=40 --url=stratum+tcp://usde.poolerino.com:3341 --userpass=username:password --freq=800 --gc3355=\\.\COM5,\\.\COM6 --gc3355-chips=40 --url=stratum+tcp://de2.miningpool.co:3399 --userpass=username:password

Thanks again for your help, still reading and learning....

If you want to run them on a different pool, you need to run two instances of cpuminer.
So:

Code:

minerd.exe --freq=800 --gc3355=\\.\COM3,\\.\COM4 --gc3355-chips=40 --url=stratum+tcp://usde.poolerino.com:3341 --userpass=username:password
minerd.exe --freq=800 --gc3355=\\.\COM5,\\.\COM6 --gc3355-chips=40 --url=stratum+tcp://de2.miningpool.co:3399 --userpass=username:password

[ny2cafuse]

The only change in autotuning is the time needed to make adjustments, so autotune will take longer to finish.

Maybe that's the issue with my units then.  They are picky enough to want to work faster when they can, but are limited.  I'll recompile and check the results.

-Fuse

[sandor111]

The only change in autotuning is the time needed to make adjustments, so autotune will take longer to finish.

Maybe that's the issue with my units then.  They are picky enough to want to work faster when they can, but are limited.  I'll recompile and check the results.

-Fuse

The higher the pool difficulty, the longer it will take.
By default, it's 3845 steps (~ 1 hour of hashing time). But with diff 512, it's 512*10 = 5120 steps.

[ny2cafuse]

The only change in autotuning is the time needed to make adjustments, so autotune will take longer to finish.

Maybe that's the issue with my units then.  They are picky enough to want to work faster when they can, but are limited.  I'll recompile and check the results.

-Fuse

The higher the pool difficulty, the longer it will take.
By default, it's 3845 steps (~ 1 hour of hashing time). But with diff 512, it's 512*10 = 5120 steps.

I've set up a separate port on the pool specifically for gridseeds.  It maxes at 256.  Would it be 2560 then?

Is it possible to tune faster, or would that cause more problems?  I'm not saying could you do that, but rather can it be done.  It would be interesting to see what a faster turning time would do.

-Fuse

[racebyu]

This software works great!!! Thanks Sandor111.
Question, I set the com ports in my file to reflect a one blade miner.

minerd.exe --freq=800 --gc3355=\\.\COM3,\\.\COM4 --gc3355-chips=40 --url=stratum+tcp://usde.poolerino.com:3341 --userpass=username:password


If I have two blades how would I configure for this if on the same computer but each blade on a different pool?
Is this how I would configure or is it not possible?

minerd.exe --freq=800 --gc3355=\\.\COM3,\\.\COM4 --gc3355-chips=40 --url=stratum+tcp://usde.poolerino.com:3341 --userpass=username:password --freq=800 --gc3355=\\.\COM5,\\.\COM6 --gc3355-chips=40 --url=stratum+tcp://de2.miningpool.co:3399 --userpass=username:password

Thanks again for your help, still reading and learning....

If you want to run them on a different pool, you need to run two instances of cpuminer.
So:

Code:

minerd.exe --freq=800 --gc3355=\\.\COM3,\\.\COM4 --gc3355-chips=40 --url=stratum+tcp://usde.poolerino.com:3341 --userpass=username:password
minerd.exe --freq=800 --gc3355=\\.\COM5,\\.\COM6 --gc3355-chips=40 --url=stratum+tcp://de2.miningpool.co:3399 --userpass=username:password

Great, thanks again!!

[sandor111]

The only change in autotuning is the time needed to make adjustments, so autotune will take longer to finish.

Maybe that's the issue with my units then.  They are picky enough to want to work faster when they can, but are limited.  I'll recompile and check the results.

-Fuse

The higher the pool difficulty, the longer it will take.
By default, it's 3845 steps (~ 1 hour of hashing time). But with diff 512, it's 512*10 = 5120 steps.

I've set up a separate port on the pool specifically for gridseeds.  It maxes at 256.  Would it be 2560 then?

Is it possible to tune faster, or would that cause more problems?  I'm not saying could you do that, but rather can it be done.  It would be interesting to see what a faster turning time would do.

-Fuse

Sorry, I forgot to mention that the lower bound is 3845. But those values can be adjusted in the source code (gc3355.h).
Look for:

Code:

#define GC3355_OVERCLOCK_MAX_HWE 3
#define GC3355_OVERCLOCK_ADJUST_MIN 10
#define GC3355_OVERCLOCK_ADJUST_STEPS 3845

If you reduce GC3355_OVERCLOCK_ADJUST_MIN and GC3355_OVERCLOCK_ADJUST_STEPS, then it will lower the time needed to adjust. Just don't set it below 2 or diff * 2

[unamis76]

Changed to the new version, running solid for 5+ hours. Autotune already finished, it's a very nice feature, now I can push my rig further!

Thanks for your work, sandor111

[wolfey2014]

The only change in autotuning is the time needed to make adjustments, so autotune will take longer to finish.

Maybe that's the issue with my units then.  They are picky enough to want to work faster when they can, but are limited.  I'll recompile and check the results.

-Fuse

The higher the pool difficulty, the longer it will take.
By default, it's 3845 steps (~ 1 hour of hashing time). But with diff 512, it's 512*10 = 5120 steps.

I've set up a separate port on the pool specifically for gridseeds.  It maxes at 256.  Would it be 2560 then?

Is it possible to tune faster, or would that cause more problems?  I'm not saying could you do that, but rather can it be done.  It would be interesting to see what a faster turning time would do.

-Fuse

Sorry, I forgot to mention that the lower bound is 3845. But those values can be adjusted in the source code (gc3355.h).
Look for:

Code:

#define GC3355_OVERCLOCK_MAX_HWE 3
#define GC3355_OVERCLOCK_ADJUST_MIN 10
#define GC3355_OVERCLOCK_ADJUST_STEPS 3845

If you reduce GC3355_OVERCLOCK_ADJUST_MIN and GC3355_OVERCLOCK_ADJUST_STEPS, then it will lower the time needed to adjust. Just don't set it below 2 or diff * 2

Hey! I see lots of progress here since I reverted back to 2.3.2
I do miss the stats at the top though ;(
I think I'll try it out now since most of the issues seem to be handled now.
I know what a hassle updating can be. I just don't have the time or patience to be part of constant debugging. I need stable clean performance w/no issues. Seems it may be there now.
Is the win binary up to date and ready to go now?
Thanks for all your hard work and dedication Sandor111!
Peace
Wolfey2014