- Joined
- Jun 15, 2019
- Posts
- 222
- Reaction score
- 65
ok, so weve now added a too soon / too early statement to the catch summary in the software, item 5 after the avail function will show this, as will an appendment to the email advice.
But, we never included it before, as there are many variables that make this unreliable :
1. Every domain seems to have a queue length to submit writes, the more popular the domain, the longer delay is needed, weve caught domains at 600ms before the advertised drop.
2, The read cycle after a write also suffers from the above, probably due to the shear amount of reads requested after writes on popular domains.
3. The parsing function of a domain check also has its own delays on submission and response, weve measeured upto 25ms, meaning the too late / early response could be an additional time out of sync value.
4. Running multiple writes will alter the result, as each will have an internal system delay (70us) or more importantly, the read responses, where only the last read will count. If your testing, use a single write.
5. NTP time shift even by a few ms can change the response, even if you run a atomic clock (like us) , this may not help, as we dont know what stratum nominet use.
In any event, those that use the software will know that the writes, delay between writes and delay itself are all changeable on the fly.
Rgds
Bill
But, we never included it before, as there are many variables that make this unreliable :
1. Every domain seems to have a queue length to submit writes, the more popular the domain, the longer delay is needed, weve caught domains at 600ms before the advertised drop.
2, The read cycle after a write also suffers from the above, probably due to the shear amount of reads requested after writes on popular domains.
3. The parsing function of a domain check also has its own delays on submission and response, weve measeured upto 25ms, meaning the too late / early response could be an additional time out of sync value.
4. Running multiple writes will alter the result, as each will have an internal system delay (70us) or more importantly, the read responses, where only the last read will count. If your testing, use a single write.
5. NTP time shift even by a few ms can change the response, even if you run a atomic clock (like us) , this may not help, as we dont know what stratum nominet use.
In any event, those that use the software will know that the writes, delay between writes and delay itself are all changeable on the fly.
Rgds
Bill
