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

After 900 accepted shares, my U seems to be a little higher, but I'm going to leave it for a while.

BTW, why does cgminer occasionally (after about 50K shares) stop sending work to the BFL box? It stays running and shows longpolls as they come in, but no shares...

Oh, you're right, my mistake.

For the record, I'm currently trying a higher baud rate as well. I'm on linux, before the change it was at 9600, hashing at 883 MHash/s with a stable U between 12.32 and 12.34.

Changing the baud rate to 115200 without restarting cgminer did not seem to change anything. Maybe cgminer sets the baud rate upon connection? Or maybe I didn't wait long enough.

I restarted cgminer, and I'm leaving it running tonight to see if it's better. If it really helps, then reducing the time from 80ms to 20ms should increase the hash rate to ~893 MHash/sec (= 883 * 5280/5220)

Early results: It does seem to be somewhat higher, it's fluctuating between 885 and 895 MHash/s now. Theoretical maximum, here I come!

I upped the baud rate and I am now getting U12.22. I was getting U11.73 before so I gained U.49. I am pretty happy with that

Hm, I guess we don't see the full picture.

At Linux side the buadrate can be set with setserial (like kano said, it is not explicitly set by the bitforce driver):
and read it back with

I can set all known rates from 75Bd to 3MBd while cgminer is working without any noticable effect. Either the Linux driver does not support setting or the chip is hardwired to operate at a defined speed. But it is obvious that it is not operating at 75Bd, since that would exceed cycle time.

The FTDI chip used is FT232RL (datasheet).

I just checked, mines running at 115.2K by default.

If you change it then start cgminer it will not stay changed so far if you set it with cgminer running it seemed to stay changed. Will Edit later if if it changes or that it chaned or did not change.
Edit: Win7 64 bit, 230400 will run and seems to stay changed after unit is running at least over 10 mins. Mine defaults to 9600. Variations on top of variations.

U: values don't "jump up" tiny amounts in any way related to small changes like this.
Maybe after a few days you "might" find it gets stable at a higher rate (if you stop and start it again)

My miner says 818.3 MH/s at the moment which should be 11.43 over very long term.
At the moment it's been running for ~40 hours and reads 11.42 (though I did notice it around 11.48 about 12 hours ago)
After over 2 weeks, last time I ran it non-stop that long, it did seem to settle on an 11.4 value
The summary said 11.4 on both a 403.5 hour run 818.8MH/s and a 70.75 hour run 817.8MH/s
(the summary is only 1 decimal point so it could have been anywhere form 11.35 to 11.44 but I'm pretty sure it was actually 11.44 when I stopped the 403.5 hour run - which 818.8 is 11.44)

Regarding serial speeds:
In the Icarus code it already specifically uses 115200, but the bitforce code doesn't specifically change the speed so it may? be possible to set the serial speed before starting cgminer - though I don't know how you do that or if it will stay on whatever value you set.

Both boards transfer 60 bytes of hash data
BFL has extra overhead on top of that: 3 bytes send, 3 reply, 60 bytes send, (3 reply - but I presume it has already started processing?)
So BFL is 66 bytes
66x8 bit bytes at 115200 is 4.58ms
66x8 bit bytes at 9600 is 55ms (yes that's big ...)
Of course, if there is more than just the 8 bit bytes (stop bits etc) then it is even longer ...

Sounds good!
Anyone else hooked up to windows who can test it?

To tell the truth it is still to early to be definitive but so far I do see some better than average U values now.  Time will tell if its real.

It should be very easily detectable on a single that doesn't throttle. Your U value would jump up 0.14/m.

Edit: Of course the difference won't happen on a throttling single; it will just throttle more often now.

Subtle, yes. 

Let's see ... if the USB rate was increased from 9600 baud to 38400, that would reduce the USB overhead to 1/4 of what it was before. And according to zefir, at 9600 baud it was about 80ms (polling is done at 10ms, which is independent of USB baud rate). So you *should* see an overhead of only ~20ms-25ms now.

That translates to an extra 10Mhps or so (about 1%-1.5%). Not sure if that would be detectable over the typical short-term variance we see reported in cgminer.

Ok, let me change the rate across the board and I will let you know if there is any subtle difference.

My understanding is that EasyMiner only measures the raw calculation rate (i.e. without any overhead effect), but you might see an increase in cgminer's reported rate if the USB speed has truly increased. Are you able to check that, Cablez?

I am able to change the b/s rate in windows to what you specified (38.4 8N1). Started up easyminer and compared the modified one vs a default one and I see no changes.  Is there something else I should check for?

Ill double check when I get home.  I tested all of the faster firmwares that were out at the time my single arrived.  I see they have added even faster ones since I last checked.  I'll post some screen shots if my memory has served me well. 

Are you really sure you flashed the 864 FW? 857 MH/s would otherwise perfectly match 872 MHz. If you're sure, what OS and miner SW are you using?

The pre-fetch and caching mechanisms has to be implemented by BFL. What can be tweaked SW wise is to reduce the polling time, but this might potentially save only some milliseconds per cycle.

What I am more curious about is the unusually low baud rate used for communication. 9600 Bd was used two decades ago, if we could use today's common rates of 115.2 kBd, that would be a huge improvement potential.

To you Windows folks: could you maybe check if it is possible to change the related COM port settings before you run EasyMiner to e.g. 38.4 kBd 8N1 and check whether they change during and after EasyMiner accessing the BFLS? Thanks.

That is the average over a day +.  The only time the thing comes off of 857 is when the long poll hits from the pool. 

But not long term, or? The values averaged over the last 5s might fluctuate (I even see higher values than clock rate now and then), but if you let the device run for a day or so, the hash rate should settle to the values I gave - at least that's what I see with my Linux driven BFLS.

On the other hand, there's a number of us who are running 896 in cool environments are getting 883 MHash/sec without throttling. Until BFL releases even faster firmwares, we could benefit from this improvement.