[LinuxPPS] ntptime status - relaunch of that issue
Felix Joussein
felix.joussein at gmx.at
Thu Mar 19 17:30:39 CET 2009
Hello Hal,
I have just been spending the last 6 hours, doing some short-term tests
- long-term tests have been running the passt few weeks - with my
machines, and wanted to let you know my status:
I performed the tests using my stable 2.4er based setup and my 2.6er setup.
As Hardware I used an Intel-Atom-, Intel Pentium-M and Intel Pentium 4
system.
The results:
2.4er setup is running stable with offset/jitter +/- 0.010 an all
machines, synchronizing within 10 minutes, stratum status is lowering
down from 16 to 1 as the offset/jitter comes within normal parameters.
On H-T cap. CPU's I had to disable it via bios, else my keyboard was
locked (tried that several times on all H-T architectures - same effect.).
2.6er setup is also running stable, H-T seams not to be an issue, but
the Stratum problem, as well as the eternal long synchronizing time from
about 8 hours (info from my college) makes it unusable for productive
environments.
Further my college has noticed, that environmental change (Temperature)
has a direct impact on the stability.
As you have mentioned, that your setup does meet pretty much what I'm
missing on mine: quick syncing, stratum level only 1 when it's synced
etc...: can you tell me, what hardware, which kernel version eventually
even attach it's .config file, the cat /proc/cmdline , and your ntpd
Version + configure options?
Thank you one more time for helping me!
regards,
Felix
Hal V. Engel schrieb:
> On Thursday 05 March 2009 02:38:35 am Felix Joussein wrote:
>
>> 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?
>>
>
> Add
>
> hpet=force
>
> to your boot command.
>
>
>> 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...
>>
>
> I have added -g (--panicgate) to the list of parms that is used to start ntp.
> On my machine this is set in /etc/conf.d/ntpd but it may be different
> depending on what distro you are using. What this does is forces a one time
> syncing of the system clock to the refclock (IE. a jump in the time) when ntpd
> is started. I believe that by default this does not happen unless the clock
> is off by more than 128 milliseconds. But I could be wrong about this and you
> can adjust this using the -x (--slew) switch.
>
> My clock usually drifts by more than 128 milliseconds during down times (like
> over night). With --panicgate I start out with an offset < 50 microseconds
> (IE. 0.050 max) and things settle down to the 5 to 10 microsecond range in
> perhaps 15 or 20 minutes as the temperature of the machine stabilizes.
>
> In my book an offset of 50 microseconds means that my machine is a true
> stratum 1 machine almost as soon as ntp is running and has reached the
> refclock which takes less than a minute. Also with --panicgate ntp will not
> report having reached the refclock until it has synced with it and made the
> initial larger time adjustment.
>
> One other consideration. If you have more than one server line in your ntp
> configuration and you have --panicgate set then ntp will sync the clock with
> which ever server it first connects with. The concern is that you may want it
> to only sync to the local refclock but it may connect to one of the other
> (less accurate) servers first and use it to make this initial adjustment
> resulting in a larger initial offset than you want.
>
>
>> it starts at about 40.000 /
>> 0.800. The 4-5 hours wouldn't be that much of a problem,
>>
>
> This is what my machine was like before I started using ---panicgate when
> starting ntp.
>
>
>> 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?
>>
>
> I just did a man ntpd and didn't see anything. The only threshold adjustment
> I saw was the slew/jump threshold that can be changed with -x or --slew. But
> this will not do what you are asking about. NTP is intended for time servers
> that are expected to run continuously so the design is not intended to cause a
> quick clock sync. So it does have some issues on machines that are rebooted
> or have down time like a workstation/end user machine. Your best bet is to
> try --panicgate.
>
>
>> 3. Can I accelerate the time adjusting from the pps (offset/jitter) signal?
>>
>
> See above.
>
>
>> 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
>>>
>
>
> _______________________________________________
> 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
>
>
>
More information about the LinuxPPS
mailing list