Topic: Fury/Blizzard tuning and mods - page 38. (Read 115281 times)
That looks like the max speed is set to 382.5
in cgminer code, we have something similar
FF*3/2 is 382.5
and this
Quote
#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
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
Quote
golden_speed_percore = (((opt_chip_clk*2)/3)*1024)/8;
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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
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.
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
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
For the latest Darkwinde BFGMiner release ONLY:
"Check Golden (FROM --nocheck-golden TO --zeus-cg) > Default "false" and Check for Golden Speed currently deactivated"
"Check Golden (FROM --nocheck-golden TO --zeus-cg) > Default "false" and Check for Golden Speed currently deactivated"
Quote
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
- 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
Might be a software limit. From BFGMiner Zeus driver:
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)
EDIT: I don't see max clock & min clock in cgminer driver
I do think you got it.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;
//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
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.
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
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
Might be a software limit. From BFGMiner Zeus driver:
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)
EDIT: I don't see max clock & min clock in cgminer 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;
//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
here's the "Zeus scrypt chip’s software implementation" doc http://zeusminer.com/user-manual-ver-1-0/
*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:
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:
Quote
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.
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"
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.
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.
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.
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.
Jump to: