One of my units, the 47 one, keeps bombing out. Just stops hashing. CGminer says it's disabled, re-enabling it doesn't work. Re-starting CGminer does (for a while).
Gonna try the 872, just for the hell of it.
Edit:
OK the other one I updated just bombed out too :/
Edit2:
After observing it for a while it would seem it bombs out when it throttles. Gonna put them back to 832.
Topic: 896 mh/s firmware release - Butterfly Labs - page 9. (Read 18548 times)
This new firmware is either going exactly half as fast, or is triggering a bug in cgminer to make it display exactly half as fast as it should be going. I suspect the latter.
EDIT: cgminer shows 433 mhash/s
EDIT: cgminer shows 433 mhash/s
Are both active leds on or just one in other words is one FPGA on or two?
EDIT: Also, the temps have gone up from 60ish degrees C to around 64, and my kill-a-watt says 119.7 watts (!)
EDIT EDIT: Upgrading to BFGMiner 2.4.1 fixed the display bug. Also, the single is steady at 120 watts, up from 80 or so.
Those extra hashes are really costing more than they are worth aren't they?
This new firmware is either going exactly half as fast, or is triggering a bug in cgminer to make it display exactly half as fast as it should be going. I suspect the latter.
EDIT: cgminer shows 433 mhash/s
EDIT: cgminer shows 433 mhash/s
Are both active leds on or just one in other words is one FPGA on or two?
EDIT: Also, the temps have gone up from 60ish degrees C to around 64, and my kill-a-watt says 119.7 watts (!)
EDIT EDIT: Upgrading to BFGMiner 2.4.1 fixed the display bug. Also, the single is steady at 120 watts, up from 80 or so.
This new firmware is either going exactly half as fast, or is triggering a bug in cgminer to make it display exactly half as fast as it should be going. I suspect the latter.
EDIT: cgminer shows 433 mhash/s
EDIT: cgminer shows 433 mhash/s
Are both active leds on or just one in other words is one FPGA on or two?
You can just use the blink command to figure out which are which. That's what I do.
Doesn't work with my Rev 2 singles. Mine were part of the first batch I suspect.
This new firmware is either going exactly half as fast, or is triggering a bug in cgminer to make it display exactly half as fast as it should be going. I suspect the latter.
EDIT: cgminer shows 433 mhash/s
EDIT: cgminer shows 433 mhash/s
You can just use the blink command to figure out which are which. That's what I do.
OK, now I see the topic has changed. Theres a 872 MH firmware out now too. Maybe that will fix my problem (hehe, I don't think so).
Is the order of the singles listed in cgminer the same order that I put them in my config file? com3, com4, com7,com13 etc?
I don't want to reflash the wrong ones.
Is the order of the singles listed in cgminer the same order that I put them in my config file? com3, com4, com7,com13 etc?
I don't want to reflash the wrong ones.
If you really do have an increased hash rate you will get more shares.
However if the increase means that the device stalls in any way (in FPGA terms that would be throttles or HW errors - in GPU terms that would be HW errors or 'SICK' in cgminer) then of course you may get overall less total Hashes done - that will be the case if the number of hashes lost during stalls is more that the number gained due to the increase hash rate.
This is what is happening with jddebug.
Somewhat related: I've sent an email to BFL to ask for the details of all the commands and specifically also mentioned the ZAX command so I can see if I can write what should be reasonably simple code to do the bitstream update.
If they don't reply (or wont give that particular command details) then I guess we'll just have to look at the EasyMiner code since that is easily reversed according to someone I had a chat with who had already done it but had difficulty understanding the result (I also worked out that it's just .NET 2 also with VB in it so it shouldn't be hard to determine the actual code - but determining the protocol may or may not be easy)
However if the increase means that the device stalls in any way (in FPGA terms that would be throttles or HW errors - in GPU terms that would be HW errors or 'SICK' in cgminer) then of course you may get overall less total Hashes done - that will be the case if the number of hashes lost during stalls is more that the number gained due to the increase hash rate.
This is what is happening with jddebug.
Somewhat related: I've sent an email to BFL to ask for the details of all the commands and specifically also mentioned the ZAX command so I can see if I can write what should be reasonably simple code to do the bitstream update.
If they don't reply (or wont give that particular command details) then I guess we'll just have to look at the EasyMiner code since that is easily reversed according to someone I had a chat with who had already done it but had difficulty understanding the result (I also worked out that it's just .NET 2 also with VB in it so it shouldn't be hard to determine the actual code - but determining the protocol may or may not be easy)
What I need is for cgminer to sense the stalls and report them as hardware errors or something like that. I had one single that I tested with easyminer that was having errors at the 864 so I put it to 832 and now no errors. The others reported NO errors and NO stalls with a medium test of 1000. I have sat and watched for long periods of time (boring) and the red light on the front of my Rev 2 singles never blinks. Of course I found I can not get them to blink with the easyminer blink command either so maybe they are not capable of that.
I'm not doubting what you are saying, just wish I could verify it actually happening somehow.
I'm at 12 hours again no. U = 9.78, 9.82, 10.27, 10.28, 11.10 (832 firmware), 11.30, 11.38, 11.51, 11.65, 11.65
Does way better on average when they are all at 832. I'm considering flashing the ones that are below 11.x to 832.
If you really do have an increased hash rate you will get more shares.
However if the increase means that the device stalls in any way (in FPGA terms that would be throttles or HW errors - in GPU terms that would be HW errors or 'SICK' in cgminer) then of course you may get overall less total Hashes done - that will be the case if the number of hashes lost during stalls is more that the number gained due to the increase hash rate.
This is what is happening with jddebug.
Somewhat related: I've sent an email to BFL to ask for the details of all the commands and specifically also mentioned the ZAX command so I can see if I can write what should be reasonably simple code to do the bitstream update.
If they don't reply (or wont give that particular command details) then I guess we'll just have to look at the EasyMiner code since that is easily reversed according to someone I had a chat with who had already done it but had difficulty understanding the result (I also worked out that it's just .NET 2 also with VB in it so it shouldn't be hard to determine the actual code - but determining the protocol may or may not be easy)
However if the increase means that the device stalls in any way (in FPGA terms that would be throttles or HW errors - in GPU terms that would be HW errors or 'SICK' in cgminer) then of course you may get overall less total Hashes done - that will be the case if the number of hashes lost during stalls is more that the number gained due to the increase hash rate.
This is what is happening with jddebug.
Somewhat related: I've sent an email to BFL to ask for the details of all the commands and specifically also mentioned the ZAX command so I can see if I can write what should be reasonably simple code to do the bitstream update.
If they don't reply (or wont give that particular command details) then I guess we'll just have to look at the EasyMiner code since that is easily reversed according to someone I had a chat with who had already done it but had difficulty understanding the result (I also worked out that it's just .NET 2 also with VB in it so it shouldn't be hard to determine the actual code - but determining the protocol may or may not be easy)
From my experience using CGMiner (and every miner for that matter) if an increase in Clock speed results in a lower share/minute rate (after a few hours, or whatever your 'test window is), it usually means that a voltage increase is required (again, my experiences, YMMV).
So, in summation, if the higher clock on the new firmware is leaving you with less shares/minute, you may have very well found the limitation for your FPGA, where as the lower clock produces more shares and less stress on the FPGA (your miner will report a higher MH/s rate with the higher clocks, but the pool will report slower performance as it is share/minute based stats).
Of course, this was using GPUs and not FPGAs.....so please be gentle when replying to me...hehe
More MH/s doesn't always translate into more shares/minute....
Just a thought...
So, in summation, if the higher clock on the new firmware is leaving you with less shares/minute, you may have very well found the limitation for your FPGA, where as the lower clock produces more shares and less stress on the FPGA (your miner will report a higher MH/s rate with the higher clocks, but the pool will report slower performance as it is share/minute based stats).
Of course, this was using GPUs and not FPGAs.....so please be gentle when replying to me...hehe
More MH/s doesn't always translate into more shares/minute....
Just a thought...
On the 864 firmware after 14 hours I get U of 9.59 to 11.91. 4 have U of 9.x, 2 have 10.x and 4 have 11.x
When they are all using 832 I get U of 11.0 to 11.55. Very tight compared to the 864 firmware.
Wow bad numbers there.When they are all using 832 I get U of 11.0 to 11.55. Very tight compared to the 864 firmware.
OK I'm gonna state a list of numbers but explain them first for the obvious reason
Explanation: over a VERY long period of time the below constant hash rates (MH/s) should give the U: values (Shares/Minute)
Code:
3 digit accuracy ...
MH/s Shares/Minute
823 11.5
817 11.4
808 11.3
800 11.2
795 11.1
The actual calculation is of course simple: Hash x 10^6 x 60 / 2^32
But anyway what that says about your setup is that the 864 is throttling in all cases you are using it - so don't use it on the 9.x and 10.x at all and only on the 11.x if it is giving long term better than 11.4 which is what you should be getting on 832
Looking at my 832 right now (which shows a max of around 826), I have average 818.65 MH/s and 11.49 shares/minute after 1day 22h 37m 54s
818.65 is actually a little higher than I have been having in the previous difficulty but maybe that is difficulty related ...
(that's most likely the reason since block time has increased a bit since the difficulty change - since LP's cause the drop from 826 to 818.65)
Being almost 2 days means that my average hash rate and the U: figure are close
(as is very likely after that long)
It would eventually arrive at 11.44
On the 864 firmware after 14 hours I get U of 9.59 to 11.91. 4 have U of 9.x, 2 have 10.x and 4 have 11.x
When they are all using 832 I get U of 11.0 to 11.55. Very tight compared to the 864 firmware.
When they are all using 832 I get U of 11.0 to 11.55. Very tight compared to the 864 firmware.
I'm most familiar with cgminer. Other miners may refer to shares per minute differently. For cgminer its called U.
U is shares per minute.
wtf
What is U?
Hash rate from a pool is so variable it's difficult to say. I'll see if there's any obvious trend over a few days.
just flashed one of mine, seems to be working just fine.
The temps of my 4 units are: 53, 57, 42 & 52. I flashed the 41, and it went up to 47. Hashing from 825 to 856.
Respectable.
The temps of my 4 units are: 53, 57, 42 & 52. I flashed the 41, and it went up to 47. Hashing from 825 to 856.
Respectable.
Does the pool you use report your hash rate as increased? I have reflashed back to 832 and then back to 864 again. I get much better pool reported rates and U when I am at 832 than when I am at 864. I can not understand it really. the hash rate reported by cgminer is correct for each firmware but the actual performance is worse at the higher hash rate.
Jump to: