Hello,

Can anyone tell me if a time shift greater than 2s per day is ""normal"" 
on a linux system that has no "external" synchronisation (ntp)?

I tryied "adjtimex -a" which gives unreliable results: it worked fine on 
   one machine (less than 1s shift / day) and badly on another one 
(several seconds shift / day)

Any info about this subject would help me.

Regards
Thierry MARTIN

Thierry,

Thierry MARTIN wrote:
> Hello,
> 
> Can anyone tell me if a time shift greater than 2s per day is ""normal""
> on a linux system that has no "external" synchronisation (ntp)?
> 
> I tryied "adjtimex -a" which gives unreliable results: it worked fine on
>    one machine (less than 1s shift / day) and badly on another one
> (several seconds shift / day)
> 
> Any info about this subject would help me.

Which kernel version are you running? Starting with ~2.6.22 a new clock
model has made its way into the Linux kernel. There are different modules
which can use different hardware timers for timekeeping, and there seem to
be some problems with certain modules on certain hardware (i.e. chipsets on
the motherboard).

To list available clock sources under kernel ~2.6.22 or newer:

# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
hpet acpi_pm pit jiffies tsc

Check which clocksource is currently being used:

# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

Change the clock source:

# echo tsc > \
/sys/devices/system/clocksource/clocksource0/current_clocksource

For a test it is also possible to override the default clock source using a
boot parameter, e.g.:

clocksource=jiffies

You may want to try if some other of the available modules does a better job
in timekeeping. If the active module doesn't work correctly then the
frequency drift often exceeds the maximum drift ntpd can handle.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Thierry MARTIN <thierry-martin@ifrance.com> wrote:
> Hello,
> 
> Can anyone tell me if a time shift greater than 2s per day is ""normal"" 
> on a linux system that has no "external" synchronisation (ntp)?

I would say 2s/day is in the upper  class  for  PCs,
and it probably  exceeds  10s/day  in  the  average.

Other architectures/manufacturers most likely do
better.

-- 
Fran�ois Meyer

Thanks Fran�ois. That is what I experience.

Fran�ois Meyer a �crit :
> Thierry MARTIN <thierry-martin@ifrance.com> wrote:
>> Hello,
>>
>> Can anyone tell me if a time shift greater than 2s per day is ""normal"" 
>> on a linux system that has no "external" synchronisation (ntp)?
> 
> I would say 2s/day is in the upper  class  for  PCs,
> and it probably  exceeds  10s/day  in  the  average.
> 
> Other architectures/manufacturers most likely do
> better.
> 

Hello again Thierry,

 On Tuesday, February 12, 2008 at 10:58:32 +0100, Thierry MARTIN wrote:

> Can anyone tell me if a time shift greater than 2s per day is
> ""normal"" on a linux system that has no "external" synchronisation
> (ntp)?

Absolutely normal: that's only 23 PPM, nothing. I have seen machines
that do better, and some that do much worse. As long as it's stable,
2 secs/day every day, and below 500 PPM, it's zeroifiable via the kernel
clock frequency setting. Even above 500 PPM, with help from --tick.


> I tryied "adjtimex -a" which gives unreliable results

This --adjust thing is quite reliable, easely to the single PPM (less
than 0.1 secs/day), provided you already carefully calibrated its
reference: The RTC, via hwclock and /etc/adjtime.

There are plenty of other methods to get an accurate kernel clock
frequency. I'll propose one: run ntpd on the machine during some hours
or a day, with a good connection to (a) good server(s). Then the
following days restore the wanted kernel frequency via:

| # ntptime -f $(cat /var/lib/ntp/ntp.drift) > /dev/null

Or via:

| # adjtimex --frequency $(awk '{printf "%.0f", $1 * 65536; exit}' /var/lib/ntp/ntp.drift)


Cordialement, Serge.
-- 
Serge point Bets arobase laposte point net

Thierry MARTIN <thierry-martin@ifrance.com> writes:

>Hello,

>Can anyone tell me if a time shift greater than 2s per day is ""normal"" 
>on a linux system that has no "external" synchronisation (ntp)?

Sure. In fact that is small. 2s/day is 20PPM , and I have machines which
have a 80PPM drift. Also some with a 6PPM drift. So 2s/d is certainly
within the range.


>I tryied "adjtimex -a" which gives unreliable results: it worked fine on 
>   one machine (less than 1s shift / day) and badly on another one 
>(several seconds shift / day)

>Any info about this subject would help me.

Use ntp to synchronize externally.

With no external sync, ntp and your computer has no way of knowing what the
"right" time is. And depending on the use your computer gets, fluctuations in
the drift of seconds per day are certainly possible (unusual but possible) from Temp variations
within the machine. 

Any place where these different clock models is described?
And defined (what is tsc?)

Martin Burnicki <martin.burnicki@meinberg.de> writes:

>Thierry,

>Thierry MARTIN wrote:
>> Hello,
>> 
>> Can anyone tell me if a time shift greater than 2s per day is ""normal""
>> on a linux system that has no "external" synchronisation (ntp)?
>> 
>> I tryied "adjtimex -a" which gives unreliable results: it worked fine on
>>    one machine (less than 1s shift / day) and badly on another one
>> (several seconds shift / day)
>> 
>> Any info about this subject would help me.

>Which kernel version are you running? Starting with ~2.6.22 a new clock
>model has made its way into the Linux kernel. There are different modules
>which can use different hardware timers for timekeeping, and there seem to
>be some problems with certain modules on certain hardware (i.e. chipsets on
>the motherboard).

>To list available clock sources under kernel ~2.6.22 or newer:

># cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>hpet acpi_pm pit jiffies tsc

>Check which clocksource is currently being used:

># cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>tsc

>Change the clock source:

># echo tsc > \
>/sys/devices/system/clocksource/clocksource0/current_clocksource

>For a test it is also possible to override the default clock source using a
>boot parameter, e.g.:

>clocksource=jiffies

>You may want to try if some other of the available modules does a better job
>in timekeeping. If the active module doesn't work correctly then the
>frequency drift often exceeds the maximum drift ntpd can handle.


>Martin
>-- 
>Martin Burnicki

>Meinberg Funkuhren
>Bad Pyrmont
>Germany

Unruh wrote:
> Any place where these different clock models is described?
> And defined (what is tsc?)
> 
tsc refers to the counter in recent Intel Architecture chips that counts 
the processor clock cycles.  It is somewhat vulnerable to power management.

Unruh wrote:
> Any place where these different clock models is described?

Hm, I think "clock models" in the sense of NTP is not correct in this
context. AFAIK there is only one "clock model" in the Linux kernel which
uses one of those "clocksource" modules as its base for timekeeping,
similar to the way ntpd uses a refclock as time source.

Each of the clocksource modules deals with a dedicated timer or counter
which may or may not be available on a specific hardware architecture, i.e.
the x86_64 hardware may provide different timers in its chipset than the
i386 architecture.

> And defined (what is tsc?)

The only place I've found to get an overview is the file
Documentation/kernel-parameters.txt which is part of the Linux kernel
sources. This also lists which clocksource modules may be available for
which hardware architecture.

Here's the relevant part from a 2.6.22 kernel:

  clocksource=  [GENERIC_TIME] Override the default clocksource
      Format: <string>
      Override the default clocksource and use the clocksource
      with the name specified.
      Some clocksource names to choose from, depending on
      the platform:
      [all] jiffies (this is the base, fallback clocksource)
      [ACPI] acpi_pm
      [ARM] imx_timer1,OSTS,netx_timer,mpu_timer2,
        pxa_timer,timer3,32k_counter,timer0_1
      [AVR32] avr32
      [IA-32] pit,hpet,tsc,vmi-timer;
        scx200_hrt on Geode; cyclone on IBM x440
      [MIPS] MIPS
      [PARISC] cr16
      [S390] tod
      [SH] SuperH
      [SPARC64] tick
      [X86-64] hpet,tsc


As already mentioned by David Woolley the TSC counter is a register inside
Pentium CPUs or higher. The tick rate corresponds to the CPU clock, so if
the CPU clock changes due to power saving efforts this has to be taken into
account when measuring time intervals.

The acpi_pm module uses the ACPI Power Management timer which is available
on every PC which supports ACPI services. 

The hpet module uses the High Precision Event Timers indroduced by recent
Intel chip sets. AFAIK it's a replacement for the old Periodic Interrupt
Timer from the original IBM PC architecture which used to generate periodic
interrupts at 18.2 Hz under DOS.

I don't know the exact details or advantages/disadvantages of those timers.
However, from several postings here in the NG and elsewhere I've seen that
certain modules may not work properly on certain chipsets. This must not
necessarily be due to the modules, AFAIK there are also chipsets out there
where the timers don't work properly and would require specific
workarounds.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Hi all,

Just a few word to keep you informed...

I have been trying acpi_pm clocksource for a few days now and the 
results are quite good :-).

The time drift is less than 1s per day (I would even say less that 500ms 
but this has to be confirmed) which is much better than the default 
config with tsc (>2s /day).

Honestly, I am a bit surprised / worried about these results: I would 
expect that people doing distribution would have the best clocksource 
detected / configured automatically.
Might be because my FC5 base is too old, or ... I Hope I won't find side 
effects...

Have a nice day!
Thierry MARTIN


