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

Only my new additions to 2.7.5 report throttle counts - in the API stats (my git - not 2.7.5 - it's a after 2.7.5)
Previously they were just HW: errors, and before that they were only COM errors (again in the API stats)

What OS are you running?

As for hardware changes, mine worked fine for about 2 months (original 832 bitstream), then one day the 2nd FPGA died.
Then it worked OK again, then it died again, and this went on for some time (weeks)
In the end I thought, stuff it, I'll try the 880 bitstream and see if that kills it.
Worked fine on 880 since then
Running 10C higher than it used to run on 832 - and even on 832 it couldn't get this hot without problems

So downgrade and see if it changes back.  But make note of U first, and your pool performance if you are using a pool, in case it changes back but either of those things don't change.

If you look at my earlier post, the units were all running within ~20Mhash of the firmware speed. With this throttling, they are now running 1-200MH below firmware speed (one is averaging 600). This level of throttling couldn't have been happening before

I think throttles showing as HW errors and being listed in the output was a feature added later than 2.4.3.  IOW, you didn't see it was throttling before, but that doesn't mean it wasn't.

Yeah, but it wasn't happening at all (running for weeks without stop) using cgminer 2.4.3 so that doesn't really make sense to me.

That's a throttle

And this:


Maybe I should downgrade? This wasn't happening at all using the old version.

This too:

Now I'm getting strange issues with 2.7.5:


2 of my units are showing a high # of HW errors all of a sudden. Arrrrrgh!!

After: 3 days and ~10 hours


Now, not all shares are going to Ozcoin
Ozcoin was 59,503 Accepted and 141 Rejected
But that's ~0.24%

Also note - I'm using 8331 - i.e. no NMC, no merged mining and certainly no extra NMC LPs

(3 days and 10 hours ago I moved it down to my basement garage where the other mining hardware is - coz it was hitting as high as 60C up here and throttling almost every hour - winter ended and spring just started here)

Also note that I'm in Aus and the pool server au.ozco.in is in the USA ... and I get a ping of ~225ms from my rig
... checking my API stats, the minimum Ozcoin pool wait time is 0.399577s and of course Ozcoin is roll-n-time - so that's why I get >1000% efficiency also

Edit: oh and the cases - no, the case is on with the fan blowing out the top
The BFL version is: single fan on top, no fan underneath new heatsink on top
As far as I can tell, the throttling hardware in mine is fscked - which works well to my advantage allowing it report higher temps with the 880 bitstream before it throttles - last week, the day before I moved it downstairs, it was running at up to 57C without throttling at all

Yeah, it was the version. Upgraded to 2.4.5. 5,000 shares in and i'm at ~0.55%

I'm on Ozcoin with CGMiner 2.7.0, and I'm getting ~0.7%.

Hmmm. I was running cgminer2.4.3, upgraded to 2.7.3 to see if that helps.

Any other cgminer flags I should be using?

I always got high rejects at Ozcoin too. I've been using 50btc (pps only) with rejects at less than 0.2 % or better. I don't know what the difference is but I'm not complaining.

This is using ozcoin, so I'm guessing switching to another pool wouldn't help? Strange my rejects are higher though. I can't imagine that 1% would be due to latency? Ping times to the pool around ~50ms.

Did you take the cases off to get them all stable at 880?

Thanks for that. I started thinking about this earlier, and posted my thoughts here, but I'll ask you here now.

1) As of right now, how often does a new header (with a new merkle root) get pushed to a miner?

2) How far forward can rollNtime go into the future and still solve a valid block?

3) I'm assuming miners > 4GH/s (miners that process more than the entire nonce range every second) just keep rolling the time by +1 second until they receive a new header? This is basically why I'm asking questions 1 and 2.

Just to clarify
For each hash you do you hash a bunch of bytes. They are (in order)
version (= 1) - 4 bytes
Previous block - 32 bytes
Merkle Root - 32 bytes
Time - 4 bytes
Block Difficulty - 4 bytes
Nonce - 4 bytes

Now of those 6 - 3 of them cannot be changed: version, previous block, block difficulty
Next is Merkle Root - that is not changeable in normal pool work (this is a subject of discussion at the moment of effectively moving all the work the pool does to the miner ... so the pool is simply just a share counter ... start billing them for your work!)

That leaves Time and Nonce.

So you get a work item from the pool that has all but the nonce defined, then you start a counter of the nonce from 0 to 0xffffffff and for each value you hash the combination of the 6 and check if the result is below the required difficulty.

So the Nonce is actually just a counter so you can try 4billion hashes with each item of work the pool has given you.

Changing a single bit in the 6 pieces of data (as in the normal example incrementing the nonce by one) produces a completely different hash result.

... and to add my previous comments on the subject ... yes that is just like MSDOS - Satoshi decided that a nonce size of 32bits was big enough - when in fact it is already too small - and when ASIC comes out it will be VERY noticeable. There is enough space to simply make it 128 bits and thus last 'many' years into the future. However that requires a hard fork and we all know the bitcoin devs are hopeless at forks and as a result - we get the good old MSDOS hack solutions to solve the problem - the first one was roll-n-time so miners simply change the time field - thus why the time field in a block is next to meaningless. The next solution is to have the miners do pretty much all the work the pools should be doing - so in my opinion they should also charge the pools for doing all their work if that is implemented

That's where the difficulty comes in.

Imagine you're pulling numbers from a hat. There's 100 numbers, and if you get higher than 5, you win a prize! But you're winning too often, so I increase the number to 20. Three more people join you, so now I"m getting a winner 4x as often, so I increase the number to 80. Now I'm giving out the same number of prizes, but you're now winning 1/4 of the number of times you used to. I'm selfish and feeling evil, so I increase the number to 99. Now it's a LOT harder to get a winner, but it will happen eventually.

That's (sort of) what difficulty does.

okay so it's the 'randomizer' thanks!


but now what decides what hash its looking for when it checks to see if it 'won'

It's a variable. The way bitcoin hashing works, you input variables, and you output a hash. Variables -> Hash

Bitcoin mining has several variables that are constantly changing, so we constantly have new work to do. Variables can include new transactions, timestamp, and what's called a nonce range.

This wiki graph shows all (well not all, but most) of the variables, and when they are updated.

Even a single digit change can drastically change the completed hash, so the nonce range has 2^32 different possibilities. This gives us 2^32 different hashes, even before any other variable can change.

Every time you hash, your miner adds +1 to the nonce, tries it again, and gets a completely different hash. Repeat several bazillion times.

and the purpose?