50 GH/s BFL miner running at 15 GH.

[-ck]

I left it off longer this time.... now about where it was when I unboxed it, but still half of expected.  I'll let it run for now until I can get a smaller hex bit.

Code:

BAL  1:  max 56C 3.26V | 25.59G/25.49Gh/s | A:  453 R:  61 HW:  4 WU:339.7/m

BAL means it's looking like a little single to cgminer, not a single. So either you don't actually have a single, or one of the boards isn't working at all or some other software confusion on cgminer's part. Try 'java api stats' if you have the api enabled (--api-listen) and see what information is in the dump.

[lightfoot]

I left it off longer this time.... now about where it was when I unboxed it, but still half of expected.  I'll let it run for now until I can get a smaller hex bit.

Code:

BAL  1:  max 56C 3.26V | 25.59G/25.49Gh/s | A:  453 R:  61 HW:  4 WU:339.7/m

BAL means it's looking like a little single to cgminer, not a single. So either you don't actually have a single, or one of the boards isn't working at all or some other software confusion on cgminer's part. Try 'java api stats' if you have the api enabled (--api-listen) and see what information is in the dump.

CK, I run BFG myself, but how do you know if something is a little single, single, or truck? Reason is if this person loaded a custom firmware and you base your "what it is" based on the string back then I could see how cgminer would fail to load all the chips.

C

[-ck]

I left it off longer this time.... now about where it was when I unboxed it, but still half of expected.  I'll let it run for now until I can get a smaller hex bit.

Code:

BAL  1:  max 56C 3.26V | 25.59G/25.49Gh/s | A:  453 R:  61 HW:  4 WU:339.7/m

BAL means it's looking like a little single to cgminer, not a single. So either you don't actually have a single, or one of the boards isn't working at all or some other software confusion on cgminer's part. Try 'java api stats' if you have the api enabled (--api-listen) and see what information is in the dump.

CK, I run BFG myself, but how do you know if something is a little single, single, or truck? Reason is if this person loaded a custom firmware and you base your "what it is" based on the string back then I could see how cgminer would fail to load all the chips.

It doesn't care, it just sends continuous work regardless of what it is, be it a BAJ BAL BAS or BAM. The only difference is the name comes up differently. It's not like cgminer goes "ooh you're a piece of shit, let me only hand you shit work instead of lots of work".

[notme]

I left it off longer this time.... now about where it was when I unboxed it, but still half of expected.  I'll let it run for now until I can get a smaller hex bit.

Code:

BAL  1:  max 56C 3.26V | 25.59G/25.49Gh/s | A:  453 R:  61 HW:  4 WU:339.7/m

BAL means it's looking like a little single to cgminer, not a single. So either you don't actually have a single, or one of the boards isn't working at all or some other software confusion on cgminer's part. Try 'java api stats' if you have the api enabled (--api-listen) and see what information is in the dump.

Excluding most of it since I have a bunch of AM hardware plugged in too, but here is the entry for BAL0:

Code:

[STATS25] =>
(
   [STATS] => 25
   [ID] => BAL0
   [Elapsed] => 25
   [Calls] => 0
   [Wait] => 0.000000
   [Max] => 0.000000
   [Min] => 99999999.000000
   [Temp1] => 30.05
   [Temp2] => 56.86
   [Vcc1] => 3.264
   [Vcc2] => 0.918
   [Vmain] => 19.638
   [Temp1 Max] => 31.00
   [Temp2 Max] => 58.00
   [Temp1 Max Time] => 1385413534
   [Temp2 Max Time] => 1385413546
   [Work Queued] => 19
   [Work Complete] => 174
   [Overheat] => false
   [Flush ID] => 105
   [Result ID] => 109
   [Flushed] => true
   [Scan Sleep] => 336
   [Results Sleep] => 100
   [Work ms] => 143
   [Result Size] => 65/64/31/10/4/0/0/0/0/0
   [Driver] => 2
   [Firmware] =>  1.2.9
   [Chips] =>  YES @ 16
   [Que Size] => 40
   [Que Full] => 36
   [Que Watermark] => 32
   [Que Low] => 16
   [GetInfo] => DEVICE: BitFORCE SC0x0a
FIRMWARE: 1.2.90x0a
IAR Executed: NO0x0a
CHIP PARALLELIZATION: YES @ 160x0a
QUEUE DEPTH:400x0a
PROCESSOR 0: 16 engines @ 267 MHz -- MAP: FFFF0x0a
PROCESSOR 1: 15 engines @ 244 MHz -- MAP: FFBF0x0a
PROCESSOR 2: 16 engines @ 252 MHz -- MAP: FFFF0x0a
PROCESSOR 3: 15 engines @ 244 MHz -- MAP: DFFF0x0a
PROCESSOR 4: 15 engines @ 255 MHz -- MAP: FFDF0x0a
PROCESSOR 5: 16 engines @ 249 MHz -- MAP: FFFF0x0a
PROCESSOR 6: 16 engines @ 252 MHz -- MAP: FFFF0x0a
PROCESSOR 7: 15 engines @ 244 MHz -- MAP: FFF70x0a
THEORETICAL MAX: 31125 MH/s0x0a
ENGINES: 1240x0a
FREQUENCY: 274 MHz0x0a
CRITICAL TEMPERATURE: 00x0a
TOTAL THERMAL CYCLES: 00x0a
XLINK MODE: MASTER0x0a
XLINK PRESENT: NO0x0aOK0x0a0x00
   [USB Pipe] => 0
   [USB Delay] => r0 0.000000 w0 0.000000
   [USB tmo] => 0 0
)

[lightfoot]

CK, ok; thought so. I have my BFL call itself all sorts of things, WAIT A SEC I can load that with all sorts of diagnostic messages if I want to. Thanks for the thought, now I have a better way of getting internal state out to the world without screwing with the USB port....

Anyway, from my POV that looks like a totally normal little single. Running at about the same temps as my jally with 5 chips, I'm cruising at 55c or so with similar voltages. So it's sinking heat. Also that hashing level looks like the limit is enabled, as it's really close to 30gh+4%. This is a stock firmware, right (yes, I'm asking again, just verifying)

Just as a cross check can you try it with BFGMiner? But I'd guess half the unit is down and the half running also powers the USB interface (it does have only one USB interface, right?)

C

[notme]

Stock firmware.  There is one usb port.

I will give bfgminer a try later.  What specifically should I be looking for?

[lightfoot]

Stock firmware.  There is one usb port.

I will give bfgminer a try later.  What specifically should I be looking for?

See if it hashes at 30 or 60. You can also select Display, "M" option to see all the engines it sees. If it only sees 8 then something is definately odd.

Can you tell if both top fans are running inside the unit? Any smell of smoke or burned at all when you stick your nose to the external fan openings?

C

[notme]

Code:

BFL 0: 59.0C | 26.84/25.47/21.17Gh/s | A:144 R:24+0( 12%) HW:6/.70%

Code:

Select processor to manage using up/down arrow keys
 BFL 0a: 60.0C |  3.16/ 3.02/ 2.56Gh/s | A: 20 R: 4+0( 15%) HW:0/none
  BitFORCE SHA256 SC from FTDI
Kernel: parallel queue
Temperatures: 30.0C 60.0C
Voltages: 3.264 / 0.915 / 18.620

Using the arrow keys I see BFL 0a - BFL 0h.

As far as I can tell, both top fans are running, but even with a flashlight I can't really see well until I get it open.

Thanks for all the help guys.  I'm leaving tomorrow to visit family for Thanksgiving, but I'll update this when I get back and get a T10 bit.

[vayvanne]

I heard some noise when unpacking and a screw dropped out of miner.
One of five miners was DOA. Other one hashes at 4, 8 or sometimes 15 GH/s out of 25-30.
Still waiting for reply from rma@butterflylabs.com.

[sameev29]

Its BFL what can we expect after all the bad experience people are having.

[notme]

Got it open.  All fans were working.  Removed thermal pads and applied paste.  Hashing at 37GH/s now, which is better, but still not what it should be.  Software is now recognizing it as a BAS with 16 cores.

[BitCloud]

had the same issue, even slower actually

put it in the freezer for 1h

full spec

[lightfoot]

I had an idea: Every Single owner should email BFL and ask that they send some wrecked units to Lightfoot for analysis. I'd be more than happy to figure this out once and for all.

I am working on the Jalapeno failure issue, but that only cost me .15btc+$50 shipping plus heck knows what else. Can't do that for single prices. :-)

C

[Photon939]

I had an idea: Every Single owner should email BFL and ask that they send some wrecked units to Lightfoot for analysis. I'd be more than happy to figure this out once and for all.

I am working on the Jalapeno failure issue, but that only cost me .15btc+$50 shipping plus heck knows what else. Can't do that for single prices. :-)

C

Unfortunately I doubt they care. Once they sell out the last of their 65nm chips that's the end of them, and the end of their "lifetime" warranty. Then we get to watch and see how many delays happen on the Monarch. I'm sitting back and watching this round 

[lightfoot]

Unfortunately I doubt they care. Once they sell out the last of their 65nm chips that's the end of them, and the end of their "lifetime" warranty. Then we get to watch and see how many delays happen on the Monarch. I'm sitting back and watching this round  

Probably not, but still it would be fun.

I'm not buying a Monarch, but I will bet dollars to donuts that the techniques I have figured out for these systems will work the same on Monarchs. And possibly other miners, maybe I should become a repair depot for companies or something.

You know, in retrospect that would have been a good idea: Have a troubleshooter or two identifying trends to minimize returns and such. RMA's are incredibly expensive and can tear down a company's profits in very short order.

But given that bitcoin is powered by delusion and optimism, I can see why that is not done. Interesting :-)