Dug through the source, recompiled, made several cgminer modifications and tried several tweaks.

Learnings, tested on a 13.5TH autofreq miner from Dec 2017, overclocked to ~15.5TH with asicboost enabled on Braiins and playing with the code:

1) The temperature displayed (at least for my model of S9) is a complete lie. The miner (and this code comes from bitmain) tries to read both PCB and ASIC temp.  The ASIC temps are deemed unreliable by the algorithm and/or can't be read on my model, so the code basically takes the actual PCB temp reading (generally 50-65C for me) adds an arbitrary 30-35C to "fake" an estimate at the ASIC temps.

Braiins web UI displays the faked temp including the offset (~90C), bitmain stock UI (autofreq, pre-asicboost) displays the original PCB reading (~60C).

2) Auto fan control works fine, it's just maybe biased a little slower than bitmain's -- mine hovered around 70% PWM in braiins.  I made modifications to cgminer to push the fan curve higher for mine to ensure good cooling for overclocking, I'm now generally at 80-90% PWM now. The difference between 70% PWM fan and 100% PWM fan is at least 20-40W power increase to run the fans.

3) Power usage on pre-asicboost bitmain firmware at 13.5TH is roughly equivalent to Braiins with asicboost at 15TH (9V and 712mhz set on each chain) for me

4) The 'recommended voltage' goes down as frequency goes up based on Bitmain's internally coded tables, which are intended to help the device stay within a given power usage envelope.  [until you hit the point of frying the thing], more voltage is always going to help the chain go faster -- it's just going to suck more power (and possibly more power than your PSU or cooling can handle)

I'm also working on an auto-frequency-adjuster that can lower frequency per-asic-chip on each board (like that one with the cool red/green UI, but automated).

It works well for modifying frequency on a per-asic basis, but the heuristic I was basing 'when should I turn down the frequency' on appears invalid, at least for some of the chips (I've been using 'reported per-asic hashrate not within 15% of ideal per-asic hashrate').  Anyone know what that red/green UI uses to determine when to display red?

I'm also seeing reported temperatures *much* higher (~20C hotter) than what the bitmain stock firmware reported.  I'm just not sure if the two are reporting the same measurement -- if not, they're not really comparable.  If these are the same measurements though, that's not great.

My S9's are in an air conditioned room at ~15C ambient air temp.

Stock bitmain 13.5TH: 65-70C reported temps
Braiins at similar hashrate: 85-90C reported temps

I sent in a ticket to braiins to ask for clarification...

Presuming this is still derived from the original bitmain firmware's implementation -- would you please release an update for this rebased on the 11/3 update from bitmain that resolves the 'hashrate dropping over time' issue?  (Or advise that it's not necessary for your implementation)

https://twitter.com/Antminer_main/status/1058714676865855488

Thanks

New England Patriots 28 @ 32 Atlanta Falcons

payments sent

I think I'm going to shut this down -- compatibility with virtually all pools has broken, and multiclone just isn't a profitable way to mine anymore since I don't have time to fix it.

All that would accomplish is turn multiclone into Yet Another Proportional Pool.  Pointless.  Solo is there so that workers do something quasi-useful when the pool can't give it anything better.  There's still a chance we'll find something on solo mining, which is why we do that rather than miners idling.


Also, the getwork daemon died and prevented any work getting distributed earlier today due to a perl threading issue from the original code that it looks like the original Multipool was fighting with, too.  I think I fixed it, but it's happened before and I thought I fixed it that time too.

This time, I wrote some code to just relaunch the damn threads when they crash.  Things should be working again, and this should provide some better stability than 'lets hope Nick notices the server is messed up and manually restarts it'

Solo happens in the following 2 conditions:
* the target pools don't give multiclone enough work quickly enough to distribute to its users to prevent 'miner idle's
* a multiclone user's miner is misbehaving (hasn't been submitting enough valid shares relative to the getworks requested)


That said, for the past ~day, we've only got ~3% stale and ~3% solo.

With a 1.25 efficiency (of the confirmed shares, which is what my new miner has got for the past week since the problems were resolved), you still come out (1-.03-.03)*1.25 = 1.175 -> 17.5% ahead of the 'ideal' non-hopping case.

