PSN-L Email List Message
Subject: Re: On timing
From: Mike Price mprice@........
Date: Mon, 11 Apr 2005 21:58:18 -0700
The RTC in a typical PC is a joke. However, if you run clock
synchronization SW you can discipline your PC clock to be quite stable
and accurate despite the poor performance of the RTC HW. Generally, the
HW clock is ignored - only the system clock (in the OS) matters and that
is adjusted regularly as its drift with respect to a time standard is
monitored. NTP is quite capable of maintaining accurate local time even
when the routing path to the server is inconsistent since each server
transaction involves multiple exchanges to determine the offset between
the local clock and the server. We manage a large number of remote
computers synchronized through the Internet using ntp and they maintain
clock synchronization to within a few jiffies (jiffy=10mS).
> Dear Dr McCue,
> Thank you for your comment!
> I am not sure if you have appreciated quite how erratic computer
> software clocks can be? Let's say that we have three amateur stations
> which know their Lat and Long co-ordinates, but are each only 50 km
> apart in a roughly straight line in a UK setting. My clock lost 6 sec
> per hour and the central station gained 6 sec per hour when checked
> last week, but the other end one is unknown. We are all using the
> standard Widows clock update of once per week and are at the end of
> the cycle. We all measure a P / S delay times of the order of 10 min,
> but we have only the one vertical sensor with some cross sensitivity.
> Sure we can put in figures for the average travel times for a
> range of depths, but estimating a 'cocked hat position' and working
> back to the time of origin leaves several minutes unexplained.
> How do you suggest that we get an estimate of the time, location
> and depth of the quake and the probable errors, please?
> Chris Chapman
Public Seismic Network Mailing List (PSN-L)
[ Top ]
[ Back ]
[ Home Page ]