Very large offset and jitter values after reboot
Nicola Berndt
I have now successfully set up my machine to use a usb-gpd-mouse to set
the time. Strangely every time I reboot I get results like this, wich
settle down after a (not so short) while:
remote refid st t when poll reach delay offset
jitter
==============================================================================
GPS_NMEA(0) .GPS. 0 l 9 64 37 0.000 -580.75
3965.19
The problem is, that this takes rather long and the computer's job
actually is, to provide exact time outdoors right after booting..
I already tried what would happen if I did a 'hwclock --systohc' once
things are settled, but with no luck. My driftfile btw. says -35.666 -
looks good to me - and I am very worried about the huge jitter...
Any ideas for me, anyone?
Thx and regards,
../nico berndt
David Woolley
>
> I have now successfully set up my machine to use a usb-gpd-mouse to set
Not a good idea. USB serial ports have high latency and jitter and NMEA
feeds also tend to have high jitter, as they are designed for
navigation, not for time. You need a PPS signal on an ISA or PCI serial
port interface.
> the time. Strangely every time I reboot I get results like this, wich
> settle down after a (not so short) while:
>
> remote refid st t when poll reach delay offset
> jitter
> ==============================================================================
> GPS_NMEA(0) .GPS. 0 l 9 64 37 0.000 -580.75
> 3965.19
You've not had your first 8 samples yet. You haven't actually had
enough for ntpd to act on the data. You can speed that up with iburst,
but ntpd will still take a long time to get a very tight lock. jitter
will reduce as you get to the eight samples. The good? think, is that
you are more than 128ms out, so that ntpd will step the time, to zero
the offset, once it gets enough samples.
>
> The problem is, that this takes rather long and the computer's job
> actually is, to provide exact time outdoors right after booting..
It is possible to get within about 10ms in two or three minutes.
Richard B. Gilbert
1. Don't reboot! My Windows, Linux, Solaris, and OpenVMS systems will
all run until the power goes off for longer than the run time of my UPS.
2. Start ntpd with the "-g" switch. The -g switch tells it to get and
set the correct time. Following startup, ntpd will discipline the clock
in the usual way. It may take a relatively long time, around thirty
minutes, to settle into really tight synchronization.
Nicola Berndt
> Nicola Berndt wrote:
>
>> I have now successfully set up my machine to use a usb-gpd-mouse to set
>>
>
> Not a good idea. USB serial ports have high latency and jitter and NMEA
> feeds also tend to have high jitter, as they are designed for
> navigation, not for time. You need a PPS signal on an ISA or PCI serial
> port interface.
>
>
had not time to really investigate yet. There is a thread connected to
that some days earlier on this list. I need the nmea-time for now, in
order to get things started.. PPS will follow very soon..
>> the time. Strangely every time I reboot I get results like this, wich
>> settle down after a (not so short) while:
>>
>> remote refid st t when poll reach delay offset
>> jitter
>> ==============================================================================
>> GPS_NMEA(0) .GPS. 0 l 9 64 37 0.000 -580.75
>> 3965.19
>>
>
> You've not had your first 8 samples yet. You haven't actually had
> enough for ntpd to act on the data. You can speed that up with iburst,
> but ntpd will still take a long time to get a very tight lock. jitter
> will reduce as you get to the eight samples. The good? think, is that
> you are more than 128ms out, so that ntpd will step the time, to zero
> the offset, once it gets enough samples.
>
>
Still very strange is that offset, wich also occurs when using
network-server from a ntp-pool..
>> The problem is, that this takes rather long and the computer's job
>> actually is, to provide exact time outdoors right after booting..
>>
>
> It is possible to get within about 10ms in two or three minutes.
>
> _______________________________________________
> questions mailing list
> ques...@lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions
>
Nicola Berndt
>
1, As I wrote already, the device has to work outdoors, where there is
no unlimited power-source, so I have to reboot. Also I think, a computer
that cannorttake a reboot has a problem wich needs to be adressed. Just
my opinion, though..
2, I forgot to mention that I already do so, still takes too long to
settle. I also don't understand what is taking so long, since - jitter
or not - the nmea time is precise enough to just quickly set the time at
startup and then let things go their way. Can someone explain that to me?
Best regards,
../nico berndt
Nicola Berndt
>> jitter
>> ==============================================================================
>> GPS_NMEA(0) .GPS. 0 l 9 64 37 0.000 -580.75
>> 3965.19
>
> You've not had your first 8 samples yet. You haven't actually had
> enough for ntpd to act on the data. You can speed that up with iburst,
> but ntpd will still take a long time to get a very tight lock. jitter
> will reduce as you get to the eight samples. The good? think, is that
> you are more than 128ms out, so that ntpd will step the time, to zero
> the offset, once it gets enough samples.
Just tried the iburst option, but I had to figure it only works with the
server command, not on refclocks.
What really puzzles me, is the stoical 600 ms offset after rebooting.
Since it is always returning having more or less the same amount, I
should really be able to get rid of it, no?
Richard B. Gilbert
power failure or a hardware failure, has something wrong with its
hardware or operating system. Once upon a time, Windows needed regular
reboots but this was largely cured by Windows 2000. Windows XP can run
for months between reboots.
> 2, I forgot to mention that I already do so, still takes too long to
> settle. I also don't understand what is taking so long, since - jitter
> or not - the nmea time is precise enough to just quickly set the time at
> startup and then let things go their way. Can someone explain that to me?
>
I don't believe you said what kind of GPS receiver you were using. It
sounds as if your are using a receiver designed for navigation rather
than timing. Timing receivers usually use a binary protocol rather than
NMEA. Timing recievers also typically have a Pulse Per Second (PPS)
output which provides a very precise indication of the "top of the second".
Even on a warm start with a good value in the drift file, ntpd can take
up to thirty minutes to pull in to tight synchronization. If you are
only looking for the seconds you may never notice the time required to
synchronize within, say, 100 microseconds.
If you are cold starting ntpd, delete the drift file before starting!
No drift file is better than one with an incorrect value for drift.
Last but not least, ntpd uses some complex algorithms to discipline the
clock.
It's NOT just a set the time and forget it. The typical computer clock
is NOT designed for high accuracy; left to itself it might be off by as
much as 500 PPM or 43 seconds per day. Ntpd makes the clock tick at
intervals as close as possible to one tick per second.
If you understand such things as phase locked loops (I don't) you'll
find the math in RFC-1305.
Richard B. Gilbert
600 ms seems to be a large error for a warm start. Are you using "-g"
to start ntpd? Forgive me if this has already been asked and answered.
Unruh
You could try chrony ( assuming you are on Linux) which has the ability to
handle the rtc as well and correct for its errors. It settles down much
faster than does ntp, and gives tighter control over the clock in many
situations.
Also as stated use the -g flag to ntpd
Unruh
>>> remote refid st t when poll reach delay offset
>>> jitter
>>> ==============================================================================
>>> GPS_NMEA(0) .GPS. 0 l 9 64 37 0.000 -580.75
>>> 3965.19
>>
>> You've not had your first 8 samples yet. You haven't actually had
>> enough for ntpd to act on the data. You can speed that up with iburst,
>> but ntpd will still take a long time to get a very tight lock. jitter
>> will reduce as you get to the eight samples. The good? think, is that
>> you are more than 128ms out, so that ntpd will step the time, to zero
>> the offset, once it gets enough samples.
>Just tried the iburst option, but I had to figure it only works with the
>server command, not on refclocks.
Oops forgot you have a gps clock. chrony does not work with refclocks.
>What really puzzles me, is the stoical 600 ms offset after rebooting.
>Since it is always returning having more or less the same amount, I
>should really be able to get rid of it, no?
It sounds like your rtc has problems. You can use hwclock to compensate for
rtc problems.
Unruh
Lets say his computer runs on a battery (it is outdoors) with a 4 hour
lifetime. And lets say that he only needs to bring up the computer for 5
min. On your suggestion, it would last for 4 hours. Bringing it up for 5
min at a time once a day would last for 80 days. Do you see the
difference?
>> 2, I forgot to mention that I already do so, still takes too long to
>> settle. I also don't understand what is taking so long, since - jitter
>> or not - the nmea time is precise enough to just quickly set the time at
>> startup and then let things go their way. Can someone explain that to me?
ntp takes a long time to settle by design. It is due to the clock
discipline proceedure that Mills decided on.
But on a refclock you should be albe to be on poll 4 or less ( 16 sec) so
the settling time should be minutes, not hours.
Martin Burnicki
Maybe you should first try to find out whether the initial system clock is
off by 600 ms after reboot, in which case the problem is due to the
mainboard's RTC, or whether the first NMEA string(s) after power-up are
sent with that time offset
Run
ntpq -c as
to get the list of associaton IDs from your running NTP daemon, and then run
ntpq -c "rv assid"
where you replace assid by the association ID listed by the first command.
This displays ntpd's filter values. If do this after the first few samples
the the output should show whether all NMEA strings show the 600 ms offset,
or only the first (few) entries.
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
Nicola Berndt
I actually said "a computer that /cannot take a reboot/". You are
talking a computer that needs rebooting ... Think of a laptop for
instance, that runs on batteries. It simply cannot run forever.
>> 2, I forgot to mention that I already do so, still takes too long to
>> settle. I also don't understand what is taking so long, since - jitter
>> or not - the nmea time is precise enough to just quickly set the time at
>> startup and then let things go their way. Can someone explain that to me?
>>
>
> I don't believe you said what kind of GPS receiver you were using. It
> sounds as if your are using a receiver designed for navigation rather
> than timing. Timing receivers usually use a binary protocol rather than
> NMEA. Timing recievers also typically have a Pulse Per Second (PPS)
> output which provides a very precise indication of the "top of the second".
I am using a u-blox LEA-4H module, wich can do binary and text modes and
provides a pps signal on a separate line. The pps part gives me trouble
at the moment though (noise) and I will either change the module or fix
the problems soon. Not an option for right now, though.
> Even on a warm start with a good value in the drift file, ntpd can take
> up to thirty minutes to pull in to tight synchronization. If you are
> only looking for the seconds you may never notice the time required to
> synchronize within, say, 100 microseconds.
>
> If you are cold starting ntpd, delete the drift file before starting!
> No drift file is better than one with an incorrect value for drift.
Why would I have an incorrect value in the drift file? Might that cause
my offset? As I understood it, the driftfile is being written to over a
longer period of time and is used to correct a general drift of the
clock. This might vary under different temperatures maybe, but should be
rather stable besides, no?
> Last but not least, ntpd uses some complex algorithms to discipline the
> clock.
> It's NOT just a set the time and forget it. The typical computer clock
> is NOT designed for high accuracy; left to itself it might be off by as
> much as 500 PPM or 43 seconds per day. Ntpd makes the clock tick at
> intervals as close as possible to one tick per second.
Sure, but /initially/ set the clock quickly and then go on with all the
ntp-goodies for timekeeping should be in it. That is what I am looking
for. Being as fast as possible as precise as possible and getting better
from there on.
> If you understand such things as phase locked loops (I don't) you'll
> find the math in RFC-1305.
Regards,
../nico berndt
Nicola Berndt
Yes, I do. Strange, right?
Nicola Berndt
Well, I tried 'hwclock --systohc' with no different result. More
suggestions?
tel: +49 30 / 6730 1395
fax: +49 30 / 6730 1394
gsm: +49 163 / 243 6802
________________________________
Nicola Berndt
David J Taylor
> Richard B. Gilbert schrieb:
>> 600 ms seems to be a large error for a warm start. Are you using
>> "-g" to start ntpd? Forgive me if this has already been asked and
>> answered.
>
> Yes, I do. Strange, right?
Is there any chance that the PPS you are using is 400ms or 600ms long, and
you are actually syncing off the wrong edge of the pulse - and not the
edge which co-incides with the UTC second?
Cheers,
David
n...@komeda-berlin.de
Hi David,
somehow you keep getting me wrong, so again in full: I am using:
NMEA, not PPS, because the receiver (u-blox LEA-4H module) has noise on the PPS-line. NMEA is in text-mode and the receiver COULD do binary-mode, wich I don't use.
The 600 ms also occur using networked server (also wrote so before..), so the error comes from elsewhere.
David Woolley
> I konw, but setting up pps failed due to noise on my pps line, wich I
> had not time to really investigate yet. There is a thread connected to
Were you using a direct ISA or PCI interface for the PPS signal? If not
you can expect a large jitter, if not the multiple counts that you
reported. Is the PPS being properly level converted to RS 232C level?
> Thx for the iburs hint, I will try that.
It's been pointed out that iburst doesn't work for reference clocks.
There is an implicit assumption that reference clocks are used on proper
servers and that people only want speed ups on pure clients.
>
> Still very strange is that offset, wich also occurs when using
> network-server from a ntp-pool..
I'm not sure that I would expect better than 1 second accuracy, reading
the RTC from the kernel (this is the sort of thing that may vary between
kernel releases, though). You may find that using hwclock to read the
RTC does wait for the second boundary. (The RTC can only be read to one
second, however, one can wait for the change in seconds.)
You should also expect a significant skew between NMEA time and the true
seconds, which will be exacerbated by the USB interface.
David J Taylor
[]
> Hi David,
>
> somehow you keep getting me wrong, so again in full: I am using:
> NMEA, not PPS, because the receiver (u-blox LEA-4H module) has noise
> on the PPS-line. NMEA is in text-mode and the receiver COULD do
> binary-mode, wich I don't use.
>
> The 600 ms also occur using networked server (also wrote so
> before..), so the error comes from elsewhere.
Sorry about that - PPS must have been on my mind.
What "tinker" do you have set for the NMEA source?
Just to confirm, you see the same error even when using a set of Internet
servers?
Cheers,
David
Richard B. Gilbert
If the temperature of the machine has changed significantly since the
drift file was written, ntpd will start with an incorrect value for
drift. If you are doing a cold start, it is usually best to delete the
drift file. The drift file is overwritten with a new value every hour.
>
>> Last but not least, ntpd uses some complex algorithms to discipline the
>> clock.
>> It's NOT just a set the time and forget it. The typical computer clock
>> is NOT designed for high accuracy; left to itself it might be off by as
>> much as 500 PPM or 43 seconds per day. Ntpd makes the clock tick at
>> intervals as close as possible to one tick per second.
>
> Sure, but /initially/ set the clock quickly and then go on with all the
> ntp-goodies for timekeeping should be in it. That is what I am looking
> for. Being as fast as possible as precise as possible and getting better
> from there on.
>
>> If you understand such things as phase locked loops (I don't) you'll
>> find the math in RFC-1305.
>
> Regards,
> ../nico berndt
The drift file is written once per hour and contains the then current
value of the drift in Parts Per Million. Ideally this value will be in
the range -100 to +100. This allows a warm start to use a reasonable
approximation of the current drift correction. When doing a cold start,
the drift file should be deleted prior to starting ntpd.
David Woolley
>
> If the temperature of the machine has changed significantly since the
> drift file was written, ntpd will start with an incorrect value for
> drift. If you are doing a cold start, it is usually best to delete the
> drift file. The drift file is overwritten with a new value every hour.
You would need a large temperature variation to justify this. If the
devices were exposed to the elements it might be justified. It would
rarely be justified if they were in living space.
One consequence of deleting the file is that it forces a frequency
calibration, which means that, once there are enough samples (about 6)
to set the clock, it will be allowed to free run for about 15 minutes
before having any further corrections applied. If you want a tight lock
in less than 20 minutes, you need a drift file.
Unruh
Try using the --directisa option both when you write the rtc on
shutdown and when you read it on bootup. If you have a very modermn machine
with HPET the rtc driver is badly munged. It should only be out by about
13ms, not 600 however.
Also look at the /etc/adjtime file
Unruh
Sorry-- don't bother. chrony does not support hardware clocks ( like your
nmea clock)
It would be really nice if someone installed glue into chrony so it could
use the ntpd hardware drivers. I do not have the time or competence.
Unruh
He is not using pps-- his pps line is too noisy. He is using nmea strings.
Now, we know that the nmea string is long (esp at the default 4800bd)
so it might be that ( needs to use one of the fudges to adjust the time)
>Cheers,
>David
Nicola Berndt
- I just wanted to let you know, that I will be gone for 3 days and will
be back on topic after that.
Thx for helping me so far and I will report on in a couple of days!
All the best,
../nico
Serge Bets
On Sunday, August 24, 2008 at 16:12:51 +0000, Nicola Berndt wrote:
> I did a 'hwclock --systohc' once things are settled, but with no luck.
First verify that hwclock worked well, immediatly looking at the
adjtimex "system-cmos" offset value:
| # hwclock --systohc ; adjtimex --compare=1
| --- current --- -- suggested --
| cmos time system-cmos error_ppm tick freq tick freq
| 1220000702 0.000007
If the offset is not a sane few microseconds, then let's see if
hwclock --systohc --debug can reveal something.
Serge.
--
Serge point Bets arobase laposte point net