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