Martin Burnicki a �crit :
> Unruh wrote:
>> Any place where these different clock models is described?
> 
> Hm, I think "clock models" in the sense of NTP is not correct in this
> context. AFAIK there is only one "clock model" in the Linux kernel which
> uses one of those "clocksource" modules as its base for timekeeping,
> similar to the way ntpd uses a refclock as time source.
> 
> Each of the clocksource modules deals with a dedicated timer or counter
> which may or may not be available on a specific hardware architecture, i.e.
> the x86_64 hardware may provide different timers in its chipset than the
> i386 architecture.
> 
>> And defined (what is tsc?)
> 
> The only place I've found to get an overview is the file
> Documentation/kernel-parameters.txt which is part of the Linux kernel
> sources. This also lists which clocksource modules may be available for
> which hardware architecture.
> 
> Here's the relevant part from a 2.6.22 kernel:
> 
>   clocksource=  [GENERIC_TIME] Override the default clocksource
>       Format: <string>
>       Override the default clocksource and use the clocksource
>       with the name specified.
>       Some clocksource names to choose from, depending on
>       the platform:
>       [all] jiffies (this is the base, fallback clocksource)
>       [ACPI] acpi_pm
>       [ARM] imx_timer1,OSTS,netx_timer,mpu_timer2,
>         pxa_timer,timer3,32k_counter,timer0_1
>       [AVR32] avr32
>       [IA-32] pit,hpet,tsc,vmi-timer;
>         scx200_hrt on Geode; cyclone on IBM x440
>       [MIPS] MIPS
>       [PARISC] cr16
>       [S390] tod
>       [SH] SuperH
>       [SPARC64] tick
>       [X86-64] hpet,tsc
> 
> 
> As already mentioned by David Woolley the TSC counter is a register inside
> Pentium CPUs or higher. The tick rate corresponds to the CPU clock, so if
> the CPU clock changes due to power saving efforts this has to be taken into
> account when measuring time intervals.
> 
> The acpi_pm module uses the ACPI Power Management timer which is available
> on every PC which supports ACPI services. 
> 
> The hpet module uses the High Precision Event Timers indroduced by recent
> Intel chip sets. AFAIK it's a replacement for the old Periodic Interrupt
> Timer from the original IBM PC architecture which used to generate periodic
> interrupts at 18.2 Hz under DOS.
> 
> I don't know the exact details or advantages/disadvantages of those timers.
> However, from several postings here in the NG and elsewhere I've seen that
> certain modules may not work properly on certain chipsets. This must not
> necessarily be due to the modules, AFAIK there are also chipsets out there
> where the timers don't work properly and would require specific
> workarounds.
> 
> 
> Martin

Thierry MARTIN wrote:

> I have been trying acpi_pm clocksource for a few days now and the 
> results are quite good :-).
> 
> The time drift is less than 1s per day (I would even say less that 500ms 
> but this has to be confirmed) which is much better than the default 
> config with tsc (>2s /day).

It's almost certain that the same hardware time source is used for both, 
so discrepancies are likely to be attributable to software issues 
(although those may include problems in calibrating the frequency of 
various sources empirically, rather than by knowing how they derive from 
the common source).

Oups?

If I understand your post, tsc is the same as acpi_pm ?

Was I just a lucky guy with this config?

(:- You've just killed my enthousiasm ... :-)



David Woolley a �crit :
> Thierry MARTIN wrote:
> 
>> I have been trying acpi_pm clocksource for a few days now and the 
>> results are quite good :-).
>>
>> The time drift is less than 1s per day (I would even say less that 
>> 500ms but this has to be confirmed) which is much better than the 
>> default config with tsc (>2s /day).
> 
> It's almost certain that the same hardware time source is used for both, 
> so discrepancies are likely to be attributable to software issues 
> (although those may include problems in calibrating the frequency of 
> various sources empirically, rather than by knowing how they derive from 
> the common source).

David,

David Woolley wrote:
> Thierry MARTIN wrote:
> 
>> I have been trying acpi_pm clocksource for a few days now and the
>> results are quite good :-).
>> 
>> The time drift is less than 1s per day (I would even say less that 500ms
>> but this has to be confirmed) which is much better than the default
>> config with tsc (>2s /day).
> 
> It's almost certain that the same hardware time source is used for both,
> so discrepancies are likely to be attributable to software issues
> (although those may include problems in calibrating the frequency of
> various sources empirically, rather than by knowing how they derive from
> the common source).

If you mean the same base oscillator on the motherboard then this may be the
case. 

However, a bunch of clock signals with different clock rates are derived
from those oscillators, and the fact that different clocksource modules
yield different results make me assume that the problems are not with the
base oscillator but with the different types of counters and/or the
implementations of the modudules which use thos specific counters.

See also 
http://bugzilla.kernel.org/show_bug.cgi?id=7963

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

On Feb 12, 4:40 pm, David Woolley
<da...@ex.djwhome.demon.co.uk.invalid> wrote:
>
> tsc refers to the counter in recent Intel Architecture chips that counts
> the processor clock cycles.  It is somewhat vulnerable to power management.

Not only PM, but also differences between processor cores.  Some
models of multi-core processors from AMD or Intel provide one TSC per
core, which may cause discrepancies when the TSC is read on one core
at a time tick and on another core at the next time tick.  This is
also true for multi-processor systems: TSCs are not guaranteed to be
correlated among processors, not even their relative monotonicity.

The Linux kernel goes through hoops to account for such discrepancies
among the several TSC instances, but it's never 100% successful
neither 100% accurate.

Using the TSC as a time reference is tempting because reading it takes
just a few CPU cycles to read it.  Other time references, such as ACPI-
PM and HPET, take much longer to read, even 1000X longer, though they
provide consistent reads and accuracy no matter from which processor
or core.

The speed to get the time-of-day from the kernel may be important when
running some applications, such as data-base servers, when every
transaction is time-tagged and the time it takes to get the time-of-
day can contribute significantly to its performance.

Therefore, for time-keeping purposes, it's better to avoid the kernel
from using the TSC as its time-reference, in favor of other timers
available in the system, unless running an application whose
performance may be gated by getting the time-of-day.

HTH

Thierry MARTIN wrote:
> Oups?
> 
> If I understand your post, tsc is the same as acpi_pm ?

No.  TSC, acpi_pm, the CTC based software clock that PCs have always 
had, etc., are all fed from the same crystal, but run at different 
multiples of that crystal's frequency.  Only the battery backed clock 
normally runs from a different crystal.

Software can get the readings wrong by missing ticks, or in the case of 
the TSC counter, at least, by trying to work out the processor clock 
speed, rather than being told it; typically they time the TSC clock 
against the CTC one, during startup, and use that to calculate effective 
CPU clock frequency.

The CPU clock frequency is slowed down by power management, so the TSC 
rate can vary.

Hi All,

Sorry for beeing too enthousiastic about my initial test...

I launched another test with clocksource=acpi_pm, on the same machine.
The results are bad now (> 500ms in a few hours).

FYI, the command I launched:
# rm /etc/adjtime;
# ntpdate ntp.cines.fr;
# hwclock --systohc;
# adjtimex -a

Then I watch:
# ntpdate -q ntp.cines.fr

Keeping a linux system with the correct time without any external 
synchronisation really seems hard...

Best regards
Thierry.





Thierry MARTIN a �crit :
> Oups?
> 
> If I understand your post, tsc is the same as acpi_pm ?
> 
> Was I just a lucky guy with this config?
> 
> (:- You've just killed my enthousiasm ... :-)
> 
> 
> 
> David Woolley a �crit :
>> Thierry MARTIN wrote:
>>
>>> I have been trying acpi_pm clocksource for a few days now and the 
>>> results are quite good :-).
>>>
>>> The time drift is less than 1s per day (I would even say less that 
>>> 500ms but this has to be confirmed) which is much better than the 
>>> default config with tsc (>2s /day).
>>
>> It's almost certain that the same hardware time source is used for 
>> both, so discrepancies are likely to be attributable to software 
>> issues (although those may include problems in calibrating the 
>> frequency of various sources empirically, rather than by knowing how 
>> they derive from the common source).

Hi Serge,

My investigations might lead me to choose your solution ;-).

The system I have is a (trans)portable machine. I wonder wether these 
parameters will be ok, wherever I place it (what is the influnce of 
temperature differences or things like that)?

Regards
Thierry MARTIN


Serge Bets a �crit :
> Hello again Thierry,
> 
>  On Tuesday, February 12, 2008 at 10:58:32 +0100, Thierry MARTIN wrote:
> 
>> Can anyone tell me if a time shift greater than 2s per day is
>> ""normal"" on a linux system that has no "external" synchronisation
>> (ntp)?
> 
> Absolutely normal: that's only 23 PPM, nothing. I have seen machines
> that do better, and some that do much worse. As long as it's stable,
> 2 secs/day every day, and below 500 PPM, it's zeroifiable via the kernel
> clock frequency setting. Even above 500 PPM, with help from --tick.
> 
> 
>> I tryied "adjtimex -a" which gives unreliable results
> 
> This --adjust thing is quite reliable, easely to the single PPM (less
> than 0.1 secs/day), provided you already carefully calibrated its
> reference: The RTC, via hwclock and /etc/adjtime.
> 
> There are plenty of other methods to get an accurate kernel clock
> frequency. I'll propose one: run ntpd on the machine during some hours
> or a day, with a good connection to (a) good server(s). Then the
> following days restore the wanted kernel frequency via:
> 
> | # ntptime -f $(cat /var/lib/ntp/ntp.drift) > /dev/null
> 
> Or via:
> 
> | # adjtimex --frequency $(awk '{printf "%.0f", $1 * 65536; exit}' /var/lib/ntp/ntp.drift)
> 
> 
> Cordialement, Serge.

Thierry MARTIN <thierry-martin@ifrance.com> writes:

>Hi All,

>Sorry for beeing too enthousiastic about my initial test...

>I launched another test with clocksource=acpi_pm, on the same machine.
>The results are bad now (> 500ms in a few hours).

>FYI, the command I launched:
># rm /etc/adjtime;
># ntpdate ntp.cines.fr;
># hwclock --systohc;
># adjtimex -a

>Then I watch:
># ntpdate -q ntp.cines.fr

>Keeping a linux system with the correct time without any external 
>synchronisation really seems hard...

Yes. YOu expected something else?
If you use chrony, you can enter in the time by hand now and then again in
8 hours. chrony will use that data to estimate the drift of the oscillator
and use that drift info to try to keep the clock on better time. You CANNOT
expect a PC oscillator to keep good time without drift compensation. They
were never designed for that. Note that 1 sec in 10 hours is a drift rate
of only 30PPM. which is well within the error budget of most crystals. With
hand setting you can probably reduce that by a factor of 10 but not much
better due to temp variations, etc.



>Best regards
>Thierry.





>Thierry MARTIN a �crit :
>> Oups?
>> 
>> If I understand your post, tsc is the same as acpi_pm ?
>> 
>> Was I just a lucky guy with this config?
>> 
>> (:- You've just killed my enthousiasm ... :-)
>> 
>> 
>> 
>> David Woolley a �crit :
>>> Thierry MARTIN wrote:
>>>
>>>> I have been trying acpi_pm clocksource for a few days now and the 
>>>> results are quite good :-).
>>>>
>>>> The time drift is less than 1s per day (I would even say less that 
>>>> 500ms but this has to be confirmed) which is much better than the 
>>>> default config with tsc (>2s /day).
>>>
>>> It's almost certain that the same hardware time source is used for 
>>> both, so discrepancies are likely to be attributable to software 
>>> issues (although those may include problems in calibrating the 
>>> frequency of various sources empirically, rather than by knowing how 
>>> they derive from the common source).

Hello Thierry,

 On Tuesday, February 19, 2008 at 16:43:10 +0100, Thierry MARTIN wrote:

> # rm /etc/adjtime;
> # ntpdate ntp.cines.fr;
> # hwclock --systohc;

This procedure sets the RTC once, but does not evaluate its drift. While
adjtimex --adjust needs to know the runtime drift rate of the RTC. So
this should be:

| # ntpdate -b ntp.cines.fr
| # hwclock --systohc
|	wait some hours (minimum 1 to 24 hours depending on hwclock
|	version) while the machine continues to run its usual tasks
| # ntpdate -b ntp.cines.fr
| # hwclock --systohc

This last command sets the RTC again *and* writes into /etc/adjtime
the needed drift correction factor in seconds per day. Now only can
adjtimex --adjust work correctly. Works, but is still not the best
method to set the kernel freq, if you don't mind me to repeat. And after
all that is finished, don't forget to set /etc/adjtime to a sane
power-off RTC drift rate (see my next article).

Note that the nude ntpdate without option does not set the system clock
immediatly nor correctly. For this procedure -b (force step) is
required. Or something better.


> Keeping a linux system with the correct time without any external
> synchronisation really seems hard...

That's very doable, but requires some amounts of efforts. ;-)
In comparision, setting up a DCF77 or GPS refclock for the ntpd daemon
is not so deadly complicated.


Cordialement, Serge.
-- 
Serge point Bets arobase laposte point net

 On Tuesday, February 19, 2008 at 17:45:59 +0100, Thierry MARTIN wrote:

> The system I have is a (trans)portable machine. I wonder wether these
> parameters will be ok, wherever I place it (what is the influnce of
> temperature differences or things like that)?

Of course the temperature influences the drift of the clocks. When you
run ntpd continuously and graph the kernel frequency, you clearly see
night and day cycles, seasonal cycles, "accidents" like the heater
stopped during 2 hours, periods where the computer is iddle or does
heavy work, and days where the sun shines. Ntpd compensates those
variations continuously, correcting the frequency to stay in phase with
The Real UTC Thing.

The frequency difference between a winter night and a summer day depends
on the machine and various conditions, but I seem to typically see
around 2 PPMs. When ntpd is not there to compensate in real time, your
goal is to calculate a mean frequency, that will suit your own usage of
the machine. On a 24/7 server, pick the mean over 24 hours. On a
workstation, pick mean of work hours. And so on.


The temperature influences also the RTC drift rate. And there is there
a major additional source of temperature variation: is the machine on,
or off? One also has to calculate a mean drift, but more to suit the
*non-usage* of the machine. Let me explain:

An accurate RTC is important at one occasion: The boot sequence, when
hwclock --hctosys reads the RTC, applies the drift correction, and
initialises the system clock. The RTC has then drifted since the last
time hwclock --systohc had set it. Typically, this happend during the
previous shutdown. In those conditions, to have a good correction factor
to apply at boot, one should evaluate the drift during power-off time.
This could be schematically:

|	at the end of the day:
| # ntpdate -b ntp.cines.fr
| # hwclock --systohc --nodrift
| # shutdown -h now
|	wait next morning, then restart the machine, and soon after:
| # ntpdate -b ntp.cines.fr
| # hwclock --systohc

This is important, as bad procedures evaluating the RTC drift wrongly
during runtime are a major source of error, maybe a dozen PPMs, one
entire second/day, resulting in several hundreds of milliseconds offset
on the next morning.

Note that the default setup of many Linux distributions doesn't do that
well. They evaluate the RTC drift from shutdown to shutdown, over mixed
periods of half runtime and half poweroff. I fear the difference to be
so big that such a compromise can suit nearly noone.

I wonder how Chrony behaves with the RTC?


Cordialement, Serge.
-- 
Serge point Bets arobase laposte point net

On Feb 19, 10:45=A0am, Thierry MARTIN <thierry-mar...@ifrance.com>
wrote:
> The system I have is a (trans)portable machine. I wonder wether these
> parameters will be ok, wherever I place it (what is the influnce of
> temperature differences or things like that)?
>

In my experience, laptops, especially the newer "ultra-thin" models,
experience wide temparature swings, even when going from high CPU load
to idle. Therefore environmental factors will likely make any "fixed"
frequency correction you might make pretty useless.

If you need good time, you pretty much have to use the reference ntpd
(or another full ntp daemon) on a machine that experiences high
temperature variations.

Of course, ntpd requires an external reference. Unfortunately, most
ntpd versions out there in the wild do not handle the changing network
connectivity that laptops typically experience very well. They expect
the network to be available on ntpd startup, and not change much
thereafter. A typical suggestion to wrok around this is to setup a
script or something to restart ntpd when your network connectivity
changes. How this is done varies from OS to OS, and even from
distribution to distribution on say Linux.

Improvements are being made to the most recent development versions of
ntpd in this area (re-doing DNS lookups periodically for example). I'm
not sure of the state of those changes, last I checked a few months
ago they were still in the latter stages of design.

Hello Serge,

You're right! I missed the -b option in ntpdate.

 > That's very doable, but requires some amounts of efforts. ;-)
I understand that.

The system is a "transportable" system. It is used to mesure some 
transmission time over a network (packets contain utc timestamp 
themselves). It can be moved to different sites in the network.

I would like to avoid the user of the system to wait for "one day" 
before he gets realiable results. The system is a "blackbox", which is 
suppose to work "out of the box".

Also, in this context, "setting up a DCF77 or GPS refclock" is not 
always possible (we actually do support NTP + GPS refclock).

Maybe I should look for a pci board that is able to keep good time - 
even with offset but limited drift- with no external time source...
If anyone has ever heard of this...

Thanks for your answers Serge,

Regards,
Thierry MARTIN



Serge Bets a �crit :
> Hello Thierry,
> 
>  On Tuesday, February 19, 2008 at 16:43:10 +0100, Thierry MARTIN wrote:
> 
>> # rm /etc/adjtime;
>> # ntpdate ntp.cines.fr;
>> # hwclock --systohc;
> 
> This procedure sets the RTC once, but does not evaluate its drift. While
> adjtimex --adjust needs to know the runtime drift rate of the RTC. So
> this should be:
> 
> | # ntpdate -b ntp.cines.fr
> | # hwclock --systohc
> |	wait some hours (minimum 1 to 24 hours depending on hwclock
> |	version) while the machine continues to run its usual tasks
> | # ntpdate -b ntp.cines.fr
> | # hwclock --systohc
> 
> This last command sets the RTC again *and* writes into /etc/adjtime
> the needed drift correction factor in seconds per day. Now only can
> adjtimex --adjust work correctly. Works, but is still not the best
> method to set the kernel freq, if you don't mind me to repeat. And after
> all that is finished, don't forget to set /etc/adjtime to a sane
> power-off RTC drift rate (see my next article).
> 
> Note that the nude ntpdate without option does not set the system clock
> immediatly nor correctly. For this procedure -b (force step) is
> required. Or something better.
> 
> 
>> Keeping a linux system with the correct time without any external
>> synchronisation really seems hard...
> 
> That's very doable, but requires some amounts of efforts. ;-)
> In comparision, setting up a DCF77 or GPS refclock for the ntpd daemon
> is not so deadly complicated.
> 
> 
> Cordialement, Serge.

Hi Thierry,

