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...
> 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.
> 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
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.
>> 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.
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 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.
Thx for the iburs hint, I will try that.
Still very strange is that offset, wich also occurs when using network-server from a ntp-pool..
>> 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
> 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.
> _______________________________________________
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?
>> 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.
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?
Nicola Berndt wrote: > Richard B. Gilbert schrieb:
>>Nicola Berndt wrote:
>>>Hello,
>>>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
>>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.
>>_______________________________________________
> 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..
I'd say that a computer that needs to be rebooted other than following a 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.
Nicola Berndt wrote: >>> 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.
> 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?
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.
>>> 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
>> 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.
>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?
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.
n...@komeda-berlin.de (Nicola Berndt) writes: >>> 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.
