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

I wonder... if it's a recurring problem and you confirm it every time, it is possible the device isn't actually hashing at that rate and is conveniently losing work...

I ran for 12 hours and it wasn't improving. I went back to 832 and U is back to what I expect. I will try the 862 again later.

Um - you did run for a day and ensure that your U: was really lower right?
As I've mentioned in a few places already, I've had a >6% variance of U: last for 3.5 hours once.
(so a -6% variance over that length of time is obviously quite possible also)

Runs great on mine too. However, even though the Hash rate is increased, the performance is decreased. I can not figure out why but when I went back to 832 I am doing better than at 862.

heres a screenshot of mine mining with the 862 firmware

http://i.imgur.com/dqOYX.jpg

runs great thx

I understand how long polls work. New block is found everyone has to get new work. The pools get hammered with requests for work. How is it possible when I am working on previously cached work and requesting new and showing cached work that I am out of work? Even set to 2 seconds for my logging I show 1 unit que and 3-12 staged. How is that out of work?

The above statement along with a 6 month warranty make me happy that BFL took 2 days to answer my email in regards to a near $10,000 USD order that I was informed may be available in 6-8 weeks.

I will keep a candle burning for you all and pray that your 6 month warrantied miners don't end up being 7 month old paperweights.

858 on the 862 firmware. 0 throttles and 0 errors light test. running on cgminer now to let it run all night. Will unplug and retry tests tomorrow.

Yes I am I edited in that I was testing faster before I checked for new posts. I gave results then downloaded the new firmwares.

......shipped with 3 fans total and a declocked bitstream....

Test shows average speed 810Mhash, 0 throttles, 0 errors and reliable. The 810 makes me a little upset. Had I known that it was shipped with 3 fans total and a declocked bitstream I would have expected the results I have gotten. Not the results that where stated plainly on the page when I paid for it.

Well that would be truely accurate except I submit stale as 2 of my 3 pools accept all of the shares. It does not go idle or does not seem to slow down until the staged work runs out. I guess my quandry is why between LP is the unit never able to clear 811.1 with an average of 796 over this test has only been 10 hours. I understand that the lag after LP (if I dumped the queue) would delay a couple of work units. Even EclipseMC where RollNtime is working. I am able to run some work multiple times per request. Even if the first request was lagging the next 4 for sure submissions should be on time as the work is now local. While the next how ever many it completes are being run through CGminer queues more work. Up to 2 is the highest I have seen. But even with a queue of 2 and staged work of 5 I am seeing less then 800 listed periodically. The loss of hashrate comes about 1 minute into the new work after the LP.

On CGMiner how long is the per device speed averaged over. I am going to try changing the log information to see when the upper matches since I know of no faster way to find out(this was a bad plan as now the value I want to test and the value I am to test it against both change at the same time). I know the average seems to be the whole running time. I know the upper data I can set and it defaults to 5 seconds. I ask because I am having trouble figuring out if cgminer is failing to deliver work fast enough, if cgminer isn't checking close enough to when its done sometimes, if a minute after a LP I am unable to get shares in a timely fashion (I have queued work so that seems unlikely), or if my single is not for some reason  signaling it is done when it should(I am not saying this is the problem).

As a side note per the engineers information I have no way to actually diagnose this. There appears to be no status indication for a unit done with its processing but not yet working. Maybe I have misunderstood but the internal LED's only blink when new work is set so they  are nearly useless for me to tell if the device is finsihing early. This has my testing stuck with a blame the other guy answer. All that needs said is BFL its cgminer or your pools, cgminer its your pools or your single, your pools its your single or cgminer. HOW DO I KNOW?

I don't think 811 sounds right at all personally. My average of not even 800 seems horribly low. I understand that LP can cause some network delays after it happens. I guess to me it seems a bit glib to say that my unit is throttling when out fo the two of us I am pretty sure I am the only one capable of seeing the LED's, and that despite my being able to look into the running unit you know much better then I do what rate the internal LED's blink at. Possibly you have broken into my house and examined the unit without my knowledge or consent but far more likely you are guessing. I am looking at the unit in question. I am in proximity to the problem and so far I have gotten nothing from the BFL-Engineer to actually help figure this out. By all means pat yourself on the back for being so knowledgable that you just know everything is fine. Maybe just for a moment pretend that when I said I stared at it for an hour I ment 60 Minutes. When I said I timed the LED flashes I actually timed them, and when I said I counted that I am not so stupid as to actually look away during it.

I understand how long polls work. New block is found everyone has to get new work. The pools get hammered with requests for work. How is it possible when I am working on previously cached work and requesting new and showing cached work that I am out of work? Even set to 2 seconds for my logging I show 1 unit que and 3-12 staged. How is that out of work?