Determining actual elapsed (wall-clock) time

John Machin sjmachin at lexicon.net
Sun Jul 3 02:11:20 CEST 2005


Roy Smith wrote:
> Peter Hansen <peter at engcorp.com> wrote:
> 
>>I guess as long as the NTP client is set up to ensure the time 
>>adjustments are smaller than some value X, it would be acceptable.
> 
> 
> NTP is generally capable of keeping the various system clocks on a LAN 
> within a few ms of each other, and within a few 10's of ms over the 
> Internet from GPS, WWV, or similar international time references.
> 
> 
>>I'll have to look into how to set up Windows XP to prevent users from 
>>changing the time on their own, assuming that's possible.
> 
> 
> On a single-user system like Windows, you pretty much have to assume the 
> user can do anything.  They can turn off NTP, reset the clock, reboot the 
> system, uninstall your software, whatever.
> 
> If you could check to see that NTP is running, it doesn't prove anything.  
> A malicious and determined user could set up another machine as a NTP 
> server to synch against, and even configure that machine to look like it 
> was a stratum-1 reference (i.e. an atomic clock).
> 
> At some point, you need to decide if you trust the system administrator to 
> supply you with an accurate system clock or not.  If you don't, and it's 
> really important that you have an accurate time reference, you've got an 
> interesting engineering problem on your hands.

A couple of quick thoughts: (1) stupidity is much more prevalent than 
malice in that environment.

(2) Peter, if your app has something else to measure e.g. it is 
processing zillions of rows from a database, grab the [UTC] wall time 
every N things, and apply plausibility checks to the speed N/delta(wall) 
-- if it goes negative or "too high" or "too slow", holler fer a mountie.



More information about the Python-list mailing list