On 2007-09-09, Steve Kostecke <[EMAIL PROTECTED]> wrote: > [NOTE: My configuration suggestions are at the bottom of this rather > long article]
Many thanks in advance, for the effort. >>>> The precision desired here is one of human scale, not milliseconds >>>> (or worse). >>> >>> Please define "human scale". >> >> Good enough(tm) for people who have never heard of NTP. :-) > > A serious question deserves a better answer than that. That was a serious answer. As precise as a normal person would like it, when that person has no knowlegde of NTP. Therefore about as precise a settings it manually from a wristwatch, radio time signal, or speaking clock (expression?). > Depending on the requirements of this application NTP may or may not be > the right solution. It might not be. It's just the most visible and available solution on a current Linux system. And it does the work 'for ya'. But alternatives are possible. >> The main concern is that that the laptop spends to much time adjusting, >> correcting, etc... when it's only got a short time on the ISP. > > Please define "too much time" and tell us why you think this is so. Well, that's not all that clear to me. Remember, I'm just posting for someone else, here. :-) But I gather that he see's activity/log entries/whatever going on a long time after he's returned home. >> As mensionned before, short time is a few (anywhere between 1 and 4) >> hours. As the other machines of that LAN can't rely on the continuous >> presence of the laptop, they too need to update quickly. > > Please define "update quickly" and tell us why this is necessary. I'd have thought the paragraph to be clear. Quick enough to be finished and become stable wwithin that 1-4 hours period that it's running and connected at my place, having access to my ISP's NTP server. >>> A network connection is not the only way to acquire the time base >>> used by NTP. Other sources include GPS/WWBV/CHU/MSF/DCF77/etc >>> receivers, high quality external oscillators, and even a serial link >>> (using the dumbclock driver). >> >> Spending money is not really an option. > > Please explain why this is so. ?????? That's the way it is. Maybe the problem is not important enough, maybe the budget is low, maybe ... I don't know. >> What is that latest option? A serial link? To what ? > > The dumbclock driver can be used to acquire time stamps via a serial > link from another system or some other source which can emit properly > formatted time stamps at one second intervals. This scheme may be useful > in situations where no network connection is permitted between certain > systems. I only included it because the nature of your application was > unclear. Thanks for the info. Not to be rude, but the nature of the application is clear to most that have allready answered. 1. The desktop PC's in his LAN are completely isolated from the Net, as he hasn't got a connection to the Net. Syncing them is no big deal; declare one of them to be the source. 2. Clocks might shift over time, that it'd become visible to the eye after a few months. So using an outside source, from time to time, seemed like a good idea at the time. 3. Since he visited me anyway, with the laptop - to exchange data - it seemed the obvious thing to do: make the laptop the NTP server for the other machines. And let the laptop update itself from my ISP, when it's connected to my LAN. >> It's precision is what it is. > > One would assume that it is desireable for one clock second to roughly > equal one real second; roughly on a par with the average quartz wrist > watch. Good assuption. But we both know that laptop's have bad HW clocks. >> The type of corrections currently active might cause the various >> machines to have different time (compared to the second), because >> their time source is only available for short times. > > So you're looking for all clocks to be "on the same second" ? How much > variance is acceptable? All on the same second would be perfect. >>>> Imagine a laptop, connected to the net only once every few (2-3) >>>> weeks. The connection lasts a few hours, maybe less. It gets it's >>>> time updated from the NTP server from the ISP. >>> >>> Ntpd doesn't merely "update" the laptop's clock to the "correct >>> time". >> >> I know. And - sorry for the blasphemy - that's the main problem. > > Let's leave inflamatory words such as blasphemy out of this discussion. > > NTP is designed to synchronize clocks with a time base. In the absence > of a legitimate (i.e. disciplined) time base it is possible to utilize > an arbitrary ntpd as an undiciplined time base. <snipped> I know that. But imagine this: - the laptop is more or less OK, in my LAN - shutdown, return home, reboot: the clock shifts So far, all is good. It's probably still reasonably close to the correct time. And certainly to serve as reference, should one of the other machines drift several seconds. Next: - his laptop is on his LAN, he moves data I gave him to another machine (PC-A). This machine will sync with the laptop's clock. - end of transfer, the laptop is stopped - he starts another machine (PC-B). This one doesn't find the laptop and stays on it's own time. - the next day, by chance, the laptop and PC-B are switched on simultaneously: PC-B syncs... on a laptop clock that may have shifted. - then he starts PC-A... which starts syncing with the new laptop time ... the shifts are numerous. That's a disadvantage of using the laptop. But it's by far the most 'available' system, as the newsserver is on it. And it brings a 'correct time' from the outside. Only concern is: when the machines see the laptop, can they sync realy, really fast, so that their NTP's work is done in a very short lapse of time? In that case at least, the clocks would be within the same second most of the time. > Then this is pointless exercise because you aren't really bringing > anything back to the LAN. True from the point of view of someone intrested in precise time keeping. But it would ensure that the clocks's drift is kept within 'certain' limits. >> True. But as long as the other machines on that LAN sync to the same >> time as the laptop, any time they detect it, that's fine. > > ntpd _can_ do that. > >>>> What can be done to get it's time sync'ed as fast as possible, >>> >>> 1. You need to have a drift file that contains an accurate frequency. >> >> Not an option for me, too fussy. > > It's a requirement. The drift file is where ntpd stores the correct > frequency for the clock. Maybe. But since the problem seems to be the shift in time at every boot/shutdown, is there any point in finding out what precise frequency the system clock has? > If your OS is configured correctly, the system clock is saved to the > hardware RTC during shut down. Boot a laptop several times, each time looking at it's time from within the bios, wihout loading the OS. After enough reboots, you'll see a error. Maybe today's laptops are better behaved, but I've had machines loosing several seconds in a few days, when the OS didn't get it's time sync'ed. >> Can be usefull in desperate situations, but we'd like to avoid doing it >> manualy, for fear of skipping it when we're in a hurry. > > This is why we have shell scripts. The running of which is subject to old people's forgetfullness. (and I'm counting myself with those :-) And the visits are not cron-able. We're people dammit, not machines! :-) :-) > *** Configuration Suggestion Many, many thanks ! -- There is an art, it says, or rather, a knack to flying. The knack lies in learning how to throw yourself at the ground and miss. Douglas Adams _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
