896 mh/s firmware release - Butterfly Labs

[P_Shep]

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.

Edit:
Tell a Lie, it wasn't 41 before it was 46, so temp hasn't really changed.

[1714899202]

1714899202

[1714899202]

1714899202

[jddebug]

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.

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.

[P_Shep]

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.

[bitpop]

What is U?

[P_Shep]

What is U?

Female sheep, init?

[bitpop]

wtf

[P_Shep]

 

U is shares per minute.

[jddebug]

I'm most familiar with cgminer. Other miners may refer to shares per minute differently. For cgminer its called U.

[jddebug]

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.

[kano]

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.
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

Now the MH/s number spacing is not exactly in the middle of each range they just happen to land where I expected them to land.
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

[bitlane]

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...

[kano]

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)

[jddebug]

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)

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.

[jddebug]

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.

[Cablez]

You can just use the blink command to figure out which are which.  That's what I do.

[rjk]

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

[jddebug]

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.

[Cablez]

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

Are both active leds on or just one in other words is one FPGA on or two?

[rjk]

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

Are both active leds on or just one in other words is one FPGA on or two?

Both on, all working AOK, Easyminer ran a successful short diagnostic saying 870 mhash/s, pool shows full speed, so must be a miner bug. Actually, I am using bfgminer 2.3.6, so maybe I will upgrade to the latest. Not sure how much difference there is in the display code for speed between bfgminer and cgminer.

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.

[jddebug]

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

Are both active leds on or just one in other words is one FPGA on or two?

Both on, all working AOK, Easyminer ran a successful short diagnostic saying 870 mhash/s, pool shows full speed, so must be a miner bug. Actually, I am using bfgminer 2.3.6, so maybe I will upgrade to the latest. Not sure how much difference there is in the display code for speed between bfgminer and cgminer.

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?