[LinuxPPS] ntptime status - relaunch of that issue
Hal V. Engel
hvengel at astound.net
Tue Feb 24 20:44:08 CET 2009
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
More information about the LinuxPPS
mailing list