> More a matter of personal preference than anything else, perhaps. Up to > this point, I have avoided the hassle of setting up ntpd and driving the > clock sync from cron.
>From what you say, I don't think you understand how NTP (the protocol) and the ntpd implementations work. ntpd does not need a cron job; each system synchronises with a local server once when ntpd starts (via ntpdate). Then the ntp daemon uses the adjtime system call to gently synchronise this system clock SPEED with the server. For the geeks, it actually tunes your clock with a software PLL (Phase Locked Loop). The point is NOT to readjust an inaccurate clock in a large step every so often, but to regulate the local clock as accurately as possible. As LTSP systems provide access to their servers, the obvious thing is to synchronise with the server. > I just feel better about avoiding added Internet bw > for each client. The bw may be negligible on an individual basis, but if > every node on every LAN used it to sync to a public time server, then it's > different. Periodic synchronisations with e.g. rdate are likely to use *more* network traffic if they are frequent enough to keep your clock reasonably accurate, since they will typically generate traffic for e.g. DNS lookups. Even at its most frenetic, ntpd sends a packet every 64 seconds; when it's relaxed it sends every 1024 seconds; the protocol does NOT resend - it is tolerant to the odd dropped packet and does not stress the network if there is no immediate answer. Read the NTP doc - the intention is that at each site handful of servers can then act as peers, to reduce the drift of any one clock: a couple of those can then use public servers in turn: the number of wide area links can be very low. Most ISPs have local NTP servers for their customers - we have a demon link, so we use ntp.demon.co.uk. Most recent ntpd implementations can use multicast IP, and that's what I'd recommend for LTSP systems. ntp.conf need contain only "multicastclient" and not the names of specific servers; the servers need to say "broadcast ntp.mcast.net ttl 2" in addition. > If however we're comparing the choice of having the clients > use ntp vs rdate to sync to a local server, then it's a moot point. No it isn't. NTP keeps your clock true to within *milliseconds*, pretty much all the time. Once it has your clock synchronised is stays that way rather than drifting and needing to be reset. It was *designed* to reduce the traffic and behave well local and wide area networks. It can use crypto based authentication. If (accidentally or intentionally) one of the servers gives a false time, ntpd will drop the bad server from its list of trusted choices. Furthermore, recent ntpd implementations track clock drift in a file; this means that after a reboot, ntpd has a good estimate "up-front" of how to compensate for local clock drift will ntpd was away, and how it is likely to drift while it finds a server, so that it will be more accurate and will synchronise faster. Though PC clocks are notoriously inaccurate, they are usually *consistent*, and NTP knows how to exploit this. ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
