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

[nst6563]

Just updated to the new binaries. Working great for me.

Same here...awesome work Sandor.  Not sure why it's "freezing" or "locking up" for some people, I've never had the problem, but I don't have a lot of gridseeds either.  Maybe it's a memory allocation issue with enabling autotune for all those gridseeds?  I'm not sure if you're using hashtables, arrays, or dictionaries to record and keep track of autotune info but maybe people with a lot of gridseeds are hitting a limitation within the method?  

If someone wants to send me 100 or more gridseeds to "test" I have 32GB ram in my system to test the theory  

It's none of that. The curses TUI isn't thread safe, so I have to use pthread_mutex to keep stuff synchronized between threads. My shitty coding lead to some deadlocks I think, where one thread was waiting forever for a lock to release. I have no idea about the top stat on Windows though, the same code works perfectly fine on any Unix system I tested (Rpi, Ubuntu, OpenWrt) which are using ncurses lib, so I guess it's a bug in the pdcurses lib which Windows uses (specifically printw/wprintw).

That's good to know, at least you know where to look.  It's a work in progress, people shouldn't expect perfection with every release.  My hat's off to you for your awesome work though.  The top bar was just a 'technicality' in my opinion as the rest of it worked just fine.

[sandor111]

It's a work in progress, people shouldn't expect perfection with every release. 

Unless you are called Wolfey2014.

[nst6563]

It's a work in progress, people shouldn't expect perfection with every release. 

Unless you are called Wolfey2014.

 

[Kergekoin]

Looks like "--freq=950" overrides the "--gc3355-freq=\\.\COM42:700"
How could i set one device lower/higher than all the rest without typing each individually?

Edit: OK. I got it. I needed to write individual freq before the overall.

[plzt]

Just updated to the new binaries. Working great for me.

Same here...awesome work Sandor.  Not sure why it's "freezing" or "locking up" for some people, I've never had the problem, but I don't have a lot of gridseeds either.  Maybe it's a memory allocation issue with enabling autotune for all those gridseeds?  I'm not sure if you're using hashtables, arrays, or dictionaries to record and keep track of autotune info but maybe people with a lot of gridseeds are hitting a limitation within the method? 

If someone wants to send me 100 or more gridseeds to "test" I have 32GB ram in my system to test the theory   

Found my 'crash' - batch file set with --retries=5 and so if the pool timed out it just ended

Any way to put in multiple pools? or any kind of management once the program is running?
Apologies if I've missed anything obvious, trying to read 67 pages in 3 days is hard!

[Kergekoin]

Just delete retries flag and it loops indefinately.

I would be interested of checking back the main pool from time to time. And switching over to it when it comes back online.

[RowanX]

Looks like "--freq=950" overrides the "--gc3355-freq=\\.\COM42:700"
How could i set one device lower/higher than all the rest without typing each individually?

Edit: OK. I got it. I needed to write individual freq before the overall.

Not sure thats true? I specify --freq first and my chips all seem to report the desired frequencies.

minerd-gc3355.exe --freq=850 --gc3355=\\.\COM1,\\.\COM2 --url=stratum+tcp://whatever.com:3333 --userpass=xxx.1:password --gc3355-freq=\\.\COM1:875,\\.\COM1:850:2,\\.\COM2:850:0,\\.\COM2:850:1,\\.\COM2:825:2,\\.\COM2:875:3,\\.\COM2:850:4,
pause

this gives the expected speeds:

[2014-04-30 17:28:03] 0@0: Set GC3355 core frequency to 875Mhz
[2014-04-30 17:28:03] 0@1: Set GC3355 core frequency to 875Mhz
[2014-04-30 17:28:03] 0@2: Set GC3355 core frequency to 850Mhz
[2014-04-30 17:28:03] 0@3: Set GC3355 core frequency to 875Mhz
[2014-04-30 17:28:03] 0@4: Set GC3355 core frequency to 875Mhz
[2014-04-30 17:28:03] 1@0: Set GC3355 core frequency to 850Mhz
[2014-04-30 17:28:03] 1@1: Set GC3355 core frequency to 850Mhz
[2014-04-30 17:28:04] 1@2: Set GC3355 core frequency to 825Mhz
[2014-04-30 17:28:04] 1@3: Set GC3355 core frequency to 875Mhz
[2014-04-30 17:28:04] 1@4: Set GC3355 core frequency to 850Mhz

I'm guessing I could actually remove --freq=850 from my bat file, as it is not needed, because I specify all my chip speeds individually thereafter.

[Mr. Jinx]

For those compiling CPUMiner on a Raspberry Pi:

It is not recommended to use the -O3 optimization parameter.
O3 is used for some high level optimization that may cause problems on RPi's.
My cpuminer would freeze very soon when compiled with -O3 parameter!

For Raspberry Pi's the recommended optimizations are -march=armv6 -mfpu=vfp -mfloat-abi=hard
After using these, my RPi is running for 24 hours without freezing.

Compiling CPUMiner on a Raspberry Pi:

Code:

git clone https://github.com/siklon/cpuminer-gc3355
cd cpuminer-gc3355
sh ./autogen.sh
./configure CFLAGS="-march=armv6 -mfpu=vfp -mfloat-abi=hard"
make

[Kergekoin]

Looks like "--freq=950" overrides the "--gc3355-freq=\\.\COM42:700"
How could i set one device lower/higher than all the rest without typing each individually?

Edit: OK. I got it. I needed to write individual freq before the overall.

Not sure thats true? I specify --freq first and my chips all seem to report the desired frequencies.

minerd-gc3355.exe --freq=850 --gc3355=\\.\COM1,\\.\COM2 --url=stratum+tcp://whatever.com:3333 --userpass=xxx.1:password --gc3355-freq=\\.\COM1:875,\\.\COM1:850:2,\\.\COM2:850:0,\\.\COM2:850:1,\\.\COM2:825:2,\\.\COM2:875:3,\\.\COM2:850:4,
pause

this gives the expected speeds:

[2014-04-30 17:28:03] 0@0: Set GC3355 core frequency to 875Mhz
[2014-04-30 17:28:03] 0@1: Set GC3355 core frequency to 875Mhz
[2014-04-30 17:28:03] 0@2: Set GC3355 core frequency to 850Mhz
[2014-04-30 17:28:03] 0@3: Set GC3355 core frequency to 875Mhz
[2014-04-30 17:28:03] 0@4: Set GC3355 core frequency to 875Mhz
[2014-04-30 17:28:03] 1@0: Set GC3355 core frequency to 850Mhz
[2014-04-30 17:28:03] 1@1: Set GC3355 core frequency to 850Mhz
[2014-04-30 17:28:04] 1@2: Set GC3355 core frequency to 825Mhz
[2014-04-30 17:28:04] 1@3: Set GC3355 core frequency to 875Mhz
[2014-04-30 17:28:04] 1@4: Set GC3355 core frequency to 850Mhz

I'm guessing I could actually remove --freq=850 from my bat file, as it is not needed, because I specify all my chip speeds individually thereafter.

Well, its holds true at least on my win8.1 mining rig. If i put individual freq after the overall, then individual freq does not work.

[surgexvb]

The freezing problem seems to have something to do.with the autotune feature.  When enabled, it freezes every 2 hours or so everytime.  When I disable it, now it has been running fine for 12 hours.

[sandor111]

The freezing problem seems to have something to do.with the autotune feature.  When enabled, it freezes every 2 hours or so everytime.  When I disable it, now it has been running fine for 12 hours.

That's because the the autotune features prints a line immediately after another, so it's more likely to deadlock (tui_lock).
Do you still experience freezing even with v0.9a? It should be a thing of the past now.

Looks like "--freq=950" overrides the "--gc3355-freq=\\.\COM42:700"
How could i set one device lower/higher than all the rest without typing each individually?

Edit: OK. I got it. I needed to write individual freq before the overall.

I'm pretty sure it's not the case. The most specific frequency is always applied.

[fivejonnyfive]

For now, the best way is to turn on logging (--log), and CTRL+F "0@0: autotune stopped", "0@1: autotune stopped", ... Pretty tedious if you have lots of miners or G-Blades.
I'm going add a config generator to the autotune feature.

I literally logged on here specifically to request adding a feature where the autotune results could be saved for future boots and I'm f'ing delighted that you're already working on this. Again, infinite gratitude for your work and skills.

[almond]

Is there any reason not to use autotune all the time ?

recently I've been starting cpuminer close to where I want the GSDs to go and let autotune fine tune each chip.

[fivejonnyfive]

Is there any reason not to use autotune all the time ?

recently I've been starting cpuminer close to where I want the GSDs to go and let autotune fine tune each chip.

In my opinion the benefit to not using autotune every time you startup the miner is that while autotune is finding the sweet spot you're going to have a slightly reduced hashrate and/or a higher HW error rate (which functionally reduces the hashrate).

In theory - one run of the autotune on a given unit should produce the optimal "profile" of the sweet-spot frequency for each chip. If you could reload that profile you would have the autotuned-frequencies per-chip without the several-hours of slightly reduced hashrate.

Now, whether there is any noticeable difference is another matter entirely. But, I'd imagine that all but the most casual of casual miners is trying to squeeze every drop of efficiency out of their hardware - so allowing the autotune to save it's conclusions regarding config - this would be appealing to many.

Just my two cents.

[almond]

     "...so allowing the autotune to save it's conclusions regarding config - this would be appealing to many."

yes, that's exactly why I use autotune all the time.

my GSD's run well at 1175 mhz with a few differences up and down for a couple of the chips, so 1175 is not bad for me either.
but it would be a neat trick to be able to take advantage of the autotune's conclusions on the next start...via config or whatever.

[ManeBjorn]

I have been reading through the thread here and I have a couple problems I cannot seem to solve with the blades.
It starts out at over 12 mh/s but after and hour or two goes all the way down to 3.8 and stays there.  This is on clevermining, LTCRabbit and ScryptGuild.
This is with two Blades using CPUMiner.  I am not sure what to do.

Here is my argument.

minerd.exe --freq=800 --gc3355=\\.\COM6,\\.\COM7,\\.\COM9,\\.\COM10 --gc3355-chips=40 --url=stratum+tcp://us.clevermining.com:3333 --userpass=1EV2wjbEkLyXBPzr7hTXyhNjsaNpyuTram:123

pause

I had tried with one Blade and autotune and got the same results.

I am not sure what I need to do to keep them running at full speed.

Any help would be appreciated.

[sandor111]

I have been reading through the thread here and I have a couple problems I cannot seem to solve with the blades.
It starts out at over 12 mh/s but after and hour or two goes all the way down to 3.8 and stays there.  This is on clevermining, LTCRabbit and ScryptGuild.
This is with two Blades using CPUMiner.  I am not sure what to do.

Here is my argument.

minerd.exe --freq=800 --gc3355=\\.\COM6,\\.\COM7,\\.\COM9,\\.\COM10 --gc3355-chips=40 --url=stratum+tcp://us.clevermining.com:3333 --userpass=1EV2wjbEkLyXBPzr7hTXyhNjsaNpyuTram:123

pause

I had tried with one Blade and autotune and got the same results.

I am not sure what I need to do to keep them running at full speed.

Any help would be appreciated.

Upload the full miner log (including debug output), maybe I can find something.
I haven't thoroughly tested on G-Blades, because I don't own one.

[surgexvb]

The freezing problem seems to have something to do.with the autotune feature.  When enabled, it freezes every 2 hours or so everytime.  When I disable it, now it has been running fine for 12 hours.

That's because the the autotune features prints a line immediately after another, so it's more likely to deadlock (tui_lock).
Do you still experience freezing even with v0.9a? It should be a thing of the past now.

