I am trying to copy paste the output of cgminer, but that proves more difficult than I thought
Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 945. (Read 4382653 times)
October 29, 2011, 12:28:29 PM
Username: dutchbratslaves
I am trying to copy paste the output of cgminer, but that proves more difficult than I thought
I am trying to copy paste the output of cgminer, but that proves more difficult than I thought
October 29, 2011, 12:27:34 PM
What's your pool username? (I don't see submits from DutchBrat in last moments) I'll follow it on my side.
October 29, 2011, 12:17:46 PM
Maybe some 20 mins
My hashrate over all my miners is dropping steadily (this one miner hashes at around 280 MHash but has an avg of 213 MHash now, I restarted it 2 hours ago)
The estimated reward is also dropping from 0.08 to 0.049 at this very moment which is consistent with the drop in my hashrate because of the connection problems
Strange, maybe a hiccup on my own network
I'll let the ping run for a while
My hashrate over all my miners is dropping steadily (this one miner hashes at around 280 MHash but has an avg of 213 MHash now, I restarted it 2 hours ago)
The estimated reward is also dropping from 0.08 to 0.049 at this very moment which is consistent with the drop in my hashrate because of the connection problems
Strange, maybe a hiccup on my own network
I'll let the ping run for a while
October 29, 2011, 12:17:32 PM
Pinging api.bitcoin.cz [178.79.183.97] with 32 bytes of data:
Looking good to me
Looking good to me
Yes, it's fine. How often do you see that error? How long it is since last message?
I've been seeing this off-and-on today, also with cgminer, going to api2. I'm keeping an eye out for it happening again now..
October 29, 2011, 12:14:15 PM
Pinging api.bitcoin.cz [178.79.183.97] with 32 bytes of data:
Looking good to me
Looking good to me
Yes, it's fine. How often do you see that error? How long it is since last message?
October 29, 2011, 12:12:42 PM
Pinging api.bitcoin.cz [178.79.183.97] with 32 bytes of data:
Reply from 178.79.183.97: bytes=32 time=6ms TTL=54
Reply from 178.79.183.97: bytes=32 time=6ms TTL=54
Reply from 178.79.183.97: bytes=32 time=6ms TTL=54
Reply from 178.79.183.97: bytes=32 time=6ms TTL=54
Looking good to me
Reply from 178.79.183.97: bytes=32 time=6ms TTL=54
Reply from 178.79.183.97: bytes=32 time=6ms TTL=54
Reply from 178.79.183.97: bytes=32 time=6ms TTL=54
Reply from 178.79.183.97: bytes=32 time=6ms TTL=54
Looking good to me
October 29, 2011, 12:08:31 PM
Is this because of the switch to a French provider ?
Not yet.
It's cgminer, right? Whats your ping to api.bitcoin.cz?
Edit: I'm monitoring pool response times once they took longer than 2 seconds; it happen time to time and it's an idicator that something is broken. But now there's no problem with response times, they're far under this threshold (actually most loaded pool backend has server load 0.15, which is excellent), so I don't see any reason why you should see this error.
Edit2: Also is there any ping packetloss?
October 29, 2011, 12:05:03 PM
I am experiencing a lot of:
'Pool not providing work fast enough'
'Pool not responding'
Errors
Is this because of the switch to a French provider ?
'Pool not providing work fast enough'
'Pool not responding'
Errors
Is this because of the switch to a French provider ?
October 29, 2011, 10:44:23 AM
It's one exponent function per share PER USER. if you have 200 users you are doing this calculation 200 times for each share? then adding the new score to the cumulative score for each user and storing that in memory? for all the millions of shares?
As you already realized, score is calculated only for one share submit, not for submit*users :-).
October 29, 2011, 10:43:19 AM
It's a good thing luck evens out in infinity,
so give it a few more years and we will be alright
Brat
so give it a few more years and we will be alright
Brat
October 29, 2011, 10:42:37 AM
It is great mining for NMC in Slush's Pool but my luck is real bad on BTC for quite sometime.
Is your expected round reward significantly lower than it should be? For eliminate effect of score based system, you can take last 50 round rewards and recalculate it with proportional method (your hashrate against pool hashrate, which is pretty constant around 1170 for last few days).
If this fits, then it's pool luck (well, we performed pretty bad last few days). If it don't fit, then we need to investigate more. Usually it's because of some connection troubles, rejected shares or crippled miner software or cards. Actually I don't have a reason to think there's some flaw in pool code, I didn't touch important stuff for many weeks and merged mining cannot affect this.
October 29, 2011, 10:33:17 AM
It is great mining for NMC in Slush's Pool but my luck is real bad on BTC for quite sometime.
October 29, 2011, 10:32:07 AM
score = score + exp(round_time/C)
This is done for every submitted share immediately.
Quote
reward = user score / total score * 50
This is done on the end of round.
Quote
Is it really done for EVERY submitted share for EVERY user?
Yes, why not? It's one exponent function per share. With current multigigahertz machines it really isn't an issue :-).
It's one exponent function per share PER USER. if you have 200 users you are doing this calculation 200 times for each share? then adding the new score to the cumulative score for each user and storing that in memory? for all the millions of shares?
not that it would be difficult for the modern pc, but my question is if it is done on an ongoing basis, then why does it take about 10 minutes to publish the rewards after each round?
BTW, thx for the lightning fast response
sorry, just realized my mistake, a share is not submitted by multiple users and still be valid. so no need to multiply by number of users...
October 29, 2011, 10:29:25 AM
score = score + exp(round_time/C)
This is done for every submitted share immediately.
Quote
reward = user score / total score * 50
This is done on the end of round.
Quote
Is it really done for EVERY submitted share for EVERY user?
Yes, why not? It's one exponent function per share. With current multigigahertz machines it really isn't an issue :-).
It's one exponent function per share PER USER. if you have 200 users you are doing this calculation 200 times for each share? then adding the new score to the cumulative score for each user and storing that in memory? for all the millions of shares?
not that it would be difficult for the modern pc, but my question is if it is done on an ongoing basis, then why does it take about 10 minutes to publish the rewards after each round?
BTW, thx for the lightning fast response
October 29, 2011, 10:23:00 AM
score = score + exp(round_time/C)
This is done for every submitted share immediately.
Quote
reward = user score / total score * 50
This is done on the end of round.
Quote
Is it really done for EVERY submitted share for EVERY user?
Yes, why not? It's one exponent function per share. With current multigigahertz machines it really isn't an issue :-).
October 29, 2011, 10:11:11 AM
Question for Slush:
In describing the logic/calculation of the score-based system, you mentioned this:
====
Matematically said, for every submitted share, pool perform
Code:
score = score + exp(round_time/C)
round_time is count of seconds between "now" and time when round started, C is magic constant which define how fast old shares lose their value. All following calculations are using C=300, but it may be changed in the future to provide the best cheatproof/usability ratio.
And on the end of round, system calculate rewards using formula
Code:
reward = user score / total score * 50
====
Is it really done for EVERY submitted share for EVERY user? that's a lot of calculations, no? or is there some other interval used to calculate the scores? maybe the scores are calculated at the end of each round?
please enlighten....
In describing the logic/calculation of the score-based system, you mentioned this:
====
Matematically said, for every submitted share, pool perform
Code:
score = score + exp(round_time/C)
round_time is count of seconds between "now" and time when round started, C is magic constant which define how fast old shares lose their value. All following calculations are using C=300, but it may be changed in the future to provide the best cheatproof/usability ratio.
And on the end of round, system calculate rewards using formula
Code:
reward = user score / total score * 50
====
Is it really done for EVERY submitted share for EVERY user? that's a lot of calculations, no? or is there some other interval used to calculate the scores? maybe the scores are calculated at the end of each round?
please enlighten....
October 29, 2011, 06:16:20 AM
This weekend (29-30. October) I'm migrating pool from London (linode.com) to France (ovh.com). Although I believe everything will be fine, there will be at least one outage during database migration (probably something around 30 minutes).
October 28, 2011, 01:59:36 AM
Looks alright on my end 
October 28, 2011, 01:51:58 AM
Most of my miners are getting:
Pool not responding errors
Are we being attacked again
Pool not responding errors
Are we being attacked again
October 27, 2011, 09:22:43 AM
Hello everybody,
Is the pool ok?
As for me the current 9+ hour block looks a bit unlucky.
And the previous 4 hour too.
Is the pool ok?
As for me the current 9+ hour block looks a bit unlucky.
And the previous 4 hour too.
Yeah, im sure it's just unlucky. I've seen 12+ hour blocks in the recent past (not counting the 1 1/2 day block from when the pool was ddos'ed).
Didn't happen as often when the pool was up around 2000 ghash, but now that its around 1200/1300 there is a lot more variance.
Jump to: