Topic: Butterfly Labs - Bitforce Single and Mini Rig Box - page 18. (Read 186899 times)

This is excellent information; thanks, zefir. I see that the actual polling interval is 10ms, but the other overheads brings it up to 80ms. An 80ms overhead per nonce cycle is closer to a 1.5%-2% overhead.

Yes, I also wouldn't worry too much about tweaking this inefficiency out. If a non-throttling 816 unit throttles with 832 firmware (a 2% increase), then that same 816 unit would likely throttle if the 80ms idle time was eliminated.

I get 857 and some change mh/s with the 864 firmware.

Hi Epoch,

I had similar estimates in a different thread and did some further digging to get a more solid understanding.

Bottom line is, if the BFLS is not throttling, you will get some long term hash rate of (system clock - 14) MH/s, that is a device with 864MHz firmware will deliver 850MH/s at most. The loss is taken for the communication to/from device. Converting it down based on a nonce time of ~5.2s, the idle time is around 80ms per cycle. That matches the real numbers for cgminer operation, that are:

• baudrate of 9600 => ~1ms (937.5 us exactly) to read/write a single character
• submitting work: write ">>>>>>>>[32 bytes midstate][last 12 bytes of block header]>>>>>>>>" => 56ms
• polling for shares: after work submission, first wait 4.5 seconds, then poll every 10ms by writing "ZFX" => 8ms average delay
• reading shares: read "NONCE-FOUND:1234ABCD,2468EFAB,1111BBBB" => (11 + #nonces * 9) ms => 18.7ms average

One could maybe implement some pre-fetching of work and caching of nonces functionality to add the potential 12MH/s - but at the same time maybe the FPGAs need this small idle time to cool down a little bit.

Thanks Epoch, super succinct as always.   That was kind of what I had figured. 1% doesn't sound so bad until the timeline gets sufficiently long.

I believe BFL addressed this question elsewhere. But basically when going through the full nonce range (2^32, of 4 billion hashes), a Single runs at its full speed of 832Mhps. It is able to do this in 5.16 seconds. After that it stops until the mining software give it another work unit. So the question is, how long does it take for the mining software (e.g. cgminer) to give it more work? Well, the miner needs to POLL the USB port to see when the Single is done, it needs to collect any difficulty-1 solutions found (typically 1), then it needs to send the next work. I believe the polling interval in cgminer is on the order of 100ms. The USB link to the Single seems to be only 9600 baud, which will add many more milliseconds to the sending of commands, collecting results, and feeding more work.

Let's assume the average delay between polls is 50ms (100ms polling interval means an average of 50ms delay); we'll assume the additional delay due to sending/receiving/processing commands is negligible. So the Single is running for 5.16 seconds at a speed of 832, then sitting 'idle' for 0.05 seconds. Another way of looking at this is that it takes (5.16+0.05) seconds to run through the entire nonce range. That would give it an effective speed of only 824Mhps, not 832.

This happens to be what cgminer reports for a full-bore 832-firmware Single (my 832-speed Singles are reported as 825 by cgminer). Perhaps my assumptions are a bit off, perhaps the polling interval is faster than 100ms ... maybe it is only 10ms. But then the overhead in transferring the serial commands becomes more significant and we're basically back to the same situation again.

You asked why EasyMiner reports a higher rate than cgminer. This is why. I think you already suspected as much. EasyMiner reports the raw rate only. That is, the rate at which a full 2^32 hash range is calculated at. It does NOT take into account the overhead of polling and command transfer over a longer period. cgminer does take this into account, which is why its reported rate will be lower.

It may be possible for BFL to tweak the firmware such that the next work could be queued in the device before it has completed its current work; that would essentially eliminate the polling delay and allow the device to operate at 100% efficiency. Currently that is not the case; we lose about 1% due to the polling and USB communication overhead.

That is very good information Epoch, I had come up with something similar for one my throttling 864 units. It is better to leave it at the higher firmware.

I was curious though, what is the reason why the test rates (seen in easyminer) are never achieved when in real use (cgminer in this instance)?  Is this network related as in getting work efficiently?

Not trying to nitpick here, but BFL advertises their specs as 832Mhps +/- 10% running variance. That's a range of 749 to 915 Mhps.

816Mhps is well within 10%. In fact, all of BFL's released firmware to date is within this range.

For my Singles, I have flashed them DOWN to an average of 808Mhps (some run 832 firmware, a few need 768, but most run 800-816 firmware). In my relatively hot environment (typically 27C or 81F), replacing the stock/loud fans with aftermarket/quiet fans, I have found that this is what I need to prevent throttling.

808 sounds like a big decrease from 832, but it is only 3%. Hardly noticeable. Yes I would prefer that they run at 832 ... or 896 for that matter ... but BFL has claimed nothing beyond 832 +/- 10%, so I'm quite satisfied running 808.

As a side-note, if your 832 Singles are throttling and you are considering to flash them down to 816, you should do it only if your unit throttles more than once every 13 minutes. In other words, if it throttles more often than once per 13 minutes, you should flash it down. If it throttles less often than this, you are better off leaving it at 832 if you want to maximize the overall mining rate.

The calculation goes something like this: The throttle cycle is 15 seconds long. During that time the Single is not calculating anything. So you are losing 15 seconds of mining. In 13 minutes, the non-throttling 816 firmware will calculate 816*13*60 megahashes (636M). The 832 firmware, throttling for 15 seconds during that time, will generate 832*12.75*60 megahashes (636M) which is the same amount.

The same calculation can be run for any of the firmware speeds, to determine exactly when a throttling Single should be flashed down to maximize overall speed. Sometimes you will find that it can make sense to let a Single throttle, as long as it doesn't happen too frequently.

Well that's lame. Another guarantee broken; that of the minimum advertised specs.  
Here's a tip: If the specs aren't up to the minimums, DON'T SHIP IT, send one that actually works.

That being said, will they run the faster ones without issues, JWU42?

All 6 of mine came with 816 firmware

Anyone interested in a road trip to BFL. 
https://bitcointalksearch.org/topic/chicago-roadtrip-to-bfl-facility-85738.

You have to direct your question to BFL.

I guess it's a Q-issue. The singles I received are also not completely identically from a production point of view, every single is unique.
So don't worry too much about that.

My BFL arrived with 814 firmware instead of 832. Should I be concerned? I've upgraded it and ran it all night at 832 and it seems to run fine. I wonder why it shipped out that way?

I have seen no evidence that BF cares about meeting deadlines. My guess is somewhere closer to December. They are probably busy photo shopping the next mini rig pic right now.

If that is the case, then I hope he starts selling them asap!

I am 99.99% sure that O_Shovah made that, and it is on an unmodified single. Note also the IR images which he has shared for all the other FPGAs he owns. I don't know if they have some agreement, though.

If anyone has a turn around time for a repaired unit I am curious how long it took from when you mailed it until you had a unit at your location again?

Also as I see it my unit being unable to actually run the "factory" firmware of 832 and having never run it makes me interested in getting a unit that works correctly. The downside is that repaired I will only make an extra $0.05 per day so if I guess a 10 day turn around time I lose 23.60. I make (expected) 2.36 per day, I would make 2.41 (expected) per day. That means that I would have to use the unit for 472 days at current rates or at least similar to current rates just to get back the delays. This does not include shipping costs. If someone would let me know how their work went maybe it would help me decide what to do.  

Hopefully someone has information on my other post on the last page as well.

After changing some things like the flatness of the heatsink base and the thermal paste to a Thermaltake Thermal compound #AS and only a very small amount per processor. I dropped my temps to where I can now run the 864. Have changed fans to some Vantec Thermal case fans and it is very quiet by compairison. For flatness I used 400 grit sandpaper with the mounting pins out on an orbital sander. Very short bursts and did not entirely remove the machining marks as I know that as deep as they are there are no leaks possible. I washed the heatsink after sanding to remove particles left by metal removal. I assume these changes Heatsink mounting surface and better thermal compound would help others as well. Before alterations I could get sometimes 58C on the 816 after I got 52. I used to throttle to where 864 was hardly better then 816 now it seems to average (over a short 5 hours) to 845.0 I assume it may improve by waiting for 24 or more hours. What I did was slow and careful.

As a side note thermal throttling temperature seems to be dependent on chip, and firmware. My 816 throttled at 65, with 872 it throttles at 56(or some temp higher but the last CGminer temp was 56. This is with a 69 degree F airsource and will likely not work for everyone. I really wish these things where factory on the units.

Note there is still a divit where the heatpipes are inserted. I did not want to remove them as the amount of alteration would get iffy.

EDIT: 846.9 average after 17 hours on 864.

Thanks for this.  Have a single that's 10 C higher than all the others.

So is the Mini-Rig ready now ? Your website mentions that initial orders (those placed in January ?) would be shipped at the end of May ?

Mine runs fine till 64 at 65 it throttles. I understand that the chips vary but 10 degrees C seems a bit off. Granted I am in the middle. I guess I got an average board. Mine will not run 864 without throttling in a 69 degree F room with 69 degree F intake temps.
Maybe this will sound too harsh if it does I did not mean whatever was read into it. I believe the easyminer needs to do a better test before saying a flash was successful. For example I have had 0 processors listed after a flash a few times. I have had reported hashrates with too many 0s. I have had power listed that was far above what the normal power for processor lists as. I know there are things that likely can't be tested before you actually run the test but the things I mentioned above did not need a test to see.
PS has anyone had a runaway hashrate on CGminer. For me on several bitstreams I get 4-8Gigahashes reported for one single. 0 Accepted units but still.
PPS I can only get 4 bitstreams to work for me. 808,816, 864, and 872. I have tried plugging in the unit then flashing immediately and flashing after it was running a test or cgminer. Also have flashed bitstream I wanted. tested, power cycled and reflashed ad nauseum. No change for me.
PPPS 832 for me shows a power for second processor of 00A5A5A5. I have no idea if that is too high but on test it immediately says throttle and then 0 nonces found for the test. I hope I am the only one that sees this or that someone knows a way to fix it.

My two singles work fine at 79 degree F. One stock speed, the other one with the second fastest firmware. But they emit a good amount of heat .