"Richard B. Gilbert" <[EMAIL PROTECTED]> writes: >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.
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. >> >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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
