Determining actual elapsed (wall-clock) time
John Machin
sjmachin at lexicon.net
Sat Jul 2 20:11:20 EDT 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