One thing I noticed was the almost instant heat on the board when I had it out of the enclosure to test voltage. It was not even hashing. I didn't measure the heat or anything but you could notice it.
Another thing I notice is how porous the the pcb is. Heatsink paste just oozes up through every hole. Your earlier advice to use non conductive paste is the only way to go.
Topic: Fury/Blizzard tuning and mods - page 36. (Read 115281 times)
It's the way the chips were designed actually. They were designed to dissipate heat through the bottom of the chips which is why the heatsink portion of the case makes contact with the backside of the circuitboard (albeit a bit poorly...they should have either used a bit more thermal paste or a decent quality thermal pad like the Gridseed units). This is where the majority of the heat will be dissipated so that's why the tops of the chips were left untouched.
I agree on the poor design....ideally they should have made a heatsink design which sandwiched both sides and was clamped or bolted together by the fan bolts. Gridseed did it. Video cards do it. Many industrial applications do it that way as well. But it all boils down to compromising performance vs cost.
I agree on the poor design....ideally they should have made a heatsink design which sandwiched both sides and was clamped or bolted together by the fan bolts. Gridseed did it. Video cards do it. Many industrial applications do it that way as well. But it all boils down to compromising performance vs cost.
I think you'll like the cooling 
The second fan is pumping air into the chamber. There's a really good flow of air out of both open ends.
The 3rd hashrate number has climbed to 1.55Mh/s at 2 hours running.
The second fan is pumping air into the chamber. There's a really good flow of air out of both open ends.
The 3rd hashrate number has climbed to 1.55Mh/s at 2 hours running.
I like it. I put these on the chips: http://www.amazon.com/Cosmos-Aluminum-Cooling-Heatsinks-cooler/dp/B007XACV8O/ref=sr_1_1?ie=UTF8&qid=1403016691&sr=8-1&keywords=heatsinks
They come with thermal adhesive already so it's an easy way to add more cooling. What I don't get with these is why they didn't have the heatsink make an active connection with the top of the chips. I mean they did it this way because it was cheaper of course but from a cooling perspective it's a bad design.
I'm also almost sure that the BPCLK pin on the chip is there for something related, directly or not, to the 382 clk limit
Back-Plane-Clock? Google wasn't very helpful.
Is it an input or an output? It might only be enabled in testmode/bypass. A full datasheet for the chip would be very helpful, without that we're stumbling in the dark.
It does look like Zeus did not design the device with much scope for overclocking in mind, given the poor use of the 8 bit clock speed configuration field of the command packet (why didn't they scale the clock by a factor of 2, rather than 2/3?).
I expected Bypass clock or Boosted Power clock
As for the best power/ hash overclocked, it looks like simple changing the 9.1 resistor with a 8.2 can do the trick. I currently have low HW errors with clock at 381 and 1.35v
Power draw is 50watt
I'm also almost sure that the BPCLK pin on the chip is there for something related, directly or not, to the 382 clk limit
Back-Plane-Clock? Google wasn't very helpful.
Is it an input or an output? It might only be enabled in testmode/bypass. A full datasheet for the chip would be very helpful, without that we're stumbling in the dark.
It does look like Zeus did not design the device with much scope for overclocking in mind, given the poor use of the 8 bit clock speed configuration field of the command packet (why didn't they scale the clock by a factor of 2, rather than 2/3?).
I might go ahead with the cooling mods on my other Fury today if I have time.
The overvolted & double fan Fury handles the heat much better. A temperature probe touched to one heat sink measures 35C. Air coming out of the chamber 22.5C. The unmodded Fury chip temp can reach 50C at 342 clk.
Do we know for sure what the minimum voltage is required for 382 clk 1.5+Mh/s?
If these chips ever hit 300kh/s then Zeus used a different driver. We now know that Zeus could not hit 300kh/s with the driver they released. I'm keeping my fingers crossed hoping we get a breakthrough.
The overvolted & double fan Fury handles the heat much better. A temperature probe touched to one heat sink measures 35C. Air coming out of the chamber 22.5C. The unmodded Fury chip temp can reach 50C at 342 clk.
Do we know for sure what the minimum voltage is required for 382 clk 1.5+Mh/s?
If these chips ever hit 300kh/s then Zeus used a different driver. We now know that Zeus could not hit 300kh/s with the driver they released. I'm keeping my fingers crossed hoping we get a breakthrough.
I'm currently experimenting with 8.2k - 10k resistor pair
1.31v
47watt
I'm also almost sure that the BPCLK pin on the chip is there for something related, directly or not, to the 382 clk limit
I might go ahead with the cooling mods on my other Fury today if I have time.
The overvolted & double fan Fury handles the heat much better. A temperature probe touched to one heat sink measures 35C. Air coming out of the chamber 22.5C. The unmodded Fury chip temp can reach 50C at 342 clk.
Do we know for sure what the minimum voltage is required for 382 clk 1.5+Mh/s?
If these chips ever hit 300kh/s then Zeus used a different driver. We now know that Zeus could not hit 300kh/s with the driver they released. I'm keeping my fingers crossed hoping we get a breakthrough.
The overvolted & double fan Fury handles the heat much better. A temperature probe touched to one heat sink measures 35C. Air coming out of the chamber 22.5C. The unmodded Fury chip temp can reach 50C at 342 clk.
Do we know for sure what the minimum voltage is required for 382 clk 1.5+Mh/s?
If these chips ever hit 300kh/s then Zeus used a different driver. We now know that Zeus could not hit 300kh/s with the driver they released. I'm keeping my fingers crossed hoping we get a breakthrough.
Can anyone recommend some quiet fans that will keep stock Blizzards/Fury's cool? The ones that they come with are just too noisy.
Thanks
Thanks
you can check this site.(you can buy elsewhere, I never bought from them, simply using the tables).
http://www.frozencpu.com/cat/l1/g36/Fans.html?id=g4YYFbNX
edit, it will be better with the link
Stock Fury/Blizzard fans are 80mm, 25mm high.
They are not cheap. another way to do it cheaper is to use a 60mm fan blowing through 2 Furys assembled as a blade.
Only one fan to buy and better cooling this way.
Can anyone recommend some quiet fans that will keep stock Blizzards/Fury's cool? The ones that they come with are just too noisy.
Thanks
Thanks
Add to your command line: --zeus-clk-override
and you can set any clock you like with "--zeus-clk". This is done on your own risk
and you can set any clock you like with "--zeus-clk". This is done on your own risk
That isn't going to work as you expect ...
Code:
if (opt_chip_clk_override)
{
info->chip_clk = opt_chip_clk;
applog(LOG_ERR, "Clock override to %iMHz", info->chip_clk);
}
clk_reg= (uint32_t)(info->chip_clk*2/3);
clk_header = (clk_reg<<24)+((0xff-clk_reg)<<16);
sprintf(clk_header_str,"%08x",clk_header+0x01);
memcpy(golden_ob2,clk_header_str,8);
{
info->chip_clk = opt_chip_clk;
applog(LOG_ERR, "Clock override to %iMHz", info->chip_clk);
}
clk_reg= (uint32_t)(info->chip_clk*2/3);
clk_header = (clk_reg<<24)+((0xff-clk_reg)<<16);
sprintf(clk_header_str,"%08x",clk_header+0x01);
memcpy(golden_ob2,clk_header_str,8);
The above assumes that clk_reg is an 8 bit value. Setting it > 255 (as is the case with opt_chip_clk > 382) makes a complete wreck of the bit twiddling when setting the 16 bit clk_header value (which must consist of an 8 bit value paired with it's one's complement). Result: likely to be ignored by the asic (so the clock just remains at it's bootup value). I'll do a worked example shortly (watch this space). Here you go ...
Code:
#include "stdio.h"
#include "stdlib.h"
int main(int argc, char *argv[])
{
if (argc < 2) return 1;
unsigned int chip_clk = atoi(argv[1]);
unsigned int clk_reg = chip_clk*2/3;
unsigned int clk_header = (clk_reg<<24)+((0xff-clk_reg)<<16);
printf("%08x\n",clk_header+0x01);
return 0;
}
C:\Tmp>clock 381
fe010001
C:\Tmp>clock 382
fe010001
C:\Tmp>clock 383
ff000001
C:\Tmp>clock 384
ffff0001
C:\Tmp>clock 385
ffff0001
C:\Tmp>clock 386
00fe0001
C:\Tmp>clock 387
01fd0001
#include "stdlib.h"
int main(int argc, char *argv[])
{
if (argc < 2) return 1;
unsigned int chip_clk = atoi(argv[1]);
unsigned int clk_reg = chip_clk*2/3;
unsigned int clk_header = (clk_reg<<24)+((0xff-clk_reg)<<16);
printf("%08x\n",clk_header+0x01);
return 0;
}
C:\Tmp>clock 381
fe010001
C:\Tmp>clock 382
fe010001
C:\Tmp>clock 383
ff000001
C:\Tmp>clock 384
ffff0001
C:\Tmp>clock 385
ffff0001
C:\Tmp>clock 386
00fe0001
C:\Tmp>clock 387
01fd0001
Note how clocks above 383 no longer meet the specification ...
Quote
⦁ Command packet
This packet ask the chip to work at a certain Frequency and Difficulty, to figure out a scrypt work’s right nonce.
Freqcode(1 byte) + Freqcode’s complement (1 byte) + Diff_code(2 bytes) + Scrypt_work(80 bytes)
⦁ Freqcode and Freqcode’s complement
The chip’s Freq(Mhz) = Freqcode*1.5
If you want chip work at 300Mhz:
Freqcode = 200 = 0xC8
Freqcode’s complement = 0xFF – 0xC8 = 0x37
This packet ask the chip to work at a certain Frequency and Difficulty, to figure out a scrypt work’s right nonce.
Freqcode(1 byte) + Freqcode’s complement (1 byte) + Diff_code(2 bytes) + Scrypt_work(80 bytes)
⦁ Freqcode and Freqcode’s complement
The chip’s Freq(Mhz) = Freqcode*1.5
If you want chip work at 300Mhz:
Freqcode = 200 = 0xC8
Freqcode’s complement = 0xFF – 0xC8 = 0x37
Aloa,
as promised I implemented an override for the 381MHz cap and pushed it to git: https://github.com/Darkwinde/bfgminer.git
Add to your command line: --zeus-clk-override
and you can set any clock you like with "--zeus-clk". This is done on your own risk
Example Linux:
Have fun and looking for feedback if everything works fine.
Darkwinde
as promised I implemented an override for the 381MHz cap and pushed it to git: https://github.com/Darkwinde/bfgminer.git
Add to your command line: --zeus-clk-override
and you can set any clock you like with "--zeus-clk". This is done on your own risk
Example Linux:
Code:
./bfgminer --scrypt --zeus-cc 6 --zeus-clk 400 --zeus-clk-override -S zeus:/dev/ttyUSB1 -S zeus:/dev/ttyUSB0 -c /opt/minepeon/etc/miner-zeus.conf
Have fun and looking for feedback if everything works fine.
Darkwinde
That's a Week 1. The GAWMiners logo was upside down on Week 1's. They must have known I'd stand it on it's side.
I have a Week 3 also. Logo is right side up when the Fury is laying flat after Week 1.
I going to run jstefanop's BFGMiner 4.0 overnight. I'm not 100% sure but I think that one allows 382 clk.
Can't wait to get 24hr poolside number.
I have a Week 3 also. Logo is right side up when the Fury is laying flat after Week 1.
I going to run jstefanop's BFGMiner 4.0 overnight. I'm not 100% sure but I think that one allows 382 clk.
Can't wait to get 24hr poolside number.
I think you'll like the cooling
The second fan is pumping air into the chamber. There's a really good flow of air out of both open ends.
The 3rd hashrate number has climbed to 1.55Mh/s at 2 hours running.
The second fan is pumping air into the chamber. There's a really good flow of air out of both open ends.
The 3rd hashrate number has climbed to 1.55Mh/s at 2 hours running.
Looking very cool...
Which week delivery is it...I am still waiting...
ZiG
I think you'll like the cooling
The second fan is pumping air into the chamber. There's a really good flow of air out of both open ends.
The 3rd hashrate number has climbed to 1.55Mh/s at 2 hours running.
The second fan is pumping air into the chamber. There's a really good flow of air out of both open ends.
The 3rd hashrate number has climbed to 1.55Mh/s at 2 hours running.
I measured Zeus R9 R10 R11 on my board
R11 is in the correct spot on my Week 1 GAW Fury
R9 measures 4.93K on the board
R10 measures 4.92K on the board
I checked like 5 times and cross checked my multimeter with several spare resistors.
R10 = ( R9 * Vfb ) / ( Vout - Vfb )
4.92 = ( 4.93 * 0.591 ) / ( 1.183v - 0.591 )
Looks like mine is slightly under volted at 1.183v (I did not measure the voltage)
I'll have to check my other Fury (Week 3).
edit:
Almost the same on the other Fury
R11 .906k
R10 4.91k
R9 4.91k
so 1.182v
R11 is in the correct spot on my Week 1 GAW Fury
R9 measures 4.93K on the board
R10 measures 4.92K on the board
I checked like 5 times and cross checked my multimeter with several spare resistors.
R10 = ( R9 * Vfb ) / ( Vout - Vfb )
4.92 = ( 4.93 * 0.591 ) / ( 1.183v - 0.591 )
Looks like mine is slightly under volted at 1.183v (I did not measure the voltage)
I'll have to check my other Fury (Week 3).
edit:
Almost the same on the other Fury
R11 .906k
R10 4.91k
R9 4.91k
so 1.182v
You will have to make measurements on components removed from the board. Read the value written on them. I'm almost sure you have 9.3k and 9.1k too.
You're right. I didn't remove the resistors but ran the markings through an online decoder.
912 = 9.1k
93A = .909k (909 Ohm)
03C = 10.5k
Looks like the reference resistor is 10.5k
I figured I could get 1.4v if I paralleled a 47.5k with the 9.1k R10. It was the only resistor I had on hand that could work for the volt mod.
R10 = ( R9 * Vfb ) / ( Vout - Vfb )
7.67 = ( 10.5 * 0.591 ) / ( 1.4v - 0.591 )
47.5k paralleled with 9.1k = 7.64
Measured voltage on the board at 1.4v
I'm running it now with an extra cooling fan and cut up heatsinks glued to the chips. Clock is 380. 5% HW errors, 67 watts with a second fan. 1 hour running so far.
Local hashrate is steady 1.7mh/s but poolside looks like it would only be 1.46mh/s
Edit:
Looks like it made it to 1.5mh/s after 1 1/2 hours
In the early days of these chips it was thought that they were capable of 300kh/s each.
Remember this:
The current chips might be a completely new design OR performance was limited as the number of chips in each miner grew. Zeus would have had to limit performance to balance power use, hash rate, heat removal etc.
300 kh/s would need a clock rate of approx 430. 6 chips could potentially hit 1.8mh/s.
Remember this:
The current chips might be a completely new design OR performance was limited as the number of chips in each miner grew. Zeus would have had to limit performance to balance power use, hash rate, heat removal etc.
300 kh/s would need a clock rate of approx 430. 6 chips could potentially hit 1.8mh/s.
Yes, they were supposed to be 1.2 with 4 chips, but they had to design a new board for 6 chips on the Blizzard.
I guess that cooling and power draw were the issue for them at higher clock.
In the early days of these chips it was thought that they were capable of 300kh/s each.
Remember this:
The current chips might be a completely new design OR performance was limited as the number of chips in each miner grew. Zeus would have had to limit performance to balance power use, hash rate, heat removal etc.
300 kh/s would need a clock rate of approx 430. 6 chips could potentially hit 1.8mh/s.
Remember this:
The current chips might be a completely new design OR performance was limited as the number of chips in each miner grew. Zeus would have had to limit performance to balance power use, hash rate, heat removal etc.
300 kh/s would need a clock rate of approx 430. 6 chips could potentially hit 1.8mh/s.
I think it's do-able....but the question would be is how much more power would it require? And would that increased power consumption be worth it? For those that don't pay for electricity...maybe...
In the early days of these chips it was thought that they were capable of 300kh/s each.
Remember this:
The current chips might be a completely new design OR performance was limited as the number of chips in each miner grew. Zeus would have had to limit performance to balance power use, hash rate, heat removal etc.
300 kh/s would need a clock rate of approx 430. 6 chips could potentially hit 1.8mh/s.
Remember this:
The current chips might be a completely new design OR performance was limited as the number of chips in each miner grew. Zeus would have had to limit performance to balance power use, hash rate, heat removal etc.
300 kh/s would need a clock rate of approx 430. 6 chips could potentially hit 1.8mh/s.
Hi all,
some guys of the litecointalk.org forum pointed to your great topic. So as I think you have some requirements to be reflected by my BFGminer port I come over to collect them.
And here I am. So first thing you like to remove the clock speed barrier right?
Some addendum to the initial posting:
> Tech Topic for the BFGminer port opened yesterday: https://litecointalk.org/index.php?topic=20477.0
> Link to Sources: https://mega.co.nz/#F!DRE0EDCK!aPxX5hZ2S_2UBTA14sU3ow
> Regarding Minepeon you can set me as one of the contact persons, as I am working with Neil and I am one of the technical responsibilities in the according forum: http://minepeon.com/forums/index.php
Regards
Darkwinde
some guys of the litecointalk.org forum pointed to your great topic. So as I think you have some requirements to be reflected by my BFGminer port I come over to collect them.
And here I am. So first thing you like to remove the clock speed barrier right?
Some addendum to the initial posting:
> Tech Topic for the BFGminer port opened yesterday: https://litecointalk.org/index.php?topic=20477.0
> Link to Sources: https://mega.co.nz/#F!DRE0EDCK!aPxX5hZ2S_2UBTA14sU3ow
> Regarding Minepeon you can set me as one of the contact persons, as I am working with Neil and I am one of the technical responsibilities in the according forum: http://minepeon.com/forums/index.php
Regards
Darkwinde
Yes...the clock speed barrier is a real pain in the ass. These things can handle more than "just" 381Mhz. Other than the clock speed I can't think of anything...you do an awesome job with fixing what the manufacturer shouldn't have left a mess in the first place. I'm hoping the limit can be lifted via software...otherwise it looks like we're on the way for a hardware based clock boost.
Also - for whatever reason bfgminer 4.2.1 has an "issue" with manicminer.in pool. I can point bfgminer to nicehash and things work ok. Point it to manic and nothing happens. No accepted shares, no hashrate, nothing. It's very odd. I've cloned and compiled from your git source and the same thing happens. Like a moron I didn't do any debug logs though. I'll see if I can get those today if you need them.
Ok next release I will cut it off by an override flag so everybody can configure it on its own.
regarding manic i can test it with my blizzards. Nicehash causes me really high rejects multipool.us not, so I also have to look into it why one pool is stable and the other not...but be patient I am no HAL developer or hardware near developer. I am learning by doing
Hi all,
some guys of the litecointalk.org forum pointed to your great topic. So as I think you have some requirements to be reflected by my BFGminer port I come over to collect them.
And here I am. So first thing you like to remove the clock speed barrier right?
Some addendum to the initial posting:
> Tech Topic for the BFGminer port opened yesterday: https://litecointalk.org/index.php?topic=20477.0
> Link to Sources: https://mega.co.nz/#F!DRE0EDCK!aPxX5hZ2S_2UBTA14sU3ow
> Regarding Minepeon you can set me as one of the contact persons, as I am working with Neil and I am one of the technical responsibilities in the according forum: http://minepeon.com/forums/index.php
Regards
Darkwinde
some guys of the litecointalk.org forum pointed to your great topic. So as I think you have some requirements to be reflected by my BFGminer port I come over to collect them.
And here I am. So first thing you like to remove the clock speed barrier right?
Some addendum to the initial posting:
> Tech Topic for the BFGminer port opened yesterday: https://litecointalk.org/index.php?topic=20477.0
> Link to Sources: https://mega.co.nz/#F!DRE0EDCK!aPxX5hZ2S_2UBTA14sU3ow
> Regarding Minepeon you can set me as one of the contact persons, as I am working with Neil and I am one of the technical responsibilities in the according forum: http://minepeon.com/forums/index.php
Regards
Darkwinde
Yes...the clock speed barrier is a real pain in the ass. These things can handle more than "just" 381Mhz. Other than the clock speed I can't think of anything...you do an awesome job with fixing what the manufacturer shouldn't have left a mess in the first place. I'm hoping the limit can be lifted via software...otherwise it looks like we're on the way for a hardware based clock boost.
Also - for whatever reason bfgminer 4.2.1 has an "issue" with manicminer.in pool. I can point bfgminer to nicehash and things work ok. Point it to manic and nothing happens. No accepted shares, no hashrate, nothing. It's very odd. I've cloned and compiled from your git source and the same thing happens. Like a moron I didn't do any debug logs though. I'll see if I can get those today if you need them.
Jump to: