- Shares and stale counters can be reset, all at once or one at a time (total sum is still saved).
- Now you can delete workers if you don't need them anymore
Topic: [DEAD] DeepBit.net PPS+Prop,instant payouts, we pay for INVALID BLOCKS too - page 304. (Read 1601419 times)
March 17, 2011, 06:31:03 PM
UPDATES:
March 16, 2011, 05:17:23 PM
Tell me your login name so can check it at my side.
What is hashing speed of your miners ?
BTW, if you see a stale hash instantly after "new block" message, it means that your miner sent it's result just some milliseconds before or after LP notify, so it's normal. But 2% is definitely not normal for Long Polling. Is this number decreasing now or not ?
What is hashing speed of your miners ?
BTW, if you see a stale hash instantly after "new block" message, it means that your miner sent it's result just some milliseconds before or after LP notify, so it's normal. But 2% is definitely not normal for Long Polling. Is this number decreasing now or not ?
My login is jakiedentures (at) gmail.com
I get ~300 MH/s on my 6950 and ~70 MH/s on my 4850. The stale share % has not gone down and is sitting at 0.93% and 2.47% respectively
March 16, 2011, 03:19:57 PM
... I set my timeout to 15 ...
What are your command line options? How do you set the timeout?
I also lowered the clocks on my card to minimums to see if that was making things strange.
I also removed the frames flag.
I set the timeout in the python fileBitcoinMiner.py TIMEOUT = 15, I did that after having problems, and I'm still getting problems.
I have the latest git pull from a day ago.
17/03/2011 08:56:34, 225438 khash/s
17/03/2011 08:56:34, Stale hash. To reduce stales, use long polling, e.g. latest m0mchil's python miner
17/03/2011 08:56:35, 225269 khash/s
I am...
Repeates about every 30 seconds:
17/03/2011 09:00:55, Wrong data: checkWork: No record for this data, please set lower getwork timeout (5 seconds)
March 16, 2011, 01:28:04 PM
... I set my timeout to 15 ...
What are your command line options? How do you set the timeout?
March 16, 2011, 11:17:56 AM
I run find for a bit and then get these "errors" and it stops submitting new blocks. I set my timeout to 15. Any ideas?
16/03/2011 01:17:07, 310189 khash/s
16/03/2011 01:17:07, d3eab41a, accepted
16/03/2011 01:17:08, 310087 khash/s
....
16/03/2011 01:17:50, 310167 khash/s
16/03/2011 01:17:50, 18364559, accepted
16/03/2011 01:17:51, 310008 khash/s
....
16/03/2011 01:18:14, 310228 khash/s
16/03/2011 01:18:14, Wrong data: checkWork: this nonce already completed
16/03/2011 01:18:15, 310012 khash/s
.....
16/03/2011 01:19:28, 309955 khash/s
16/03/2011 01:19:29, long poll: new block
16/03/2011 01:19:29, 302538 khash/s
.....
16/03/2011 01:24:45, 309991 khash/s
16/03/2011 01:24:45, Wrong data: checkWork: this nonce already completed
16/03/2011 01:24:46, 309802 khash/s
....
16/03/2011 01:29:24, 309983 khash/s
16/03/2011 01:29:24, Wrong data: checkWork: No record for this data, please set
lower getwork timeout (5 seconds)
16/03/2011 01:29:26, 309819 khash/s
.....
16/03/2011 01:30:41, 309976 khash/s
16/03/2011 01:30:42, Wrong data: checkWork: No record for this data, please set
lower getwork timeout (5 seconds)
16/03/2011 01:30:43, 309700 khash/s
16/03/2011 01:17:07, 310189 khash/s
16/03/2011 01:17:07, d3eab41a, accepted
16/03/2011 01:17:08, 310087 khash/s
....
16/03/2011 01:17:50, 310167 khash/s
16/03/2011 01:17:50, 18364559, accepted
16/03/2011 01:17:51, 310008 khash/s
....
16/03/2011 01:18:14, 310228 khash/s
16/03/2011 01:18:14, Wrong data: checkWork: this nonce already completed
16/03/2011 01:18:15, 310012 khash/s
.....
16/03/2011 01:19:28, 309955 khash/s
16/03/2011 01:19:29, long poll: new block
16/03/2011 01:19:29, 302538 khash/s
.....
16/03/2011 01:24:45, 309991 khash/s
16/03/2011 01:24:45, Wrong data: checkWork: this nonce already completed
16/03/2011 01:24:46, 309802 khash/s
....
16/03/2011 01:29:24, 309983 khash/s
16/03/2011 01:29:24, Wrong data: checkWork: No record for this data, please set
lower getwork timeout (5 seconds)
16/03/2011 01:29:26, 309819 khash/s
.....
16/03/2011 01:30:41, 309976 khash/s
16/03/2011 01:30:42, Wrong data: checkWork: No record for this data, please set
lower getwork timeout (5 seconds)
16/03/2011 01:30:43, 309700 khash/s
March 16, 2011, 06:21:01 AM
I am at .19% stale 
Two crappy days in a row with 11 and 10 blocks found, respectively.
Two crappy days in a row with 11 and 10 blocks found, respectively.
March 16, 2011, 04:55:12 AM
I get 0.6~0.7 stale share with LP I believe. Not bad, but not perfect
Nothing is perfect and LP don't lead to absolute zero of stale shares; there are still latencies in server broadcasts, on network level, miner have to refresh his job internally etc. I think 0.3% is the minimum which can be done with current infrastructure, so 0.6% isn't SO bad.
Btw I'm thinking that better number for showing LP effectivity should be (stale shares)/(new blocks notifications), which tell us in how many cases was the LP broadcast too late. It is more exact than (stale shares)/(submitted shares), because this number depends also on bitcoin network speed (difficulty and hashrate) and when new blocks are coming faster or slower than before, this number will be affected. What do you think, Tycho?
March 16, 2011, 04:01:03 AM
I get 0.6~0.7 stale share with LP I believe. Not bad, but not perfect
It's very hard to get stales percentage lower than 0.3% because of network delay.And it depends on your hashing speed too. Your result is normal.
March 16, 2011, 03:06:10 AM
I get 0.6~0.7 stale share with LP I believe. Not bad, but not perfect
March 16, 2011, 01:33:00 AM
Any idea how I can get long polling working? There's no extra flags required to enable it, correct?
Tell me your login name so can check it at my side.What is hashing speed of your miners ?
BTW, if you see a stale hash instantly after "new block" message, it means that your miner sent it's result just some milliseconds before or after LP notify, so it's normal. But 2% is definitely not normal for Long Polling. Is this number decreasing now or not ?
March 15, 2011, 05:58:18 PM
Hey Tycho, Great pool you've got running however I've been using the latest version (2011/03/11) m0mchil's python miner but it seems that long polling isn't working for some reason.
I get these messages when mining occasionally:
And my stats page says I've been submitting 0.97% and 2.21% stale shares for my miners
Any idea how I can get long polling working? There's no extra flags required to enable it, correct?
I get these messages when mining occasionally:
Quote
15/03/2011 17:41:31, long poll: new block
Stale hash. To reduce stales, use long polling, e.g. latest m0mchil's python min
Stale hash. To reduce stales, use long polling, e.g. latest m0mchil's python min
And my stats page says I've been submitting 0.97% and 2.21% stale shares for my miners
Any idea how I can get long polling working? There's no extra flags required to enable it, correct?
March 15, 2011, 11:16:09 AM
I've got two machines mining, both at fairly low bitrates, 6M and 73M. Both of them are running the latest poclbm. My status page (for accounts tlyons@ive.*) show my two accounts at 1.91% and 1.49% stale, respectively. Is that statistic over the life of the account? Because I just started using the new poclbm about 24 hours ago, but was using it for a couple weeks before that.
Look at each worker's page - there is a time and date of last reset for those counters. Today i'll add manual reset button for users.If you switched to long polling just one day ago, then it includes old results too. If everything is working correctly, then stale percentage should be decrementing slowly.
I also see this occasionally:
Is there anything I might want to tweak on this?
This one is already fixed. Code:
15/03/2011 08:41:16, long poll: backend error
March 15, 2011, 11:07:59 AM
it seems i get more and more of these
I see that you are sending more stale shares than expected (but less than 1%, anyway).Quote
Stale hash. To reduce stales, use long polling, e.g. latest m0mchil's python miner
while already using latest m0mchil's python miner. Trying to find the cause of this.
In addition, I see log entries such as this occasionally (times are UTC -0700) :
Code:
15/03/2011 06:40:30, 5ab08224, accepted
15/03/2011 06:41:38, long poll: Deepbit is temporarily unavailable
15/03/2011 06:42:13, ea0227f4, accepted
15/03/2011 06:42:57, d260477e, accepted
15/03/2011 06:43:45, long poll: new block
I also see this occasionally:
Code:
15/03/2011 08:41:16, long poll: backend error
Regards... Todd
March 15, 2011, 07:51:05 AM
UPDATES:
- Now you can see number of contributed shares per each worker.
- Stale shares percentage is also shown. If you are sending more than 1% stale shares and are mining with GPU, please update your miner to the latest version of m0mchil's poclbm miner.
- Worker names are shown in red color if no share was received in the last 30 minutes.
March 15, 2011, 07:14:42 AM
troll
March 15, 2011, 02:31:27 AM
Please remove the word "fair" from your thread title. Implying that Slush is purposefully "unfair" is an offensive patently false lie propagated through an unwillingness to understand statistics. (and pure malice by some)
Slush has shown the statistical charts proving that the score based reward system distributes just as equally as a shares based reward system.
I also "like" the implication that a 3% fee is more "fair" than a 2% fee.
Slush has shown the statistical charts proving that the score based reward system distributes just as equally as a shares based reward system.
I also "like" the implication that a 3% fee is more "fair" than a 2% fee.
Please remove the words "patently false" from your post. Any lie is, by definition, patently false. Please also remove the words "Slush" and "purposefully" since there is nothing in the original post mentioning Slush or that anybody has done anything on purpose. While you are at it, remove the word "imply" since the original statements did not imply anything more than stated. "Propagated" is improper since the misunderstanding of statistics actually diminishes on this board, as good people like yourself explain probability. "Unwillingness" is also incorrect, since the people who spread rumors are usually just stupid and not "unwilling" to "understand". In fact, we know nothing about their level of understanding, so strike that too. Your post must read, "Please the thread title offensive lie statistics." When you are done editing, please leave this forum for one week in compliance with your new rule that one forum member can direct another on what he or she must do.
March 14, 2011, 08:03:35 PM
it seems i get more and more of these
I see that you are sending more stale shares than expected (but less than 1%, anyway).Quote
Stale hash. To reduce stales, use long polling, e.g. latest m0mchil's python miner
while already using latest m0mchil's python miner. Trying to find the cause of this.
March 14, 2011, 05:14:26 PM
my timezone is not supported, my machines are operating in Timezone GMT+13
would you mind adding that one?
Fixed. would you mind adding that one?
March 14, 2011, 05:02:10 PM
Hi Tycho,
my timezone is not supported, my machines are operating in Timezone GMT+13
would you mind adding that one?
cheers.
March 14, 2011, 02:16:41 PM
it seems i get more and more of these
Quote
Stale hash. To reduce stales, use long polling, e.g. latest m0mchil's python miner
while already using latest m0mchil's python miner. Jump to: