Butterfly Labs - Bitforce Single and Mini Rig Box

[kano]

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

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.

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.

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

[Askit2]

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.

[P_Shep]

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

[zefir]

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):

Code:

stty -F /dev/ttyUSBx <baudrate>

and read it back with

Code:

stty -a -F /dev/ttyUSBx

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

[aseldon]

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

[BTCurious]

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)

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!

[rjk]

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

[BTCurious]

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

That seems like a lot. Are you sure it's not just because it cooled down or something?

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

Haven't noticed that yet, personally.

[kano]

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

Read my post above
That change has nothing to do with the baud rate.

Increasing the baud rate from 9600 to 115200 will remove a delay of roughly 50ms per nonce range.
(and that's also assuming that it was running at 9600baud and is now running at 115200baud)
A nonce range takes about 5.16s so that's about ... 1% ... (your change is 5% so clearly unrelated)

Again, U: doesn't mean much unless you've been running for a few days
After an hour it will be within about 10% of the final figure

[wogaut]

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

I'm observing something similar, but not your quoted 50k, in fact it seems pretty random here, I will need to do more logging; had logging off so I wouldn't clutter the Raspberry SD card.

[BTCurious]

Hm, now my hashrate seems the same as before. I'll leave it running for a few days and have a look at the U.

[zefir]

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

Since when do you observe this? One of my BFLS (running at 872) happened to just quit working two times this week. No indication that communication failed or any other log messages from cgminer. The only thing I noticed is the right LED being off, indicating that device is not hashing. Since restarting cgminer makes it work again, I assume it is only communication that hangs.

Before I updated to cgminer-2.4.2 and played with the different firmwares, the BFLS worked for weeks non-stop. Would be a pity if the FW with the higher clock caused  the device idling around two nights

[BFL-Engineer]

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

Since when do you observe this? One of my BFLS (running at 872) happened to just quit working two times this week. No indication that communication failed or any other log messages from cgminer. The only thing I noticed is the right LED being off, indicating that device is not hashing. Since restarting cgminer makes it work again, I assume it is only communication that hangs.

Before I updated to cgminer-2.4.2 and played with the different firmwares, the BFLS worked for weeks non-stop. Would be a pity if the FW with the higher clock caused  the device idling around two nights

The communication protocol on the unit side is rock-solid. Probably it's the cgminer upgrade that
has caused this. The firmware only affects hashing engine and how they work, and does not affect
the MCU on board which handles communication protocol. Most likely this is due to cgminer change.



Regards,
BF Labs Inc.

[zefir]

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

Since when do you observe this? One of my BFLS (running at 872) happened to just quit working two times this week. No indication that communication failed or any other log messages from cgminer. The only thing I noticed is the right LED being off, indicating that device is not hashing. Since restarting cgminer makes it work again, I assume it is only communication that hangs.

Before I updated to cgminer-2.4.2 and played with the different firmwares, the BFLS worked for weeks non-stop. Would be a pity if the FW with the higher clock caused  the device idling around two nights

The communication protocol on the unit side is rock-solid. Probably it's the cgminer upgrade that
has caused this. The firmware only affects hashing engine and how they work, and does not affect
the MCU on board which handles communication protocol. Most likely this is due to cgminer change.



Regards,
BF Labs Inc.

Hey, great you are around.

I'll try with previous cgminer if this happened again.

While you are here, could you give a hint whether changing the FTDI baudrate has any effect on the communication (and idle hashing) time as is discussed above? Just to save us from tapping around in the dark. Thanks.

[BFL-Engineer]

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

Since when do you observe this? One of my BFLS (running at 872) happened to just quit working two times this week. No indication that communication failed or any other log messages from cgminer. The only thing I noticed is the right LED being off, indicating that device is not hashing. Since restarting cgminer makes it work again, I assume it is only communication that hangs.

Before I updated to cgminer-2.4.2 and played with the different firmwares, the BFLS worked for weeks non-stop. Would be a pity if the FW with the higher clock caused  the device idling around two nights

The communication protocol on the unit side is rock-solid. Probably it's the cgminer upgrade that
has caused this. The firmware only affects hashing engine and how they work, and does not affect
the MCU on board which handles communication protocol. Most likely this is due to cgminer change.



Regards,
BF Labs Inc.

Hey, great you are around.

I'll try with previous cgminer if this happened again.

While you are here, could you give a hint whether changing the FTDI baudrate has any effect on the communication (and idle hashing) time as is discussed above? Just to save us from tapping around in the dark. Thanks.

The baud-rate is not used anywhere. It's just a formality.


Regards,
BF Labs Inc.

[zefir]

The baud-rate is not used anywhere. It's just a formality.


Regards,
BF Labs Inc.

Thanks for saving us from wasting more time on this

[Cablez]

Yeah, 12+ hours running and there is no real difference in U from that baud rate change.  Oh well.

[wogaut]

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

Since when do you observe this? One of my BFLS (running at 872) happened to just quit working two times this week. No indication that communication failed or any other log messages from cgminer. The only thing I noticed is the right LED being off, indicating that device is not hashing. Since restarting cgminer makes it work again, I assume it is only communication that hangs.

Before I updated to cgminer-2.4.2 and played with the different firmwares, the BFLS worked for weeks non-stop. Would be a pity if the FW with the higher clock caused  the device idling around two nights

Had the exact same thing, it's fine right now, I'm observing. BTW, I'm running cgminer-v2.4.1-9 under Debian Linux.

[crazyates]

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

Since when do you observe this? One of my BFLS (running at 872) happened to just quit working two times this week. No indication that communication failed or any other log messages from cgminer. The only thing I noticed is the right LED being off, indicating that device is not hashing. Since restarting cgminer makes it work again, I assume it is only communication that hangs.

Before I updated to cgminer-2.4.2 and played with the different firmwares, the BFLS worked for weeks non-stop. Would be a pity if the FW with the higher clock caused  the device idling around two nights

Had the exact same thing, it's fine right now, I'm observing. BTW, I'm running cgminer-v2.4.1-9 under Debian Linux.

A lot of people have been talking about CGMiner 2.4.1 and 2.4.2 not liking to mine with Singles. Any hickup and it just stops hashing. Better to stick with 2.3.6 for now.

[rjk]

Yeah it's harder to track down because I upgraded cgminer (actually bfgminer, but I think its the same code) at the same time as I did a firmware update, so I wasn't 100% sure where the issue might lie.