[LinuxPPS] ntptime status - relaunch of that issue

Thu Mar 5 11:38:35 CET 2009

Big thank to all of you who have helped to track down the problem!

The best results seam to run on an intel atom (330) with hped clocksource.

Now there is one more little issue:
1. How do I get hped as default timer at boot time?
When booting my machine it's always tsc, which brings worse results.
2. An other issue is the time ntpd needs to come down to an offset of
max 0.010 and an jitter of max 0.003.
On my machine it takes about 4-5 hours... it starts at about 40.000 / 0.800.
The 4-5 hours wouldn't be that much of a problem, fare more the fact,
that ntpd switches to stratum1 eventhought it's not as precise as desired...
So the second question is: can I set a threshold which limits the
stratum1 to a defined offset/jitter level?
3. Can I accelerate the time adjusting from the pps (offset/jitter) signal?

4. More hardware: has anyone of you experience with VIA C7 CPU's and the
clocksource issue?

5. anybody at CeBIT that weekend?
Regards,

Felix

Hal V. Engel schrieb:
> On Tuesday 24 February 2009 02:52:23 am Felix Joussein wrote:
>   
>> Hello Michael,
>>
>> I have checked that the current clock source is tsc and that 3 different
>> are available in total: tsc, acpi_pm and jiffies
>>     
>
> Have you enables HPET in the kernel config?  
>
> Also many motherboards have spread spectrum oscillators with introduces 
> continuous variations into the frequency of the system oscillator.  This is 
> intended to reduce radio frequency interference by spreading the spurious RF 
> over a wider frequency range so that the MB can meet regulatory requirements.  
> But it can cause issues for accurate time keeping.  In some cases the BIOS 
> settings will allow you to turn off this "feature" so it is worth the effort 
> to check to see if you can do this.   
>
>   
>> I have changed them to see what happens:
>>
>> tsc & acpi_pm show no differences...
>> jiffies let's the beeper beep permanently... as soon as the keyboard
>> produces a short beep (for ex. backspace on begin of line)... and after
>> setting jiffies you can't reset it to tsc (the echo tsc > /sys/.....) is
>> useless... not exewcuted, because a cat of the file still shows jiffies.
>>
>> I also have compared the behavior  from my former 2.4 installation
>> mentioned in my posts before, and realized, that the ntpd would not even
>> start.
>> In dmesg I get: many lines "do_clock_gettime: negative time wrap on
>> CPU#0: -60751978ns (0,7646704)" and ntpd produces
>> "adjtimex: ntpd could be using obsolete ADJ_TICKADJ" and then stops
>> itself again.
>>
>> The ppstest equivalent in 2.4 is ppsctl, the output is pretty similar to
>> ppstest, the jitter is bouncing from 640 to -32, -672, 704 per line.
>>
>> when I try to run ntpd -d I get a lot debugging output, and at the end a
>> freezed screen. (So definitely this hardware s***ks, maybe I better turn
>> it into a DVR device!)
>>
>> The current machines, running 2.4 kernel + PPSKit are Pentium III with
>> 512MB Ram...
>>     
>
> The PIII has an invariant TSC counter and that would explain at least part of 
> it's good time keeping performance.
>
>   
>> The Idea to use Pentium M's was to limit power usage.... the industrial
>> PC I'm using now has a Pentium M and 2 GB RAM is using 80W at most...
>> So: how about an Intel ATOM?
>>     
>
> Maybe but there was a long thread about TSC counters on the ntp mailing list 
> back in the time frame after AMD had announced their plan to make future AMD 
> CPUs TSC invariant and there appeared to be skepticism at that time about 
> Intel's offerings in this regard at least in part because the feature was 
> poorly documented.  
>
>   
>> So, what would be the recommended hardware setup?
>>     
>
> Another option might be to use one of the low power amd64 CPUs that was 
> recently released.  I know that one of these is rated at 9 watts (single core, 
> there is also a dual core unit rated at 22 watts) and with a low power 
> consumption MB chip set (AMD makes some of these) you should end up with a 
> system with very low over all power consumption that is in the same ball park 
> as an Atom system (the chip set used on the Atom MB has fairly high power 
> consumption and this is the chip with the big heat sink on it) and you will 
> almost for sure end up with a solidly implemented invariant TSC.   
>
> I should add that it is almost impossible to know how good any hardware setup 
> will work without first testing it.   But if I was building a new system that 
> was intended as a low power consumption time keeping network appliance I would 
> go with one of these low power AMD CPUs if for no other reason than that the 
> TSC features are well documented and were specifically intended for time 
> keeping.
>
>   
>> thank's for helping me!
>>
>> regards,
>>
>> Felix Joussein
>>
>> Michael Meier schrieb:
>>     
>>>> I played around with different hardware and realised, that then faster a
>>>> machine is, then less the offset / jitter is.
>>>> For example on an amd64 X2 5000+ jitter/offset is about 0,100 - 0,010
>>>> +/- while with the Pentium M processor the offset/jitter rises up far
>>>> beyond 1,000...
>>>> I think, the Pentium M (1700MHz) should be way enough for a ntp server?
>>>>         
>>> The CPU Power surely is enough, but you might hit an architectural
>>> problem with the Pentium M: It has a timestamp counter [1] that does
>>> NOT increase monotonically, even when all power saving features are
>>> disabled. Since the TSC is the default and preferred timesource of the
>>> kernel, that will cause some confusion. The kernel will detect that
>>> the TSC is crap after some time, and switch to another source after
>>> some time if it has some available, but the TSC really is the best you
>>> can get. The only thing that comes close to it is HPET (High Precision
>>> Event Timer), and that is not available everywhere. And naturally, if
>>> ntpd cannot get the local time from the kernel with a sufficiently
>>> high resolution, things will start to jitter.
>>> You should check what your kernel currently uses as timesource (cat
>>> /sys/devices/system/clocksource/clocksource0/current_clocksource), and
>>> what sources it has available
>>> (/sys/devices/system/clocksource/clocksource0/current_clocksource).
>>> You can also check in the kernel logs, the kernel usually tells you
>>> when it changes the timesource and why.
>>>
>>> [1] http://en.wikipedia.org/wiki/Time_Stamp_Counter
>>>       
>> _______________________________________________
>> LinuxPPS mailing list
>> LinuxPPS at ml.enneenne.com
>> http://ml.enneenne.com/cgi-bin/mailman/listinfo/linuxpps
>> Wiki: http://wiki.enneenne.com/index.php/LinuxPPS_support
>>     
>
>
> _______________________________________________
> LinuxPPS mailing list
> LinuxPPS at ml.enneenne.com
> http://ml.enneenne.com/cgi-bin/mailman/listinfo/linuxpps
> Wiki: http://wiki.enneenne.com/index.php/LinuxPPS_support
>
>
>   