Fury/Blizzard tuning and mods

[J4bberwock]

My hashrate shows 1,54 on each Fury. There is a hard cap somewhere. Either on the chips, or on the board with a resistor or a bridge somewhere, maybe in the software.
Whatever I change in Ltc clock gives almost the same hashrate.
That reminds me of reading somewhere that going Ltc clock higher than a certain value "voids the warranty"
Something might be capping the value we can use, whatever we are asking. I tester from 450 to 600 Ltc clock with no change either in HW errors or hashrate except some Furys displaying lower hashrate in hashra when the  clock is too high.
For now, I suggest using around 8k resistor to have voltage near 1.35. That will use less watts and give extra stable hashrate around 1.5Mh/s until we find how to remove the cap.
Over 520 or 550 Ltc clock might disable some cores and could explain the low hashrate shown by hashra contrôla.I also had higher hashrate with the laptop on windows during the first tests. I'll test when back at home.

[1714900292]

1714900292

[1714900292]

1714900292

[1714900292]

1714900292

[1714900292]

1714900292

[1714900292]

1714900292

[happydaze]

Complete guess here but maybe the readcount timeout doesn't scale with the out of spec frequency or hashrate and the chips are idle waiting for work.
Chips count affects the readcount timeout.  Chips were spec'd at 300 clk or 210khs so your vmodded 6 chip Fury should perform like a 10 chip device.
You will get a totally wrong local hashrate if you set 10 chips but maybe you'll see if there's any difference poolside.  I think I'd try 8, 10,  and 12 chips as tests to speed up the readcount timeout.
Total guess but worth a try.

[J4bberwock]

After looking at the schematics from Zeus, they are broadcasting the work across chips in a similar way Gridseed is using.

The MODE pins named from 0 to 9 are chips id on the board.
The MODESEL, BPCLK and CLK could be the ones interesting to uncap the clock.
BPCLK might be connected to something to "Bypass clock" probably grounded. I'll check when back at home if there is an obvious bridge to do somewhere.
MODESEL have a 10k resistor connected to it. What is it used for?
CLK is the external 32 MHz crystal used as reference. I'll check if I have something near 40MHz, not sure it could help, but it's the way USB erupters were overclocked.

[J4bberwock]

*Reserved*

Technical info:

From the doc we know the chips have 8 cores.
Also it indicates the hash rate is approx 70% of the clock rate if "--nocheck-golden" is used.

So 340 clk would equal 238kh/s per chip x 6 chips for the Fury = 1.4mh/s approx
328 clk would equal 230kh/s per chip x 6 chips for the Fury = 1.377mh/s approx

Readcount Timeout is explained as:

4.3   Readcount Timeout
After we send one command packet to the chained chips, that BIG chip will cover all the 32 bits nonce in a certain TIME. So we must send a new work to it before that, otherwise its hash power is wasted.

Cgminer’s readcount timeout is used for that. Every count means 0.1 second. We now set the readcount to be 3/8 of the covering time. It may be 3/4 later.

Where are these info coming from? Do we have access to any technical data?
Looks like it's the way they plan to increase hashrate later by"firmware upgrade"

[happydaze]

here's the "Zeus scrypt chip’s software implementation" doc http://zeusminer.com/user-manual-ver-1-0/

[happydaze]

Might be a software limit.  From BFGMiner Zeus driver:

Code:

	info->chips_count = opt_chips_count;
//max clock 381MHz, min clock 200MHz
if(opt_chip_clk>381)
info->chip_clk = 381;
else if(opt_chip_clk<200)
info->chip_clk = 200;
else
info->chip_clk = opt_chip_clk;

I don't know if we override that when setting the clk speed.

and read count is slightly more than 3/4  (doc indicates it was 3/8 at some point)

Code:

info->read_count = info->read_count*0.76;

EDIT:  I don't see max clock & min clock in cgminer driver

[nst6563]

call me crazy (and many do)...but that looks like it's hard setting 381 as a max....which would explain why 340mhz gives 1.4mhs....354 gives 1.51mhs...and for whatever reason...500mhz gives 1.52mhs....

Good find....I'm going to set my clock back from 520 down to 381 and see what the hashrate looks like in the minepeon I've been using.  It does report a higher hashrate than Hashra/Cgminer....  I may make a change to that and recompile as well to see if there are any differences.

Nice find

[J4bberwock]

Might be a software limit.  From BFGMiner Zeus driver:

Code:

	info->chips_count = opt_chips_count;
//max clock 381MHz, min clock 200MHz
if(opt_chip_clk>381)
info->chip_clk = 381;
else if(opt_chip_clk<200)
info->chip_clk = 200;
else
info->chip_clk = opt_chip_clk;

I don't know if we override that when setting the clk speed.

and read count is slightly more than 3/4  (doc indicates it was 3/8 at some point)

Code:

info->read_count = info->read_count*0.76;

EDIT:  I don't see max clock & min clock in cgminer driver

I do think you got it.
Software limit to 381
381*0.7*6=1600

Also, doesn't the nogolden thing could allow higher frequency if disabled?

We need the bfgminer/cgminer devs to work this out. Unfortunately, I'm not registered at litecointalk.

I'm moving from the phone to the laptop to do some testings.

[happydaze]