I have some ideas on things that might help reduce solo that I might get to this weekend...

Fixed. Divide-by-zero error crashed the website.

This integration of the solo pool as a backup (with blocking calls! one malfunction and everything is borked!) causes more trouble than anything else... My local bitcoind flaked out and needed restarted, so the pool crashed for about 30 minutes just a little bit ago.

Have a couple different longpoll push mechanisms to try that can hopefully fix the stales issue.

I had increased Multiclone's work pool queue yesterday to try to deal with the idles (which were caused by the problematic user).  Unfortunate side effect of this seems to be increased stales.  I put the work queue back where it was before.  Give it a shot again, and things should be back to how they were before?

Ah right, I'd forgotten about that. And you seem to be the only one with that particular quirky problem.  I'll pay you out manually in the next day or two.

What are you calling 'a lot'? global rate for past ~day is around 3.5%, which is certainly higher than normal, but not ridiculously high.

I think it's likely due to the problem user my previous post describes.

Whoever is address "1D1ugDJrrifR7WG3TaU1w71yF2wiXmAGqC", something looks to be screwed up in your miner config.  I see a ton of connections from you that keep opening longpoll connections, but rarely request or submit any work.

Yesterday, it looks like you were mining okay-ish (barely; you were only submitting shares for about half of the getworks requested) with a 1-2 Ghash.  Today, the log is just getting spammed with longpoll requests; looks like you're maintaining ~80 open connections, but are hardly submitting any work.  Each time a new longpoll comes out, trying to handle all your connections is causing brief idles for everyone else.

I've temporarily blocked your access to multiclone due to the problems your miners are causing everyone else. Please PM me when you think you have it fixed and I'll re-enable you.

There will still be a small handful of solo shares, just due to how multipool's queue works.  I've tried removing solo at various points and stability suffers.  If a given miner is being 'bad' (lots of stales in a row with no good shares, or newly connected), it will also receive some extra solo shares so that the 'real' pools don't get mad for multiclone requesting way more work than we submit good shares.

Overall, solo looks to be accounting for <4% of the global share rate.  With a ~20% increase in earned BTC, it's still definitely worthwhile.

In short: yes, but I'd be shocked if it's *quite* as bad as your comment indicates.  bitcoinpool started fabricating their stats, which totally screwed up the hopping for several days, causing us to mine a *lot* at bad times on that pool.  There was also a difficulty increase early last week that contributed some to this.

They've been kicked out; I do apologize for the trouble this caused everyone, but there wasn't really anything I could do to counter this =/


Now for some good news....
*drumroll*
bitcoins-lc shares have been processed!  This week's payment has been sent out!

I also added eligius back in with a fixed utility of 1.0 to serve as a backup for when hopping on all the proportional pools has a low expected payout.  This should (help) prevent any future efficiency from going below 1.


Multiclone's hashrate has been wayyyyyy down this week, probably as a result of the bitcoinpool thing.  It's resolved now, so let's get this party started again!

bitcoinpool kicked out of the rotation for stats lying. They were almost certainly what brought everyone's efficiency down. Thanks for bringing the problem to my attention!

I find the efficiency<1 comments odd, unless you only mined at multipool for a small number of unlucky hours.  All the accounts I've looked at (which mine long-term) have efficiencies around 1.15-1.25

The deepbit owner said he'd ban multiclone's account if I kept it in the rotation, so I removed it to avoid the headache.


Server restarted, dunno what was causing the flakyness. Hopefully it's better now.

Could be from when I restarted the server a couple times yesterday. My reject rate was a bit higher than normal for the past 24h too (but not nearly as high as yours). Global reject rate *after* the restart is 1.1%


Also, this.  You've probably overclocked your card too much.

A few days ago, I saw a thread on the forums where someone had written a pool stats aggregator that can be queried and will return stats for whichever pool you ask for.

Anyone happen to know what I'm talking about and can easily link me to it?  BTCGuild's 'current round shares' on their website is obviously wrong / 'includes multiple rounds'.  Just curious to see what the stats aggregator thing says...