So I installed your binary and my S5 fan shot up to 100% and stayed there, even though I have it set to 20% in the UI. Just to make sure that really was what caused it, I unplugged the S5, plugged it back in and it started up with fans at 20% like usual. I re-installed the binary, restarted cgminer and it was back to 100%. Is there a fan speed flag or something I'm missing? 20% I can deal with... 100%? Not so much when it sits with me in my office  Been a very long time since I had anything to do with the S5 since I made that binary sorry. I had heard that fan control could not be set by the interface with it (going back to auto?) so there's not much I can do about it now. |
|
|
|
Any custom FW for S5? -- I am planning to get the S5 FW refreshed to do ckpool solo mining fulltime.
Only the binary I made which has to be manually copied over and is not permanent. you can even shorten the sequence :p ssh 192.168.1.x -l root
cd /usr/bin
mv cgminer cgminer.bak
wget http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer
chmod +x cgminer
/etc/init.d/cgminer.sh restart |
|
|
|
The user summary is all valid JSON that can be parsed by any compatible parser, and having all the workers listed is helpful for a summary of when you have lots. You can still search by distinct worker if you only want one worker's summary. Having said that, I made it so that the order of the entries for the user are still first before any worker entries are listed, so if you are looking yourself rather than using a parser, you can just look at the start of that summary. I cant make heads nor tails of this gibberish that comes up as my stats now. I think it was alot better when it was just one line. How do i find my overall best share? Does everyone stats look like this? {"hashrate1m": "6", "hashrate5m": "138M", "hashrate1hr": "56.7G", "hashrate1d": "52.8G", "hashrate7d": "721G", "lastupdate": 1459284547, "workers": 13, "shares": 1389906112, "bestshare": 2479216.9410085399, "bestever": 5372841526,
"worker": [{"hashrate1m": "0", "hashrate5m": "0", "hashrate1hr": "1.88K", "hashrate1d": "5.11G", "hashrate7d": "4.18G", "lastupdate": 1459284547, "shares": 14153882, "bestshare": 267074.17735289322, "bestever": 1746902, "workername": "1PwftnJ5FhMhTb9dAY61oD2KE8VPvh9Qkt.53"}, {"hashrate1m": "0", "hashrate5m": "0", "hashrate1hr": "0", "hashrate1d": "34.5M", "hashrate7d": "817M", "lastupdate": 1459284547, "shares": 6968892, "bestshare": 0.0, "bestever": 14702765, "workername": "1PwftnJ5FhMhTb9dAY61oD2KE8VPvh9Qkt.44"}, {"hashrate1m": "0", "hashrate5m": "0", "hashrate1hr": "700", "hashrate1d": "1.39G", "hashrate7d": "1.28G", "lastupdate": 1459284547, "shares": 8843593, "bestshare": 314230.7511612706, "bestever": 58962350, "workername": "1PwftnJ5FhMhTb9dAY61oD2KE8VPvh9Qkt.s4"}, {"hashrate1m": "0", "hashrate5m": "0", "hashrate1hr": "2.51K", "hashrate1d": "8.44G", "hashrate7d": "719G", "lastupdate": 1459284547, "shares": 66383769626, "bestshare": 2479216.9410085399, "bestever": 16647668062, "workername": "1PwftnJ5FhMhTb9dAY61oD2KE8VPvh9Qkt"}, {"hashrate1m": "0", "hashrate5m": "0", "hashrate1hr": "1.04K", "hashrate1d": "3.47G", "hashrate7d": "2.13G", "lastupdate": 1459284547, "shares": 15298493, "bestshare": 99209.681028703533, "bestever": 9291283, "workername": "1PwftnJ5FhMhTb9dAY61oD2KE8VPvh9Qkt.spn1"}, {"hashrate1m": "0", "hashrate5m": "0", "hashrate1hr": "2.29K", "hashrate1d": "4.25G", "hashrate7d": "3.13G", "lastupdate": 1459284547, "shares": 30263781, "bestshare": 163048.10578066277, "bestever": 15367570, "workername": "1PwftnJ5FhMhTb9dAY61oD2KE8VPvh9Qkt.penis"}, {"hashrate1m": "0", "hashrate5m": "0", "hashrate1hr": "930", "hashrate1d": "3.19G", "hashrate7d": "2.5G", "lastupdate": 1459284547, "shares": 19818066, "bestshare": 174983.41529394643, "bestever": 61109954, "workername": "1PwftnJ5FhMhTb9dAY61oD2KE8VPvh9Qkt.234"}, {"hashrate1m": "0", "hashrate5m": "0", "hashrate1hr": "410", "hashrate1d": "1.89G", "hashrate7d": "547M", "lastupdate": 1459284547, "shares": 241000, "bestshare": 71704.667530447958, "bestever": 906504, "workername": "1PwftnJ5FhMhTb9dAY61oD2KE8VPvh9Qkt.sp"}, {"hashrate1m": "0", "hashrate5m": "0", "hashrate1hr": "0", "hashrate1d": "24M", "hashrate7d": "422M", "lastupdate": 1459284547, "shares": 1862486, "bestshare": 0.0, "bestever": 3346091, "workername": "1PwftnJ5FhMhTb9dAY61oD2KE8VPvh9Qkt.88"}, {"hashrate1m": "0", "hashrate5m": "0", "hashrate1hr": "1.14K", "hashrate1d": "3.83G", "hashrate7d": "2.38G", "lastupdate": 1459284547, "shares": 14333545, "bestshare": 1516840.3880243786, "bestever": 11033324, "workername": "1PwftnJ5FhMhTb9dAY61oD2KE8VPvh9Qkt.7"}, {"hashrate1m": "0", "hashrate5m": "0", "hashrate1hr": "0", "hashrate1d": "0", "hashrate7d": "94.6K", "lastupdate": 1459284547, "shares": 231000, "bestshare": 0.0, "bestever": 173662, "workername": "1PwftnJ5FhMhTb9dAY61oD2KE8VPvh9Qkt.201"}, {"hashrate1m": "0", "hashrate5m": "0", "hashrate1hr": "1.17K", "hashrate1d": "4.22G", "hashrate7d": "2.95G", "lastupdate": 1459284547, "shares": 16149261, "bestshare": 59668.244952384652, "bestever": 9036481, "workername": "1PwftnJ5FhMhTb9dAY61oD2KE8VPvh9Qkt.s498"}, {"hashrate1m": "0", "hashrate5m": "0", "hashrate1hr": "0", "hashrate1d": "18.6M", "hashrate7d": "3.36G", "lastupdate": 1459284547, "shares": 8953949278, "bestshare": 0.0, "bestever": 6529849368, "workername": "1PwftnJ5FhMhTb9dAY61oD2KE8VPvh9Qkt."}, {"hashrate1m": "0", "hashrate5m": "0", "hashrate1hr": "1.38K", "hashrate1d": "4.33G", "hashrate7d": "2.27G", "lastupdate": 1459284547, "shares": 15846936, "bestshare": 517941.20130359975, "bestever": 70778845, "workername": "1PwftnJ5FhMhTb9dAY61oD2KE8VPvh9Qkt.baron"}, {"hashrate1m": "0", "hashrate5m": "0", "hashrate1hr": "1.23K", "hashrate1d": "3.99G", "hashrate7d": "2.22G", "lastupdate": 1459284547, "shares": 14354062, "bestshare": 229864.77214219442, "bestever": 267571121, "workername": "1PwftnJ5FhMhTb9dAY61oD2KE8VPvh9Qkt.chase"}, {"hashrate1m": "0", "hashrate5m": "0", "hashrate1hr": "0", "hashrate1d": "0", "hashrate7d": "51M", "lastupdate": 1459284547, "shares": 13892649, "bestshare": 0.0, "bestever": 3797299, "workername": "1PwftnJ5FhMhTb9dAY61oD2KE8VPvh9Qkt.33"}, {"hashrate1m": "6", "hashrate5m": "138M", "hashrate1hr": "56.7G", "hashrate1d": "8.11G", "hashrate7d": "7.81G", "lastupdate": 1459284547, "shares": 10803974, "bestshare": 514617.47145399998, "bestever": 206458625, "workername": "1PwftnJ5FhMhTb9dAY61oD2KE8VPvh9Qkt.DEwmt"}, {"hashrate1m": "0", "hashrate5m": "0", "hashrate1hr": "165", "hashrate1d": "541M", "hashrate7d": "554M", "lastupdate": 1459284547, "shares": 562394, "bestshare": 96499.848984600379, "bestever": 28492399, "workername": "1PwftnJ5FhMhTb9dAY61oD2KE8VPvh9Qkt.6417"}]}Note where the workers start. The total user summary is still only right at the start where it always was. |
|
|
|
|
This thread is only for support of the current official cgminer and bitcoin mining so you need to seek help from whoever is maintaining whatever fork you are using. Offtopic, including forks, CPU/GPU, old version and altcoin posts will be deleted.
|
|
|
|
ck, could you kind enough to explain to me about this scaling issue, preferably in noob wording lol...
In a regular pool, the more hashrate the pool has, the less variation there is in each miner's payouts. In p2pool it is biphasic. Initially as the hashrate of the pool increases your variation decreases, and then as the hashrate gets larger again, variation starts increasing again. If all miners were on p2pool, it'd be like they were solo mining at 1/20th of the current network diff which would be horrific variation. It's one of the limitations of the p2pool design that's been talked about, thrashed out and debated about for years on end without a solution. Oh, how skillfully you mislead people. This statement is false, because those miners who did not increase their capacity with the increasing of the total power of the pool, will get fewer benefits in any system of charges. At very high magnification power of a regular pool, there is a possibility that the weak miners (those who do not increase capacity) did not receive payments. For example, if I will mine on your CKPool with the usual CPU this is the same thing as I tried solo mining. Excuse me, but basically you seem to have no idea what you're talking about and it's hard to know if it's a language problem, ignorance or a combination of both. The solo pool I run is not regular pooled mining so it's pointless bringing that into the discussion. You asked for a simple explanation of why there's a scaling issue and I gave you the simplest possible explanation of what's wrong without describing at depth why. If you wish to understand further, please feel free to understand how pooled mining at other pools and p2pool work before arguing with me. I will not argue this further with you so feel free to have the final word which will make you feel like you've won the argument... until you educate yourself. |
|
|
|
ck, could you kind enough to explain to me about this scaling issue, preferably in noob wording lol...
In a regular pool, the more hashrate the pool has, the less variation there is in each miner's payouts. In p2pool it is biphasic. Initially as the hashrate of the pool increases your variation decreases, and then as the hashrate gets larger again, variation starts increasing again. If all miners were on p2pool, it'd be like they were solo mining at 1/20th of the current network diff which would be horrific variation. It's one of the limitations of the p2pool design that's been talked about, thrashed out and debated about for years on end without a solution. |
|
|
|
I've been reading about this p2pool difficulty scaling issue. It said the more hash power being put in, the more harder it gets and by the time it is high enough, it will be like solo mining.
This applies to any variant of mining, including a solo. Nonsense. Pooled mining is nothing like that, except in the case of p2pool. |
|
|
|
[2016-03-25 00:55:26.217] Possible block solve diff 1684119876772.186523 !
[2016-03-25 00:55:26.333] BLOCK ACCEPTED!
[2016-03-25 00:55:26.333] Solved and confirmed block 404180 by 17UhZWXLyiHmPmAb4VdFweGWRYY52qjxwp
[2016-03-25 00:55:26.333] User 17UhZWXLyiHmPmAb4VdFweGWRYY52qjxwp:{"hashrate1m": "38.3T", "hashrate5m": "37.3T", "hashrate1hr": "37.7T", "hashrate1d": "37T", "hashrate7d": "48.2T"}
[2016-03-25 00:55:26.333] Worker 17UhZWXLyiHmPmAb4VdFweGWRYY52qjxwp:{"hashrate1m": "38.3T", "hashrate5m": "37.3T", "hashrate1hr": "37.7T", "hashrate1d": "37T", "hashrate7d": "49.9T"}
[2016-03-25 00:55:26.333] Block solved after 503477725820 shares at 304.2% diff
|
|
|
|
|
The algorithm does not look at the timestamp at all, but when the blocks arrive.
|
|
|
|
does the large surge and drop negatively affect the pool ?
No |
|
|
|
Nahndo, I don't think the issues your condsidering reflect Kano or the server being able to handle the 35PH load. The hardware that the pool is on could easily handle the entire bitcoin network hashrate if it needed to with the current pool code. The database code less than that but Kano's always working on it and that never interferes with mining. |
|
|
|
I seem to recall someone a few years ago saying their chips didn't hash the full range or something. The numbers were something like 768 out of 1024 or equiv. Wonder if that has something to do with it.
I'm thinking it was BFL or the 55nm Bitfury. I'll look around and see if I can find the thread.
No, that's not a problem. It was bitfury chips but led to no problems like this whatsoever. |
|
|
|
Dammit, seems like Shirlock Holmes won't be able to track this one. So what checks do we have in place today to safeguard us from this issue? So these bastard took a bunch of BTC somewhere around 46BTC after the deduction from us? Don't make me get Putin to chase down their ass! Not cool.
There's a critical number of shares beyond which it becomes highly improbable that miners haven't submitted a certain number of high shares. This is what all the database work kano has been doing over the last few weeks has been towards detecting so in future it should be picked up much sooner. This almost certainly went on for much longer on other pools in the past, and may well still be ongoing now, but don't be quick to blame any runs of bad luck on this issue as it takes a lot of shares to detect, but fortunately the larger the miner, the faster they'll be picked up (and Kano checks for patterns from groups of miners in similar places to see they're not splitting their hashes across multiple accounts to hide it.) |
|
|
|
I guess I still cannot wrap my head around the motive for anyone doing this. Are they hoping that they can drive the pool luck down so that members leave and go.....where? Even if they could cause the pool luck to go down, how can they direct anyone to go where it would benefit them?
I can see that it happened and that they did it intentionally but I just don't see the end game for the perpetrators. Maybe I just can't think like the bad guys!
Hanlon's razor - "Never attribute to malice that which can be adequately explained by stupidity, but don't rule out malice." I doubt it started out as malice. Likely it started out as stupidity and has turned to malice over time. Since they never respond when directly questioned/emailed, the most likely explanation is this was a batch of custom miners that were faulty right from the beginning, be it due to firmware or dodgy software, that had a 32 bit signed integer limitation somewhere in their design that cannot be now fixed, or is not worth the effort to fix, and have been mining under the radar for ages on other pools without being noticed. Now that they have been noticed, they have been moving from pool to pool to try and be not noticed and appear to have no intention to try and fix the issue. |
|
|
|
Not really understanding Kano cause I'm just a miner Translation: Your big hasher "saradis" is likely mining useless hashes that can never find a block. |
|
|
|
|
Pull it apart for spare parts like the power supplies, the fans and the water coolers, and throw the rest in the bin.
|
|
|
|
Validating a block takes around 300ms on my pool.
My pool has the 2nd highest average block size.
The highest is solo.ckpool.org that also has this tiny time to validate blocks.
Minor correction. 300ms is the slowest block validation time. Some blocks are much faster to verify depending on how complex it is. Solo has different hardware and verifies in up to ~140ms by comparison. |
|
|
|
Ye I kinda had the same question but how DASH are doing it ?
The answer to that is likely "Badly, in an exploitable way." But no, I haven't looked at the code myself (nor have an interest in doing so), so it's pure speculation. |
|
|
|
|
Show Posts
