Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
June 25, 2011, 09:08:24 PM |
|
As far as I know, the actual value of the X-Roll-Ntime header is presently undefined. I would like to suggest that if it contains expire=N, then the work is valid for up to N seconds. This can allow miners to know precisely when to give up on it and get new work.
Thoughts?
|
|
|
|
|
|
The forum strives to allow free discussion of any ideas. All policies are built around this principle. This doesn't mean you can post garbage, though: posts should actually contain ideas, and these ideas should be argued reasonably.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8343
|
|
June 26, 2011, 03:20:12 AM |
|
As far as I know, the actual value of the X-Roll-Ntime header is presently undefined. I would like to suggest that if it contains expire=N, then the work is valid for up to N seconds. This can allow miners to know precisely when to give up on it and get new work. Thoughts?
N seconds or ntime incremented by N?
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
June 26, 2011, 05:30:46 AM |
|
As far as I know, the actual value of the X-Roll-Ntime header is presently undefined. I would like to suggest that if it contains expire=N, then the work is valid for up to N seconds. This can allow miners to know precisely when to give up on it and get new work. Thoughts?
N seconds or ntime incremented by N? There shouldn't be a difference...
|
|
|
|
fpgaminer
|
|
June 26, 2011, 07:25:34 AM |
|
This can allow miners to know precisely when to give up on it and get new work. How would the pool provide a sane value, since it doesn't know when the next block will be found?
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4158
Merit: 8343
|
|
June 26, 2011, 07:29:46 AM |
|
This can allow miners to know precisely when to give up on it and get new work. How would the pool provide a sane value, since it doesn't know when the next block will be found? Long polling, of course. The pool knows how old a block header its willing to accept, which is what this is useful for.
|
|
|
|
JoelKatz
Legendary
Offline
Activity: 1596
Merit: 1012
Democracy is vulnerable to a 51% attack.
|
|
June 27, 2011, 10:53:14 AM |
|
This can allow miners to know precisely when to give up on it and get new work. How would the pool provide a sane value, since it doesn't know when the next block will be found? The pool operator will choose a sane value, or a sane algorithm based upon the difficulty.
|
I am an employee of Ripple. Follow me on Twitter @JoelKatz 1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
July 15, 2011, 08:10:48 PM |
|
Due to network latency, I recommend the following design for miners: 1. getwork, record <duration of getwork request> and <time+getwork expire> , and begin mining on it 2. every second, update ntime and reset nonce to <first nonce> 3. when a share is found, submit it. record the duration of the submit request. 4. if a share submission fails due to a network error, save the share and retry it a second later the same as step 3; also immediately (regardless of how long the current work has been active) begin trying to get new work (which is treated the same as step 5+6 when done) 5. when current time is past <time@1+getwork expire> minus <duration of longest getwork/submit since we started this work> times 4, begin a request for new work 6. when new work arrives, discard old work and begin using the new work.
|
|
|
|
vector76
Member
Offline
Activity: 70
Merit: 18
|
|
July 15, 2011, 08:48:41 PM |
|
Due to network latency, I recommend the following design for miners: 1. getwork, record <duration of getwork request> and <time+getwork expire> , and begin mining on it 2. every second, update ntime and reset nonce to <first nonce> 3. when a share is found, submit it. record the duration of the submit request. 4. if a share submission fails due to a network error, save the share and retry it a second later the same as step 3; also immediately (regardless of how long the current work has been active) begin trying to get new work (which is treated the same as step 5+6 when done) 5. when current time is past <time@1+getwork expire> minus <duration of longest getwork/submit since we started this work> times 4, begin a request for new work 6. when new work arrives, discard old work and begin using the new work.
If I understand this correctly, rather than waiting until the exact getwork expire deadline, you are getting new work a little bit early, based on how long the getwork/submit request takes? So for example if getwork takes at most 5 seconds you get new work 20 seconds before the current work expires, to avoid submitting expired shares. What about just a fixed percentage or a fixed duration? I might worry that this scheme could have unintended side-effects. If server load increases lagginess, it could be self-reinforcing if it increases the chances that the miners will decide to refresh their work. What might have been randomly spread out over time could become concentrated and bursty. I am visualizing sand dunes but I can't connect it with words.
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
July 15, 2011, 08:54:08 PM |
|
If I understand this correctly, rather than waiting until the exact getwork expire deadline, you are getting new work a little bit early, based on how long the getwork/submit request takes? So for example if getwork takes at most 5 seconds you get new work 20 seconds before the current work expires, to avoid submitting expired shares. Correct. What about just a fixed percentage or a fixed duration? I might worry that this scheme could have unintended side-effects. If server load increases lagginess, it could be self-reinforcing if it increases the chances that the miners will decide to refresh their work. What might have been randomly spread out over time could become concentrated and bursty. I am visualizing sand dunes but I can't connect it with words. I don't think there is any way to avoid this potential problem. Surely you don't want to suggest miners do stale work? A fixed percentage/duration would not adapt well to the many different network links/distances that can affect latency.
|
|
|
|
vector76
Member
Offline
Activity: 70
Merit: 18
|
|
July 16, 2011, 01:31:23 PM |
|
Not a big deal. I guess if it becomes a problem the pool can dither N. Which they would probably want to do anyway to avoid a spike exactly N seconds after a new block.
|
|
|
|
|