Looks like "--freq=950" overrides the "--gc3355-freq=\\.\COM42:700"
How could i set one device lower/higher than all the rest without typing each individually?

Edit: OK. I got it. I needed to write individual freq before the overall.

I'm pretty sure it's not the case. The most specific frequency is always applied.

Thanks for your reply Sandor.  One thing I have always wondered about is when I have multiple gridseeds, or any other ASIC for that matter, do the ASICS actually work together to solve the work that the pool gives, or is each ASIC on its own trying to solve the work.

The reason I ask is I used to run individual cpuminer instances per ASIC, with each ASIC connected with its own worker name to the pool.  With that method, each worker had a low difficulty appropriate for its hashrate.  My hashrate was pretty consistent around 14,500 KH.  Never went much below or.above that.

Now, using your cpuminer, I have 21 gridseeds under one worker name, and since the hashrate is high, the pool gives them high difficulty.  This results in my hashrate fluctuating anywhere from 9,500 KH to 17,000 KH.

If each gridseed is indeed operating on its own, I would think the difficulty would be too high for a 340kh device and would be discarding work because it cannot solve it in time before the work becomes stale.

Any insight into this would be much appreciated.

[Kergekoin]

Reporting for latest windows minerd. Works perfectly for 6-7 hours now.  
Award outgoing to the guy whos responsible.
50K DOGEs sprinting towards you!

[sandor111]

The freezing problem seems to have something to do.with the autotune feature.  When enabled, it freezes every 2 hours or so everytime.  When I disable it, now it has been running fine for 12 hours.

That's because the the autotune features prints a line immediately after another, so it's more likely to deadlock (tui_lock).
Do you still experience freezing even with v0.9a? It should be a thing of the past now.

Looks like "--freq=950" overrides the "--gc3355-freq=\\.\COM42:700"
How could i set one device lower/higher than all the rest without typing each individually?

Edit: OK. I got it. I needed to write individual freq before the overall.

I'm pretty sure it's not the case. The most specific frequency is always applied.

Thanks for your reply Sandor.  One thing I have always wondered about is when I have multiple gridseeds, or any other ASIC for that matter, do the ASICS actually work together to solve the work that the pool gives, or is each ASIC on its own trying to solve the work.

The reason I ask is I used to run individual cpuminer instances per ASIC, with each ASIC connected with its own worker name to the pool.  With that method, each worker had a low difficulty appropriate for its hashrate.  My hashrate was pretty consistent around 14,500 KH.  Never went much below or.above that.

Now, using your cpuminer, I have 21 gridseeds under one worker name, and since the hashrate is high, the pool gives them high difficulty.  This results in my hashrate fluctuating anywhere from 9,500 KH to 17,000 KH.

If each gridseed is indeed operating on its own, I would think the difficulty would be too high for a 340kh device and would be discarding work because it cannot solve it in time before the work becomes stale.

Any insight into this would be much appreciated.

It's pretty technical, but in cpuminer-gc3355, the pool sends work to cpuminer (consists of coinbase, previous hash, merkle tree), cpuminer assembles the block header and adjusts a value called extranonce2, which can be changed freely. This results in a different merkle root hash, thus different 'work'. The work has to be generated for each Gridseed miner to prevent the miners from solving the same work.
The unique work data is sent to the Gridseed miner, where it will be divided between the 5 or 40 chips, this is done by changing the the starting and ending nonce value.

Pool difficulty does not matter long term I think, you'll just get more consistent results on low diff short term. The process of detecting new work and sending it to the Gridseed miner takes less than 1s, atleast on cpuminer. It's fine to discard old work, here is why: there are multiple solutions (nonces) to the work, the probability of finding a nonce with current work doesn't change during trying to solve it, it's not that it 'wasted' time trying to solve work when that work goes stale if you know what I mean.
Hope this helps.

Edit: Thanks Kergecoin.