For the latest Darkwinde BFGMiner release ONLY:

"Check Golden (FROM --nocheck-golden TO --zeus-cg) > Default "false" and Check for Golden Speed currently deactivated"

As many many things have been changed here is the short change log:
- Re-Base to BFGminer branch 4.2.0
- Set new miner version to 4.2.1 to reflect a stable driver version for Zeus
- Bugfix of the difficulty counter (done by jstefanop)
- Stability fix for higher clock and lower HW errors
- Driver rework, 50% done
- Changed command line options for
Chips Count (FROM --chips-count TO --zeus-cc) > Default "6" if you do not specify this parameter
Chips Clock (FROM --ltc-clk TO --zeus-clk) > Default "328" if you do not specify this parameter
Check Golden (FROM --nocheck-golden TO --zeus-cg) > Default "false" and Check for Golden Speed currently deactivated
Debug (FROM --ltc-debug TO --debug) > Related output changed to default debug information layer
No Check Scrypt (--nocheck-scrypt) > removed as deprecated

[nst6563]

I'm crazy so I edited the driver file with a max speed of 1000mhz.  I figured that should give a good enough ceiling for testing.  It's compiling now...hopefully no errors.
I'll give it a quick test run and if it works, I'll throw it on my dropbox and give you guys the link.  If not...well...I tried 

[J4bberwock]

I'm crazy so I edited the driver file with a max speed of 1000mhz.  I figured that should give a good enough ceiling for testing.  It's compiling now...hopefully no errors.
I'll give it a quick test run and if it works, I'll throw it on my dropbox and give you guys the link.  If not...well...I tried 

1000 should be enough 
raspberry or windows build?
How to easily install on Raspberry with hashra controla?
I already logged via SSH to move the limits in the control panel, but that's all.

[nst6563]

Right now it's compiled for the rpi.  
I think to use it with Hashra would require quite a bit of re-work to the Hashra frontend system itself because right now Hashra uses cgminer.  If the api calls are the same I suppose you could just make a backup of the Hashra cgminer and rename bfgminer to cgminer.  I'm actually using Minepeon right now since bfgminer is the default miner for it and it's a 'drop in' replacement at this point.

Also...it seems to be working.  
Clock is a "conservative" 400Mhz right now....hashrate is 1.65mhs-1.76mhs.


Dropbox link to the rpi binary:
https://www.dropbox.com/s/65qcs6vv5qxi3pv/bfgminer-oc


Enjoy...I have to leave for a while...but I upped my clock speed to 450Mhz and will let that run while I'm away.  Feel free to download my compiled version and test.  The only thing I changed was the max clock speed.  Otherwise it's a direct pull from darkwinde's github.

[happydaze]

Let us know what the third column numbers are when you get back. 
The numbers there on mine match the long term pool numbers after it has been running for a while.

[thebotnet]

What do you guys think the best img is for RPI and Furys at the time of this post? it looks like hashra, star miner, and minepeon are the only ones with support right now.

[J4bberwock]

Let us know what the third column numbers are when you get back. 
The numbers there on mine match the long term pool numbers after it has been running for a while.

I'm more interested in the 128mBTC/hour thing. Does that mean 0.128BTC?

I think some numbers aren't reported correctly

[J4bberwock]

What do you guys think the best img is for RPI and Furys at the time of this post? it looks like hashra, star miner, and minepeon are the only ones with support right now.

I have only used hashra so far. Works quite good, easy to setup and use.
I'll try minepeon tomorrow for the oc build of bfgminer.

[nst6563]

Looks like raising the max clock doesn't do much.  Past 381 and the hashrate goes up but the number of accepted shares drops like a rock.

There's something about that 381 ceiling....I'm still out but when I get back I'll see if I can find anything else with that 381 limit.  Looking at code on the phone sucks.  It was bad enough remoting into my machine from the phone to change the speed back to 381.

[J4bberwock]

Looks like raising the max clock doesn't do much.  Past 381 and the hashrate goes up but the number of accepted shares drops like a rock.

There's something about that 381 ceiling....I'm still out but when I get back I'll see if I can find anything else with that 381 limit.  Looking at code on the phone sucks.  It was bad enough remoting into my machine from the phone to change the speed back to 381.

are the work units also decreasing?
they are accepted share, but if you don't have fixed difficulty, the pool might increase dif when hashrate goes up.

[nst6563]

I don't think the work units are decreasing because even if I just change the speed to 382 the number of accepted shares plummets.  At 381 I get accepted shares immediately but at 382 it takes a minute before a share is accepted and then a couple more minutes go by before another share is accepted.  At 381 it's a steady stream of accepted shares.

I've tried two different pools.  Nicehash and manicminer.  Manic lets you set the diff manually and I think nicehash is vardiff if you don't set the diff in the password.  Same behavior for both pools.

[J4bberwock]

in cgminer code, we have something similar

#if 1   
   if(opt_chip_clk>(0xff*3/2)){
      opt_chip_clk = 0xff*3/2;
   }
   else if(opt_chip_clk<2){
      opt_chip_clk = 2;
   }

   clk_reg= (uint32_t)(opt_chip_clk*2/3);
#endif

FF*3/2 is 382.5

and this  

golden_speed_percore = (((opt_chip_clk*2)/3)*1024)/8;