Topic: X-Roll-Ntime extension (Read 5037 times)
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.
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. Due to network latency, I recommend the following design for miners:
1. getwork, record and , and begin mining on it
2. every second, update ntime and reset nonce to
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 minus times 4, begin a request for new work
6. when new work arrives, discard old work and begin using the new work.
1. getwork, record
2. every second, update ntime and reset nonce to
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
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.
Due to network latency, I recommend the following design for miners:
1. getwork, record and , and begin mining on it
2. every second, update ntime and reset nonce to
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 minus times 4, begin a request for new work
6. when new work arrives, discard old work and begin using the new work.
1. getwork, record
2. every second, update ntime and reset nonce to
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
6. when new work arrives, discard old work and begin using the new work.
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?
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.
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? 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?Thoughts?
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?
Thoughts?
N seconds or ntime incremented by N?
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?
Thoughts?
Jump to: