|
I'm selling everything now to pay off what I spent on the rigs, then I'll sell enough to pay for electricity.
|
|
|
|
Hoppable prop pools will not be wanting to give out that much information... of course that's their problem.
That's why everything is optional. Word. |
|
|
|
|
I just checked, mines running at 115.2K by default.
|
|
|
|
Reminds me of  Certainly does  but no standard exists for this yet... all have been proprietary. |
|
|
|
Did you update the wiki page with the specification? I should probably do that... |
|
|
|
|
Hmmm, AJAX eh?...
A quick google shows that is indeed what I would need. Something new for me to learn.
|
|
|
|
|
(as a corollary, I would prefer to have accurate BTC stats. Don't much care for NMC so would be quite happy if NMC accepted shares aren't reported when BTC is stale)
|
|
|
|
Thanks for looking into that. At least now I have an explanation  Didn't mean to infer there was a discrepancy in submitted shares, just the rejected ones. |
|
|
|
|
The BFL driver code isn't so great right now. At the slightest sign of a problem, the default action is to scream and die. There aren't any re-tries or timeouts. Hopefully that'll change soon.
|
|
|
|
My calculator has a solar panel. |
|
|
|
Can you turn on shares logging on CGminer for about an hour and send it to me? An hour should be enough to show the discrepancy, correct?
Sure, I'll get that going a bit later. |
|
|
|
You can use "--rotate" and get similar results to "--load-balance". The miner works on one pool for the time you specify and then rotates to the next.
Yeah, I was thinking about that. |
|
|
|
As each pool has a different idea about when the block changes, if I choose the first pool's block change to discard all work from all pools then there can be quite a long period across block changes where cgminer throws out lots of work because it will continue to consider it from the old block. I had to relax the stale testing for load balance to prevent this work from being thrown out. On the other hand it's almost certainly what's leading to higher stales at every longpoll/block change. People generally get scared when they see a huge dip in hashrate across longpoll and start blaming cgminer for not keeping the devices busy. It probably makes more sense to throw out the work and accept the dip in hashrate so I can do that next version, but no matter what I choose, someone will complain  I was wondering if something like this was the case. Looking at the log that seemed to me what was happening, but I was having difficulty translating what was going on... (for one, the specific pool/device the message is about is rarely referenced in the logs!). If there's not much you can do, there's not much you can do! I'll just stick to fail-over then I'd say taking the dip in hashrate would be better option though. I prefer not to start work than throw away work done... 1. You won't waste power calculated hashes you know will be stale. 2. You don't get stales appearing in the stats. |
|
|
|
|
I think I might have found what's been causing my high stales, though not specifically...
It seems with load-balance I get very a poor stale rate, which seems to get worse the more pools involved. with 3 pools I get around 1.5% stale, with 5 it's up to 3-4%. When it's fail-over-only I'm looking at < 0.5%
Trouble is, the CGminer reported stats are not the same as the pools report. it seems the pools (some more than others) often report a share as valid to cgminer, then decide in it's own stats that it's stale.
I have a 10Mb debug log file taken over 1.5hrs if it'll be useful to diagnose anything.
|
|
|
|
|
Sorry, stales, not invalids!
|
|
|
|
|
High invalid rate aside... I'm still getting a very large discrepancy between CGminer and maxbtc reported invalid rate. It does seem that maxBTC it telling cgminer a share valid, then deciding it's not.
|
|
|
|
Any updates on Ztex support?
I can compile a version with it in, but I don't know that anyone has got it working. Look back through this thread and see if you can get any info from those who have attempted it. And thanks Ned |
|
|
|
|
Network.
Wonderful road-runner time warner cable. And I can't change to anyone else :/
I have ping to EMC of 60ms, to Ozcoin 70ms.
The weird thing is when pinging to EMC the pings are rapid fire, like 1s intervals. to Ozcoin it once every 4s or so. No idea why that may be? Don't change any options!
|
|
|
|
|
Show Posts
