Chris,
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).

Mike


ChrisAtUpw@....... wrote:

> 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?
>  
>     Regards,
>  
>     Chris Chapman
>     


__________________________________________________________

Public Seismic Network Mailing List (PSN-L)