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

Quote from: wogaut on June 07, 2012, 10:43:42 AM

This happens to me occasionally as well (Win7/64 here), typically once every day or two. Happens in cgminer 2.4.1 and 2.4.2; in the cgminer window the device's hashrate is listed as 'OFF'.

This never happened with 2.3.6; I ran that version for 2 weeks straight without any issue. So I'm also leaning toward it being a cgminer issue introduced in 2.4.1.

In 2.4.1+, devices are disabled (rolling rate is "OFF") when scanhash() returns 0. Check your cgminer log for reasons (all error conditions log error messages). I don't think it is an "issue". What's the point to have a device that cannot hash.

cgminer just handles errors coming from the device and disables the device. That is its error handling.
See nedbert9 post: https://bitcointalk.org/index.php?topic=76208.40

Closing and re-opening/re-initializing the port would probably be a better solution. But disable is simpler and works.

I'll check into the logs tonight to see if they have any further clues ... I don't have any evidence (only observation and comparison to earlier behavior) to know what the root cause of the scanhash() failure is.

I do know that my Singles hashed for 2 weeks solid under 2.3.6 without any failure. Those same Singles have now had 1-2 'OFF' failures every day or two for the past two weeks running 2.4.1 and 2.4.2 in the same environment (same ambient temperature, same host PC, same USB hubs, same cables, same physical location and position).

That observation, plus several posts from other Single users running 2.4.1+, make a reasonably strong case to at least suggest that something may be broken in 2.4.1+.

I've read nedbert's post that you referenced; he is encountering the same problem as being described here. The point is that prior to 2.4.1+, Singles did not spontaneously 'stop hashing'. So I am trying to understand why they would be doing so now ... and, so far, the circumstantial evidence seems to be pointing the spotlight on cgminer 2.4.1+.

I have one Single working now under CGminer 2.4.2 and before 2.4.1 without any problems, but I use Windows Server 2003

crazyates

legendary

Activity: 952

Merit: 1000

Quote from: af_newbie on June 07, 2012, 10:23:42 AM

This happens to me occasionally as well (Win7/64 here), typically once every day or two. Happens in cgminer 2.4.1 and 2.4.2; in the cgminer window the device's hashrate is listed as 'OFF'.

This never happened with 2.3.6; I ran that version for 2 weeks straight without any issue. So I'm also leaning toward it being a cgminer issue introduced in 2.4.1.

In 2.4.1+, devices are disabled (rolling rate is "OFF") when scanhash() returns 0. Check your cgminer log for reasons (all error conditions log error messages). I don't think it is an "issue". What's the point to have a device that cannot hash.

cgminer just handles errors coming from the device and disables the device. That is its error handling.
See nedbert9 post: https://bitcointalk.org/index.php?topic=76208.40

Closing and re-opening/re-initializing the port would probably be a better solution. But disable is simpler and works.

And works??? For what? Permanently disabling a perfectly good BFL single, just because there was some hiccup somewhere for a brief moment?
We seem to have a disagreement on the definition of "works" vs. "issue".

J/K. Ckolivas is a god.

af_newbie

legendary

Activity: 2702

Merit: 1468

Quote from: af_newbie on June 07, 2012, 10:23:42 AM

This happens to me occasionally as well (Win7/64 here), typically once every day or two. Happens in cgminer 2.4.1 and 2.4.2; in the cgminer window the device's hashrate is listed as 'OFF'.

This never happened with 2.3.6; I ran that version for 2 weeks straight without any issue. So I'm also leaning toward it being a cgminer issue introduced in 2.4.1.

In 2.4.1+, devices are disabled (rolling rate is "OFF") when scanhash() returns 0. Check your cgminer log for reasons (all error conditions log error messages). I don't think it is an "issue". What's the point to have a device that cannot hash.

cgminer just handles errors coming from the device and disables the device. That is its error handling.
See nedbert9 post: https://bitcointalk.org/index.php?topic=76208.40

Closing and re-opening/re-initializing the port would probably be a better solution. But disable is simpler and works.

Epoch

legendary

Activity: 922

Merit: 1003

Quote from: af_newbie on June 07, 2012, 10:23:42 AM

This happens to me occasionally as well (Win7/64 here), typically once every day or two. Happens in cgminer 2.4.1 and 2.4.2; in the cgminer window the device's hashrate is listed as 'OFF'.

This never happened with 2.3.6; I ran that version for 2 weeks straight without any issue. So I'm also leaning toward it being a cgminer issue introduced in 2.4.1.

In 2.4.1+, devices are disabled (rolling rate is "OFF") when scanhash() returns 0. Check your cgminer log for reasons (all error conditions log error messages). I don't think it is an "issue". What's the point to have a device that cannot hash.

cgminer just handles errors coming from the device and disables the device. That is its error handling.
See nedbert9 post: https://bitcointalk.org/index.php?topic=76208.40

Closing and re-opening/re-initializing the port would probably be a better solution. But disable is simpler and works.

I'll check into the logs tonight to see if they have any further clues ... I don't have any evidence (only observation and comparison to earlier behavior) to know what the root cause of the scanhash() failure is.

I do know that my Singles hashed for 2 weeks solid under 2.3.6 without any failure. Those same Singles have now had 1-2 'OFF' failures every day or two for the past two weeks running 2.4.1 and 2.4.2 in the same environment (same ambient temperature, same host PC, same USB hubs, same cables, same physical location and position).

That observation, plus several posts from other Single users running 2.4.1+, make a reasonably strong case to at least suggest that something may be broken in 2.4.1+.

I've read nedbert's post that you referenced; he is encountering the same problem as being described here. The point is that prior to 2.4.1+, Singles did not spontaneously 'stop hashing'. So I am trying to understand why they would be doing so now ... and, so far, the circumstantial evidence seems to be pointing the spotlight on cgminer 2.4.1+.

wogaut

donator

Activity: 448

Merit: 250

Quote from: zefir on June 06, 2012, 03:07:25 PM

This happens to me occasionally as well (Win7/64 here), typically once every day or two. Happens in cgminer 2.4.1 and 2.4.2; in the cgminer window the device's hashrate is listed as 'OFF'.

This never happened with 2.3.6; I ran that version for 2 weeks straight without any issue. So I'm also leaning toward it being a cgminer issue introduced in 2.4.1.

In 2.4.1+, devices are disabled (rolling rate is "OFF") when scanhash() returns 0. Check your cgminer log for reasons (all error conditions log error messages). I don't think it is an "issue". What's the point to have a device that cannot hash.

cgminer just handles errors coming from the device and disables the device. That is its error handling.
See nedbert9 post: https://bitcointalk.org/index.php?topic=76208.40

Closing and re-opening/re-initializing the port would probably be a better solution. But disable is simpler and works.

And works??? For what? Permanently disabling a perfectly good BFL single, just because there was some hiccup somewhere for a brief moment?
We seem to have a disagreement on the definition of "works" vs. "issue".

despoiler

member

Activity: 94

Merit: 10

Quote from: despoiler on June 06, 2012, 02:53:21 PM

Quote from: zefir on June 06, 2012, 02:52:00 PM

Quote from: despoiler on June 06, 2012, 02:22:51 PM

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

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.

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.

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?

Confirmed 864 is loaded. My unit stays pegged at 857.7 and the only time it comes down is when the LP hits. It goes right back to 857.7 and the average starts to climb back up to that also. I'm running Win7 64 with CGIMiner 2.4.1

Epoch

legendary

Activity: 922

Merit: 1003

Quote from: wogaut on June 07, 2012, 09:24:27 AM

Quote from: wogaut on June 07, 2012, 09:24:27 AM

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 Sad

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.

This happens to me occasionally as well (Win7/64 here), typically once every day or two. Happens in cgminer 2.4.1 and 2.4.2; in the cgminer window the device's hashrate is listed as 'OFF'.

This never happened with 2.3.6; I ran that version for 2 weeks straight without any issue. So I'm also leaning toward it being a cgminer issue introduced in 2.4.1.

Edit: @wogaut, I tend to agree. If this issue does not get resolved soon, rolling back to 2.3.6 may be the way to go.

rjk

sr. member

Activity: 448

Merit: 250

1ngldh

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.

crazyates

legendary

Activity: 952

Merit: 1000

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 Sad

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.

wogaut

donator

Activity: 448

Merit: 250

Quote from: BFL-Engineer on June 07, 2012, 01:28:01 AM

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 Sad

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.

Cablez

legendary

Activity: 1400

Merit: 1000

I owe my soul to the Bitcoin code...

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

zefir

donator

Activity: 919

Merit: 1000

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

BFL-Engineer

full member

Activity: 227

Merit: 100

Quote from: zefir on June 07, 2012, 01:23:51 AM

Quote from: BFL-Engineer on June 07, 2012, 01:08:45 AM

Quote from: BFL-Engineer on June 07, 2012, 01:08:45 AM

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 Sad

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

donator

Activity: 919

Merit: 1000

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 Sad

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

full member

Activity: 227

Merit: 100

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 Sad

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

donator

Activity: 919

Merit: 1000

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 Sad

BTCurious

hero member

Activity: 714

Merit: 504

^SEM img of Si wafer edge, scanned 2012-3-12.

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.

wogaut

donator

Activity: 448

Merit: 250

Quote from: aseldon on June 06, 2012, 08:10:06 PM

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.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

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

BTCurious

hero member

Activity: 714

Merit: 504

^SEM img of Si wafer edge, scanned 2012-3-12.

Quote from: aseldon on June 06, 2012, 08:10:06 PM

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?