[ntp:questions] Re: ntpd, boot time, and hot plugging

David L. Mills mills at udel.edu
Fri Feb 4 02:15:44 UTC 2005

Brad & Co.,

I make no value judgements in any form here, but I do observe just about 
every motherboard on the planet today has a TOY clock which is updated 
occasionally by the operating system. So, a machine coming up to sell an 
Airbus is probably pretty close, at least within the second if the TOY 
time since the last update was not too long and in that case you might 
have lost a large number of Airbus sales anyway.

Here's how to sell more Airba. The operating system should write the TOY 
time and offset within the second to a file from time to time keeping a 
history of at least the last two updates. Assuming the motherboard is 
not tossed in the frigid sea or boiling desert, the operating system (or 
NTP) can retrieve these values, compute the time and current offset and 
set the clock with good accuracy.


Brad Knowles wrote:
> At 10:21 AM -0500 2005-02-03, Tom Smith wrote:
>>>      With a decent drift file ...
>>  Precisely. The decent drift file is a problem. It sometimes doesn't
>>  exist after a large initial offset has been turned over to ntpd.
>     Even without a good drift file, you can still sync very quickly. It 
> may not be seven seconds, it may be fifteen.  But that should still be 
> tolerable.
>>  You should discuss that with a bank or stock exchange that
>>  is losing millions in transactions during those seconds
>>  or with public utility that is paying the government
>>  penalties for downtime. :-)
>     My wife is general counsel, head of legal, and secretary to the 
> board for the world's largest clearing and settlement firm for European 
> stocks and bonds, with an annual turnover in excess of 256 trillion Euro 
> last year, and assets under management in excess of twelve trillion 
> Euros.  Yes, I mean trillion.
>     When Argentina decides not to make their interest payments on their 
> Brady bond debt, because 80% of their bonds are held through her 
> company, the final decision of whether or not to declare what used to be 
> the world's seventh largest economy officially bankrupt, arrives on her 
> desk.
>     I understand the scale of the problem.  With over a trillion Euro of 
> turnover in a single workday, milliseconds do count.
>>  Well, no. As David pointed out in his posting, all engineering
>>  is a matter of tradeoffs. For many users, the tradeoff needs
>>  to be 'Get these applications up fast on a "good enough"
>>  time and refine the time (and frequency) in the background.'
>     So, doing a single query and taking whatever bogus time may be set 
> from that server, is more important than waiting a few more seconds to 
> make sure that you've got a pretty good timesync?
>     I'm sorry, I don't buy it.  The bigger the application, the more you 
> have to lose, the more important it is to have good time sync.
>     See above -- milliseconds do count.
>>  Perhaps it is. For you. If it's seven seconds.
>     For financial applications, if the server goes down, then your N+M 
> fault-tolerant systems take over that load, and not a single transaction 
> is dropped or excessively delayed.  If your main server facility is 
> taken out by terrorists or natural disaster, then your hot spare 
> facility, that is located hundreds or thousands of miles away, takes 
> over and a few transactions might be delayed, but nothing is dropped.
>     If you're running something that mission-critical and you don't have 
> those kinds of systems (which can tolerate a few extra seconds of 
> startup time in order to ensure that the time is set reasonably well), 
> then you are shooting yourself in the foot with a thermonuclear weapon, 
> and you will get what you deserve.

More information about the questions mailing list