Message-ID: <495A0979.7000704@g3ysx.org.uk>
Date: Tue, 30 Dec 2008 11:43:53 +0000
From: Stewart Bryant <stewart@g3ysx.org.uk>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: rsgb_lf_group@blacksheep.org
References: <BAY105-W473211C11A1107D1891FB5D3E60@phx.gbl> <007101c969dd$7d40fdf0$8cd9160a@EFREMOV> <0FA664D5D2F74FFA80C9460AA01B9C78@Silver> <2AAC194CE68E48069E6980FBC3713C88@JimPC> <5804028F4B3F4EB48348D8C62C8432B4@JimPC>
In-Reply-To: <5804028F4B3F4EB48348D8C62C8432B4@JimPC>
Subject: Re: LF: Re: WSPR and CW - NTP
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org


James Moritz wrote:
> Dear LF Group,
> 
> There is a similar NTP set-up for Windows Vista - see 
> http://www.howtogeek.com/howto/windows-vista/dealing-with-windows-vista-time-sync-problems/ 
> . I am trying it here at the moment, and it seems to work.
> 
> Cheers, Jim Moritz
> 73 de M0BMU
> 
> 
> 
> 

Some other things to think about WRT NTP. You should be less concerned 
about picking the "best" reference clock on the net than picking
a good clock that has a reliable (i.e. constant delay) path to your
site. So whilst it might be for example tempting to pick the NPL clock, 
a good clock within the network of your service provider may well be better.

It may be very difficult to figure out what sort of hardware they
are using, but if your ISP is providing the clock from their
router hardware, then you need to take a careful look at the
quality - in general they are not as good as you will get from
a specialist time server. That said, expect major improvements
in the next generation as all of the providers gear up to
service the mobile phone industry (which needs very precise
time and frequency to operate).

One of the biggest errors that you get is with the ADSL link to your
house - cable should be better. This is because NTP takes the path delay 
(and hence server to client time offset ) to be half the round trip 
time. The final hop is asymmetric and extremely variable. The new 
generation cable services should be very interesting in this regard, 
since they will quite precise time at the STB to work and one has to 
hope that this will be made available to the user applications.

You might also note that NTP needs to run continuously to get the best 
out of it. There are two reasons for this. The first is that it learns 
drift characteristics of the client oscillator over time and makes 
predictive correction. The second is that it has an algorithm that looks 
for the packets that appear to arrive with lowest delay compared to the 
packets it previously received. These packets are interesting because in 
a packet switching network the packets that have the minimum delay 
represent a stiff timing edge - the lowest delay packets have been 
switched by the routers without queuing and hence give the most 
consistent delay measurement.

Finally I am not sure whether the common O/Ss can support it but
NTP has a way to average the time over a number of servers. I am fairly 
sure you will get this on any O/S based on UNIX since that is the NTP 
development group reference platform.

Cheers

Stewart/G3YSX