Return-Path: Received: from rly-dd10.mx.aol.com (rly-dd10.mail.aol.com [172.19.141.157]) by air-dd04.mail.aol.com (v121_r4.4) with ESMTP id MAILINDD042-ba1495a098c1e1; Tue, 30 Dec 2008 06:44:19 -0500 Received: from post.thorcom.com (post.thorcom.com [193.82.116.20]) by rly-dd10.mx.aol.com (v121_r4.4) with ESMTP id MAILRELAYINDD103-ba1495a098c1e1; Tue, 30 Dec 2008 06:44:15 -0500 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1LHd0v-0004gY-Le for rs_out_1@blacksheep.org; Tue, 30 Dec 2008 11:43:57 +0000 Received: from [83.244.159.144] (helo=relay3.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1LHd0v-0004gP-6g for rsgb_lf_group@blacksheep.org; Tue, 30 Dec 2008 11:43:57 +0000 Received: from kiwi.webfusion.co.uk ([212.67.202.195]) by relay3.thorcom.net with esmtp (Exim 4.63) (envelope-from ) id 1LHd0t-0007dN-4F for rsgb_lf_group@blacksheep.org; Tue, 30 Dec 2008 11:43:57 +0000 Received: from host217-34-87-14.in-addr.btopenworld.com ([217.34.87.14] helo=stewart-bryants-computer.local) by kiwi.webfusion.co.uk with esmtpa (Exim 4.54) id 1LHd0s-0000oo-AS; Tue, 30 Dec 2008 11:43:54 +0000 Message-ID: <495A0979.7000704@g3ysx.org.uk> Date: Tue, 30 Dec 2008 11:43:53 +0000 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: rsgb_lf_group@blacksheep.org References: <007101c969dd$7d40fdf0$8cd9160a@EFREMOV> <0FA664D5D2F74FFA80C9460AA01B9C78@Silver> <2AAC194CE68E48069E6980FBC3713C88@JimPC> <5804028F4B3F4EB48348D8C62C8432B4@JimPC> In-Reply-To: <5804028F4B3F4EB48348D8C62C8432B4@JimPC> X-Spam-Score: 0.0 (/) X-Spam-Report: autolearn=disabled,none Subject: Re: LF: Re: WSPR and CW - NTP Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-SA-Exim-Scanned: Yes Sender: owner-rsgb_lf_group@blacksheep.org Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group X-SA-Exim-Rcpt-To: rs_out_1@blacksheep.org X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-AOL-IP: 193.82.116.20 X-Mailer: Unknown (No Version) 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