DrHaribo (OP)
Legendary
Offline
Activity: 2730
Merit: 1034
Needs more jiggawatts
|
|
October 11, 2012, 07:38:23 AM |
|
Some server changes are in. CPU usage reduced by 20-25%. The server is now also using Luke-jr's trick of sending pre-computed "empty" blocks (only transaction is the generation transaction) through long poll. So now the load spikes from abusive miners are greatly reduced and long poll is faster. This results in much fewer rejects than we've seen in the last few days and the delay you would sometimes see with getting work after long poll seems essentially gone.
At the moment for the current round I have 0.04% rejects. Pool wide rejects are 0.43% though. I would have hoped to get this lower. Let me know if you still have a high reject ratio and I'll see what I can do.
Namecoin rejects are sometimes very high. I suspect some miners are configured to ignore namecoin long polls. Not a big deal I guess, with namecoin value being what it is.
Note: every round starts with rejected work. If you see 10% rejected in the first second of a round, that's normal. Round data is more useful to look at after it has gone over, say, 30 minutes.
|
|
|
|
QuantumFoam
Full Member
Offline
Activity: 200
Merit: 100
|Quantum|World's First Cloud Management Platform
|
|
October 11, 2012, 06:43:52 PM |
|
kano, yea that thread is huge and I haven't been keeping up with it for several months. My bad. Thanks for the link! It'll be easy to keep cgm updated now.
|
|Quantum|World's First Cloud Management Platform on the Blockchain
|
|
|
Shermo
|
|
October 11, 2012, 07:52:07 PM |
|
My efficiency seems to be significantly increased since your changes DrHaribo On my 6870 machine its gone from about 280% to 450%, rejects seem to be better too!
|
|
|
|
narousberg
Legendary
Offline
Activity: 1753
Merit: 1007
|
|
October 11, 2012, 08:18:47 PM |
|
My efficiency seems to be significantly increased since your changes DrHaribo On my 6870 machine its gone from about 280% to 450%, rejects seem to be better too! yes, less rejects too (ztex quads)
|
I AM NOT SELL MY BITCOINTALK ACCOUNT !!!
|
|
|
Shermo
|
|
October 12, 2012, 10:29:52 AM |
|
Seems the site and pool server went down briefly and now seems really sluggish...
|
|
|
|
DrHaribo (OP)
Legendary
Offline
Activity: 2730
Merit: 1034
Needs more jiggawatts
|
|
October 12, 2012, 11:03:12 AM |
|
A bit of russian DDoS attack on the web server currently taking place. Sorry for the instability. Mining looks fine so far, though.
|
|
|
|
Shermo
|
|
October 12, 2012, 11:10:21 AM |
|
Looking at the stats my home machines using cgminer seem to be fine. I only noticed because my work PC went quiet all of a sudden, it is using the BitMinter Java client with the port 80 switch... so I guess that doesn't use long polling as it keeps running out of work? [EDIT] Work PC seems to be OK now actually, it was working and then dropping but it seems to be going steady again now
|
|
|
|
DrHaribo (OP)
Legendary
Offline
Activity: 2730
Merit: 1034
Needs more jiggawatts
|
|
October 12, 2012, 11:40:04 AM |
|
Looking at the stats my home machines using cgminer seem to be fine. I only noticed because my work PC went quiet all of a sudden, it is using the BitMinter Java client with the port 80 switch... so I guess that doesn't use long polling as it keeps running out of work?
Sure it uses long polling, or it would cause a lot of rejects. But it goes through the web server. Not recommended unless you really need to use port 80 because that's all your firewall allows.
|
|
|
|
DrHaribo (OP)
Legendary
Offline
Activity: 2730
Merit: 1034
Needs more jiggawatts
|
|
October 13, 2012, 02:24:52 PM Last edit: October 13, 2012, 05:24:47 PM by DrHaribo |
|
Small server update today: - Increase shift size (PPLNS with N=4x difficulty). This should reduce variance for part-time mining and if you have some downtime on your rigs.
- Implemented getwork "midstate" extension. Most miners support this now. It reduces bandwidth a little and also CPU usage on the server.
- Small speedup for long poll
- Small speedup in checking proofs of work
Only shaved a few percent off the server CPU usage this time, but every bit helps. EDIT: most browsers of course I meant most miners support this now. Also, if your livestats don't show shift progression correctly (100% when only half done), try clearing your browser cache and reloading the page.
|
|
|
|
Digigami
|
|
October 13, 2012, 10:29:31 PM |
|
sweet
|
|
|
|
QuantumFoam
Full Member
Offline
Activity: 200
Merit: 100
|Quantum|World's First Cloud Management Platform
|
|
October 14, 2012, 03:19:12 AM |
|
Noticed my hash rate has increased by about 5Mh/s per gpu ever since the recent server changes.
|
|Quantum|World's First Cloud Management Platform on the Blockchain
|
|
|
Shermo
|
|
October 14, 2012, 09:45:22 AM |
|
The pool seems to be running really sweetly with all the recent changes, my efficiency is over 500% now on my single GPU system, and my rejects are very very low compared to before Great work DrHaribo!
|
|
|
|
loshia
Legendary
Offline
Activity: 1610
Merit: 1000
|
|
October 14, 2012, 03:05:12 PM |
|
The pool seems to be running really sweetly with all the recent changes, my efficiency is over 500% now on my single GPU system, and my rejects are very very low compared to before Great work DrHaribo! +1 You are the man DOC:)
|
|
|
|
Mobius
|
|
October 14, 2012, 03:14:43 PM |
|
When will you implement var diff for miners?
|
|
|
|
ralree
|
|
October 14, 2012, 05:38:49 PM |
|
- 170,100 shares accepted since last cgminer restart
- 139 rejects
That's 0.08%! Cheers!
|
1MANaTeEZoH4YkgMYz61E5y4s9BYhAuUjG
|
|
|
QuantumFoam
Full Member
Offline
Activity: 200
Merit: 100
|Quantum|World's First Cloud Management Platform
|
|
October 14, 2012, 07:33:34 PM |
|
(5s):2480.2 (avg):2486.0 Mh/s | Q:7925 A:88271 R:112 HW:0 E:1114% U:34.7/m
Pretty sweet
|
|Quantum|World's First Cloud Management Platform on the Blockchain
|
|
|
DrHaribo (OP)
Legendary
Offline
Activity: 2730
Merit: 1034
Needs more jiggawatts
|
|
October 14, 2012, 07:59:36 PM |
|
Great to hear the new server changes are working out Yes, variable difficulty will be coming soon. I'm currently working on some changes to support multiple mining servers. I thought that might be a good idea to do first as it will make it easier to test var diff. It could also be useful to have a couple more servers when ASICs turn up.
|
|
|
|
jamesg
VIP
Legendary
Offline
Activity: 1358
Merit: 1000
AKA: gigavps
|
|
October 14, 2012, 08:18:50 PM Last edit: October 15, 2012, 11:33:04 AM by gigavps |
|
Great to hear the new server changes are working out Yes, variable difficulty will be coming soon. I'm currently working on some changes to support multiple mining servers. I thought that might be a good idea to do first as it will make it easier to test var diff. It could also be useful to have a couple more servers when ASICs turn up. Are you sure you would even need extra servers with variable diff? You already have rollNTime support so the most requests coming to the pool server are share submissions. With a variable diff solution that uses X-Mining-Hashrate you could greatly reduce the pools current load. You could also fall back to the server calculating the var diff to keep share submission below a maximum threshold of say 24 shares per minute. I guess my main point is that IMHO it is a higher priority to have variable difficulty working with either GBT or stratum than to have multiple pool servers. You might never need an extra pool server with these other pieces in place.
|
|
|
|
Krak
|
|
October 14, 2012, 11:35:06 PM |
|
Are you sure you would even need extra servers with variable diff? You already have rollNTime support so the most requests coming to the pool server are share submissions. With a variable diff solution that uses X-Mining-Hashrate you could greatly reduce the pools current load. You could also fall back to the server calculating the var diff to keep share submission below a maximum threshold of say 24 shares per minute.
I guess my main point is that IMHO it is a higher priority to have variable difficulty working with either GBT or stratum than to have multiple pool servers. You might never need an extra pool server with these other pieces in place.
Yeah, but a US server would be nice. I can easily hit < 0.01% rejects on MaxBTC just because my ping to their server is ~30ms.
|
BTC: 1KrakenLFEFg33A4f6xpwgv3UUoxrLPuGn
|
|
|
-ck
Legendary
Offline
Activity: 4284
Merit: 1645
Ruu \o/
|
|
October 15, 2012, 12:57:59 AM |
|
Are you sure you would even need extra servers with variable diff? You already have rollNTime support so the most requests coming to the pool server are share submissions. With a variable diff solution that uses X-Mining-Hashrate you could greatly reduce the pools current load. You could also fall back to the server calculating the var diff to keep share submission below a maximum threshold of say 24 shares per minute.
I guess my main point is that IMHO it is a higher priority to have variable difficulty working with either GBT or stratum than to have multiple pool servers. You might never need an extra pool server with these other pieces in place.
Yeah, but a US server would be nice. I can easily hit < 0.01% rejects on MaxBTC just because my ping to their server is ~30ms. The ping time factor is overrated. I've tried different servers from the same pool located at 250ms and 50ms ping times and the reject rate was identical. On the other hand, changes to the pool setup itself cause larger changes to the reject rate.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
|