Thierry MARTIN wrote:
> Maybe I should look for a pci board that is able to keep good time -
> even with offset but limited drift- with no external time source...
> If anyone has ever heard of this...

http://www.meinberg.de/english/products/gps170pci.htm
http://www.meinberg.de/english/products/tcr167pci.htm

OK, I'm biased ;-) ...

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Thierry MARTIN wrote:
> Hello Serge,
> 
> You're right! I missed the -b option in ntpdate.
> 
>  > That's very doable, but requires some amounts of efforts. ;-)
> I understand that.
> 
> The system is a "transportable" system. It is used to mesure some 
> transmission time over a network (packets contain utc timestamp 
> themselves). It can be moved to different sites in the network.
> 
<snip>
> 
> Maybe I should look for a pci board that is able to keep good time - 
> even with offset but limited drift- with no external time source...
> If anyone has ever heard of this...

<snip>

Both Meinburg Funkuhren and Symmetricomm offer PCI cards with "super 
clocks".  An Oven Controlled Crystal Oscillator (OCXO) is available on 
these cards for a premium price.  The oscillator can, I believe, be GPS 
disciplined on either card.

Be prepared for "sticker shock"!   These cards cost around $1200 US the 
last time I looked and they may cost more now.  I have occasionally seen 
them for less on e-Bay but that's not something you can count on finding 
when you want it.

Hi Martin,

It seems that once again, you're about to save me ;-) !
So, ok my system has a Meinberg gps170pci board.

As far as I can remember, when GPS signal is not there, NTP does not use 
GPS refclock as a timesource.

So i guess, you suggest that I use the DCF77 emulation or some other 
feature from the board?
Could you please enlight me about this?

Thanks!
Thierry MARTIN



Martin Burnicki a �crit :
> Hi Thierry,
> 
> Thierry MARTIN wrote:
>> Maybe I should look for a pci board that is able to keep good time -
>> even with offset but limited drift- with no external time source...
>> If anyone has ever heard of this...
> 
> http://www.meinberg.de/english/products/gps170pci.htm
> http://www.meinberg.de/english/products/tcr167pci.htm
> 
> OK, I'm biased ;-) ...
> 
> Martin

Thierry,

Thierry MARTIN wrote:
> Hi Martin,
> 
> It seems that once again, you're about to save me ;-) !

;-))

> So, ok my system has a Meinberg gps170pci board.
> 
> As far as I can remember, when GPS signal is not there, NTP does not use
> GPS refclock as a timesource.

By default not. This is because ntpd sees the board's "not synchronized"
status.
 
> So i guess, you suggest that I use the DCF77 emulation or some other
> feature from the board?
> Could you please enlight me about this?

It's much easier. You run Linux, don't you?

The kernel module which lets ntpd use the card as reference time source can
be loaded with a parameter which overrides the real board status and always
tells ntpd the card is synchronized. Just load the module with the
following parameter:

modprobe mbgclock pretend_sync=1

Of course this parameter should only be used for testing.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

I will try this.


Martin Burnicki a �crit :
> Thierry,
> 
> Thierry MARTIN wrote:
>> Hi Martin,
>>
>> It seems that once again, you're about to save me ;-) !
> 
> ;-))
> 
>> So, ok my system has a Meinberg gps170pci board.
>>
>> As far as I can remember, when GPS signal is not there, NTP does not use
>> GPS refclock as a timesource.
> 
> By default not. This is because ntpd sees the board's "not synchronized"
> status.
>  
>> So i guess, you suggest that I use the DCF77 emulation or some other
>> feature from the board?
>> Could you please enlight me about this?
> 
> It's much easier. You run Linux, don't you?
> 
> The kernel module which lets ntpd use the card as reference time source can
> be loaded with a parameter which overrides the real board status and always
> tells ntpd the card is synchronized. Just load the module with the
> following parameter:
> 
> modprobe mbgclock pretend_sync=1
> 
> Of course this parameter should only be used for testing.
> 
> Martin

Ryan Malayter wrote:
> On Feb 19, 10:45 am, Thierry MARTIN <thierry-mar...@ifrance.com>
> wrote:
>> The system I have is a (trans)portable machine. I wonder wether these
>> parameters will be ok, wherever I place it (what is the influnce of
>> temperature differences or things like that)?
>>
> 
> In my experience, laptops, especially the newer "ultra-thin" models,
> experience wide temparature swings, even when going from high CPU load
> to idle. Therefore environmental factors will likely make any "fixed"
> frequency correction you might make pretty useless.
> 
> If you need good time, you pretty much have to use the reference ntpd
> (or another full ntp daemon) on a machine that experiences high
> temperature variations.
> 
> Of course, ntpd requires an external reference. Unfortunately, most
> ntpd versions out there in the wild do not handle the changing network
> connectivity that laptops typically experience very well. They expect
> the network to be available on ntpd startup, and not change much
> thereafter. A typical suggestion to wrok around this is to setup a
> script or something to restart ntpd when your network connectivity
> changes. How this is done varies from OS to OS, and even from
> distribution to distribution on say Linux.
> 
> Improvements are being made to the most recent development versions of
> ntpd in this area (re-doing DNS lookups periodically for example). I'm
> not sure of the state of those changes, last I checked a few months
> ago they were still in the latter stages of design.

