[Sussex] NTP Server....

[Richie Jarvis]

Andy Smith wrote:
> On Wed, Apr 04, 2007 at 09:13:21PM +0100, Richie Jarvis wrote:
>   
>> Hi All,
>>
>> I recently reinstalled my MythTV server on ubuntu 6.10, and have been 
>> having real trouble with times.  What seems to be happening is that the 
>> clock is running ahead by about 30 minutes.  I've setup NTP (first with 
>> the deb pkg defaults, and recently using pool.ntp.org), and made sure 
>> that ntp-server is running.  I have verified that its running, and seems 
>> to be receiving times using ntp -p:
>>
>> root at sam:/var/log/mythtv# ntpq -p
>>     remote           refid      st t when poll reach   delay   offset  
>> jitter
>> ==============================================================================
>> pool.ntp.org    83.170.73.8      3 u    7   64    1   24.319  -1090.6   
>> 0.001
>> LOCAL(0)        73.78.73.84      5 l    6   64    1    0.000    0.000   
>> 0.001
>>
>> This would seem to imply (to my untrained eyes) that its working - yet I 
>> keep having to reset the time, by shutting down the ntp-server, and 
>> running ntpdate pool.ntp.org
>>     
>
> 1090ms is a very big offset.  But you only have one server, so that
> one server could be wrong -- servers in pool.ntp.org are only
> periodically tested to see if they are sane; I once saw one that was
> wrong by ten years!
>
> I suggest using at least:
>
> 0.uk.pool.ntp.org
> 1.uk.pool.ntp.org
> 2.uk.pool.ntp.org
> 3.uk.pool.ntp.org
> 0.pool.ntp.org
> 1.pool.ntp.org
> 2.pool.ntp.org
>
> That way at least one or two bad clocks won't affect you and you can
> focus on your own problems.
>
>   
>> Has anyone else had similar NTP issues, and knows whats going on?
>>     
>
> What is the hardware?  Some of the embedded and low power CPUs have
> very poor clock sources and you need to tell Linux to use a
> different source.
>
> For example until a patch made it into the kernel to use a different
> time source, my soekris router would lose ticks when the CPU was
> sleeping, so the clock went slow by around half an hour a day.
>
> Once the offset gets too big, ntp will give up trying to correct it
> and you end up having to use ntpdate.  Don't be tempted to just cron
> ntpdate; that will skew the clock every so often which can be quite
> bad!
>
> Cheers,
> Andy
>   
Hi Andy,

I was pretty sure it wasn't a dicky ntp server, as I did try several.  
I've confirmed this this morning as well.  But, you did point me down 
what is hopefully the right track!  This system is using an nForce2 
chipset, and it turns out that these chipsets have a 'Spread Spectrum' 
feature which is known to play havoc with ntp and clocks.

So, for others who may come across this issue - the post from Nvidia 
which shows how to identify and solve the issue is here: 
http://www.ussg.iu.edu/hypermail/linux/kernel/0410.1/1505.html

I've disabled FSB Spread Spectrum in the BIOS, and already can see that 
the unreasonable offset is much more healthy! 

root at sam:~# ntpq -p
     remote           refid      st t when poll reach   delay   offset  
jitter
==============================================================================
 tigger.lentil.o 195.66.241.3     2 u   50   64    1   38.515   -4.337   
0.001
 1.uk.pool.ntp.o 129.6.15.29      2 u   49   64    1   25.488   -3.343   
0.001
 2.uk.pool.ntp.o 193.62.22.98     2 u   48   64    1   24.607   -4.526   
0.001
 LOCAL(0)        73.78.73.84      5 l   47   64    1    0.000    0.000   
0.001

Thanks for your help,

Richie