Butterfly Labs - Bitforce Single and Mini Rig Box

[Epoch]

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.

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.

[1714189439]

1714189439

[despoiler]

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   

[wogaut]

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

[Epoch]

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

[crazyates]

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.

[leofar]

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

[Epoch]

And works??? For what? Permanently disabling a perfectly good BFL single, just because there was some hiccup somewhere for a brief moment?

I was being sarcastic.  Good luck arguing it with Kano or Con.

Might have luck with Luke, though.

[BitMinerN8]

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

Lucky you.  2.4.1 and 2.4.2 has the same error handling with regards to  this issue.

FWIW:
I have a Win7/x64 rig with (1) 5870 and (5) BFL Singles running 2.4.1 for over two weeks without issue. None of them have dropped offline, all are running 832 fw, CGminer says 826Mh/s.

[Epoch]

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

Lucky you.  2.4.1 and 2.4.2 has the same error handling with regards to  this issue.

FWIW:
I have a Win7/x64 rig with (1) 5870 and (5) BFL Singles running 2.4.1 for over two weeks without issue. None of them have dropped offline, all are running 832 fw, CGminer says 826Mh/s.

Lots of observations coming in. Some people have trouble, some don't. With 5 Singles running for 2 weeks I would have expected the issue to crop up at least once. This is part of the reason that makes this 'issue' (or non-issue) difficult to pin down. Bottom line is that if the program is working for someone, then they have no worries. For the others experiencing issues, a workaround would seem to be switching back to 2.3.6.

This may or may not be related, but I noticed that 2.4.1+ will NOT run 15 devices. It will crash immediately. With 2.3.6 I was able to run 15 devices fine. I merely point this out as an example of something, which used to work, being inadvertently 'broken' in 2.4.1+.

[crazyates]

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

Lucky you.  2.4.1 and 2.4.2 has the same error handling with regards to  this issue.

FWIW:
I have a Win7/x64 rig with (1) 5870 and (5) BFL Singles running 2.4.1 for over two weeks without issue. None of them have dropped offline, all are running 832 fw, CGminer says 826Mh/s.

Lots of observations coming in. Some people have trouble, some don't. With 5 Singles running for 2 weeks I would have expected the issue to crop up at least once. This is part of the reason that makes this 'issue' (or non-issue) difficult to pin down. Bottom line is that if the program is working for someone, then they have no worries. For the others experiencing issues, a workaround would seem to be switching back to 2.3.6.

This may or may not be related, but I noticed that 2.4.1+ will NOT run 15 devices. It will crash immediately. With 2.3.6 I was able to run 15 devices fine. I merely point this out as an example of something, which used to work, being inadvertently 'broken' in 2.4.1+.

This 15 device limit is separate from the pdcurses fuckup having to do with the cmd prompt window size?

[dropt]

Since people are weighing in, I had issues with 1 of my 2 singles using CGminer 2.4.1 under BAMT.  It would either a) show OFF, or b) Show as if it was hashing, but the accepted shares would not increase and the reported hash rate would slowly (and I mean sloooowly) decrease over time.  I moved them over to a win7 machine using cgminer 2.4.1 and have not had an issue since.

[Epoch]

This 15 device limit is separate from the pdcurses fuckup having to do with the cmd prompt window size?

15 devices, cgminer 2.4.1, window size 120x50: crash on startup
15 devices, cgminer 2.3.6, window size 120x50: works fine

EDIT: I've just had another Single go into the 'OFF' state (cgminer 2.4.2). That clinches it; I'm rolling back to 2.3.6.

[P_Shep]

This:

https://github.com/ckolivas/cgminer/commit/06023e549efa649979b501cd448e1098b715860f

came in between 2.3.6 and 2.4.0. Might have something to do with it.

[Epoch]

This:

https://github.com/ckolivas/cgminer/commit/06023e549efa649979b501cd448e1098b715860f

came in between 2.3.6 and 2.4.0. Might have something to do with it.

So 2.3.6 would terminate the application if a write-error was encountered, while 2.4.1+ simply continues running but sets the device as 'OFF'. Yes, this is consistent with the behavior I am seeing.

I will set up to test 2.3.6 again, to verify if cgminer quits (signifying a Single failure) over the next week. If the Singles fail as often as I am seeing now, I should expect to see something within the next 2 days but I'll wait a week to be more certain.

Thanks for the info, P_Shep.

[P_Shep]

I don't know what exactly 'quit' does. It may exit the whole program, or maybe it just terminates the thread. If the thread terminates, maybe cgminer starts it back up? I'm not familier enough with the code.
Either way the whole BFL driver code needs re-writing. It's not at all robust.

[kano]

This 15 device limit is separate from the pdcurses fuckup having to do with the cmd prompt window size?

15 devices, cgminer 2.4.1, window size 120x50: crash on startup
15 devices, cgminer 2.3.6, window size 120x50: works fine

EDIT: I've just had another Single go into the 'OFF' state (cgminer 2.4.2). That clinches it; I'm rolling back to 2.3.6.

Well I put up a pull request that might be related to this ... then spent a day arguing with Luke-jr coz he saw it as a problem in BFGMiner ... and I still have no idea why he has any say in what goes into the BFL code in cgminer ...
(what a fucking waste of time that was)

https://github.com/ckolivas/cgminer/pull/215
(fun read that )

Anyway, the change relates to 3 issues, the 3rd one I haven't confirmed if it fixes it yet or not.
1) BFL doesn't display an ERR (only a DEBUG message) if it fails to open a device (so you don't know unless you have debug on)
2) Telling cgminer that a device is a 'bitforce:' or an 'icarus:' doesn't stop it from trying to open an invalid device name (and ignoring the error)
3) I think 2) may be the cause of getting an error on windows7 64bit where it's running in 32bit emulation and has a limit to the number of USB ports that can be opened and I think that opening an invalid device that includes something that looks like a USB port in the name may use up the limited number of available USB ports in 32bit mode

The reason why it's changed between 2.3.6 and 2.4.2 (other than that change listed above by P_Shep) is that the lead dev wanted me to include a change from BFGMiner into cgminer that Luke-jr did to resolve an issue he had with the BFL code hanging on opening an Icarus
He was given an Icarus and then put in a change to attempt Icarus first before BFL rather than fix the BFL problem.
As you can see from the minor and simple change request I made above, it is no point me even trying to fix BFL problems ...

I've also told him a simple change to BFL to match like I did in Icarus regarding aborting work on an LP (instead of hashing on invalid data when submit stale is switched off) but he wont implement it since (according to him) it will not work with the code (i.e. he can't do it ) and his other excuse was that there will be a new firmware to resolve this real soon now ... (4-6 weeks?) ...

P.S. 'quit' quits cgminer ...

[P_Shep]

https://github.com/ckolivas/cgminer/pull/215
(fun read that )

Yeah, I read that earlier. Fun and games!

[O_Shovah]

Hello everybody.

As this thread features all BFL devices i wanted to spread some pictures of my recent developments here.
Nameingly i havedesigned and build water cooling blocks for the BFL single versions in for BFL.
But as this project has been agreed to be delayed to the next generation of boards for volume production, i wanted to show my prototypes here at least.
Some pixels:


My water cooled rig at work  2.4 Gh/s.


High density per heith.


Two of the prototype coolers coupled.

I created also coolers for the x6500 board and wil do so for the lancelot.

Questions, critique, and ideas are welcome

[ice_chill]

Very interesting, what's the possible price ?

[Cablez]

What number of coupled units do you think will be the max before pressure issues abound?