No need to look. I haven't had the bandwidth to get much done in the 
last few months. Needless to say it will be much easier to implement on 
Windows than on Unix machines as Windows uses threads so there's no 
issue with the transfer of information between processes.

Danny

On Sat, 23 Feb 2008 23:38:09 GMT, Danny Mayer wrote:
>
> No need to look. I haven't had the bandwidth to get much done in the 
> last few months. Needless to say it will be much easier to implement on 
> Windows than on Unix machines as Windows uses threads so there's no 
> issue with the transfer of information between processes.

Why are threads not used on UNIX?
/hjj

Hans J�rgen Jakobsen wrote:
> On Sat, 23 Feb 2008 23:38:09 GMT, Danny Mayer wrote:
> 
>>No need to look. I haven't had the bandwidth to get much done in the 
>>last few months. Needless to say it will be much easier to implement on 
>>Windows than on Unix machines as Windows uses threads so there's no 
>>issue with the transfer of information between processes.
> 
> 
> Why are threads not used on UNIX?
> /hjj

I've never used them but I believe that Solaris supports threads.

In article <47C19D56.9010305@comcast.net>,
 "Richard B. Gilbert" <rgilbert88@comcast.net> wrote:

> Hans J�rgen Jakobsen wrote:
> > On Sat, 23 Feb 2008 23:38:09 GMT, Danny Mayer wrote:
> > 
> >>No need to look. I haven't had the bandwidth to get much done in the 
> >>last few months. Needless to say it will be much easier to implement on 
> >>Windows than on Unix machines as Windows uses threads so there's no 
> >>issue with the transfer of information between processes.
> > 
> > 
> > Why are threads not used on UNIX?
> > /hjj
> 
> I've never used them but I believe that Solaris supports threads.

True.  IRIX (SGI) and AIX (IBM) also support threaded applications.

The Solaris kernel is also itself threaded.  I think this is true of 
IRIX and AIX.  The HP-UX kernel is not threaded, although threaded 
applications are supported.

These are the OSs I know something of.

Joe Gwinn

Hans J�rgen Jakobsen wrote:
> On Sat, 23 Feb 2008 23:38:09 GMT, Danny Mayer wrote:
>> No need to look. I haven't had the bandwidth to get much done in the 

>> last few months. Needless to say it will be much easier to implement on 

>> Windows than on Unix machines as Windows uses threads so there's no 

>> issue with the transfer of information between processes.
> 

> Why are threads not used on UNIX?
> /hjj

The experience with BIND 9 shows that various implementations of 

pthreads are flawed and therefore compiling BIND9 with threads remains 

an option. While I am willing to undertake the work to use threads it's 

a much harder problem to make it optional.

Danny

Danny Mayer wrote:
> Hans J�rgen Jakobsen wrote:
>> Why are threads not used on UNIX?
>> /hjj
> 
> The experience with BIND 9 shows that various implementations of
> pthreads are flawed and therefore compiling BIND9 with threads remains
> an option. While I am willing to undertake the work to use threads it's
> a much harder problem to make it optional.

Hm, I'd really like to know what the limitations/problems with pthread are.

I'm assuming BIND would make heavy usage of threads, whereas ntpd would
basically only have to start one other thread to do the DNS lookups (except
the special Windows things, which have already been implemented as
threads).

There are no special requirements except for blocking critical sections
while some parameters are updated. 

This would also simplify a fix for bug #987: http://bugs.ntp.org/987


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Martin Burnicki wrote:
> Danny Mayer wrote:
>> Hans J�rgen Jakobsen wrote:
>>> Why are threads not used on UNIX?
>>> /hjj
>> The experience with BIND 9 shows that various implementations of
>> pthreads are flawed and therefore compiling BIND9 with threads remains
>> an option. While I am willing to undertake the work to use threads it's
>> a much harder problem to make it optional.
> 

> Hm, I'd really like to know what the limitations/problems with pthread ar
e.
> 

> I'm assuming BIND would make heavy usage of threads, whereas ntpd would
> basically only have to start one other thread to do the DNS lookups (exce
pt
> the special Windows things, which have already been implemented as
> threads).
> 


Yes.

> There are no special requirements except for blocking critical sections
> while some parameters are updated. 

> 


Yes.

> This would also simplify a fix for bug #987: http://bugs.ntp.org/987
> 


Yes.

Danny
> 

> Martin