Title: X-Roll-Ntime extension Post by: Luke-Jr on 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? Title: Re: X-Roll-Ntime extension Post by: gmaxwell on 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? Title: Re: X-Roll-Ntime extension Post by: Luke-Jr on 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. N seconds or ntime incremented by N?Thoughts? Title: Re: X-Roll-Ntime extension Post by: fpgaminer on June 26, 2011, 07:25:34 AM Quote 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?Title: Re: X-Roll-Ntime extension Post by: gmaxwell on June 26, 2011, 07:29:46 AM Quote 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. Title: Re: X-Roll-Ntime extension Post by: JoelKatz on June 27, 2011, 10:53:14 AM Quote 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?Title: Re: X-Roll-Ntime extension Post by: Luke-Jr on 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. Title: Re: X-Roll-Ntime extension Post by: vector76 on 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. Title: Re: X-Roll-Ntime extension Post by: Luke-Jr on 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.Title: Re: X-Roll-Ntime extension Post by: vector76 on 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.
|