Bitcoin Forum
December 10, 2016, 03:13:30 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 [74] 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 »
  Print  
Author Topic: Butterfly Labs - Bitforce Single and Mini Rig Box  (Read 176560 times)
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
June 07, 2012, 02:33:08 PM
 #1461

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.

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
1481382810
Hero Member
*
Offline Offline

Posts: 1481382810

View Profile Personal Message (Offline)

Ignore
1481382810
Reply with quote  #2

1481382810
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481382810
Hero Member
*
Offline Offline

Posts: 1481382810

View Profile Personal Message (Offline)

Ignore
1481382810
Reply with quote  #2

1481382810
Report to moderator
1481382810
Hero Member
*
Offline Offline

Posts: 1481382810

View Profile Personal Message (Offline)

Ignore
1481382810
Reply with quote  #2

1481382810
Report to moderator
1481382810
Hero Member
*
Offline Offline

Posts: 1481382810

View Profile Personal Message (Offline)

Ignore
1481382810
Reply with quote  #2

1481382810
Report to moderator
Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
June 07, 2012, 02:37:51 PM
 #1462

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.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
despoiler
Member
**
Offline Offline

Activity: 94


View Profile
June 07, 2012, 03:02:12 PM
 #1463

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   
af_newbie
Legendary
*
Offline Offline

Activity: 910



View Profile
June 07, 2012, 03:23:42 PM
 #1464


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.
wogaut
Donator
Sr. Member
*
Offline Offline

Activity: 448



View Profile
June 07, 2012, 03:43:42 PM
 #1465


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
Legendary
*
Offline Offline

Activity: 917



View Profile
June 07, 2012, 03:44:23 PM
 #1466

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

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
June 07, 2012, 03:47:16 PM
 #1467


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.

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
leofar
Full Member
***
Offline Offline

Activity: 157


Злобный Ых


View Profile
June 07, 2012, 03:51:03 PM
 #1468

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

Плюну в ухо, укушу за нос...
af_newbie
Legendary
*
Offline Offline

Activity: 910



View Profile
June 07, 2012, 03:59:54 PM
 #1469

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.
af_newbie
Legendary
*
Offline Offline

Activity: 910



View Profile
June 07, 2012, 04:02:23 PM
 #1470

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.
Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
June 07, 2012, 04:11:38 PM
 #1471

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.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
BitMinerN8
Hero Member
*****
Offline Offline

Activity: 626


Mining since May 2011.


View Profile
June 07, 2012, 04:13:45 PM
 #1472

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
Legendary
*
Offline Offline

Activity: 917



View Profile
June 07, 2012, 04:34:56 PM
 #1473

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

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
June 07, 2012, 04:57:41 PM
 #1474

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?

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
dropt
Legendary
*
Offline Offline

Activity: 1442



View Profile
June 07, 2012, 05:19:11 PM
 #1475

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
Legendary
*
Offline Offline

Activity: 917



View Profile
June 07, 2012, 06:19:50 PM
 #1476

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.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
P_Shep
Legendary
*
Offline Offline

Activity: 924


View Profile WWW
June 07, 2012, 07:01:04 PM
 #1477

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
Legendary
*
Offline Offline

Activity: 917



View Profile
June 07, 2012, 07:18:16 PM
 #1478

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.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
P_Shep
Legendary
*
Offline Offline

Activity: 924


View Profile WWW
June 07, 2012, 07:44:10 PM
 #1479

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
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
June 07, 2012, 08:56:41 PM
 #1480

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

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

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Pages: « 1 ... 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 [74] 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!