larry@focsys.uucp (Larry Williamson) (03/13/90)
I'd like to get some of these machines to come to a consense as to the current time of day. I understand that all machines running timed on a network will negotiate with each other to determine the best approximation of the current time of day. Our BSD machines have timed. Our Mips machines have timed. Why not our 386/ix machines? -larry
trb@haddock.ima.isc.com (Andrew Tannenbaum) (03/14/90)
In article <LARRY.90Mar12164645@focsys.uucp> larry@focsys.uucp (Larry Williamson) writes: > Our BSD machines have timed. Our Mips machines have timed. > Why not our 386/ix machines? Timed was designed to run under BSD, and it relies on the "Berkeley UNIX Time Synchronization Protocol (TSP)" (See your 4.3BSD Manual SMM:22) and the BSD adjtime(2) system call. Since neither TSP nor adjtime(2) are supported by AT&T UNIX or ISC UNIX Sytem V release 3 for the 386 (formerly known as 386/ix), timed is not supported on ISC UNIX 5.3. If you have a machine with timed, it is a straightforward matter to run a script over the net from one of your well-synchronized machines that adjusts the clocks on your Sys V machines using settime(2). This is a hack solution, but it may help. Note that there are dangers in setting a system's clock backwards without adjtime (mostly because it can screw up "make" or other such time-dependent software) so you can sync it at night, but be careful about people who run system builds overnight, and so on. It's clear (to me) that in these days of networked systems (especially file systems), it becomes increasingly important to sync the clocks on a local net. Most manufacturers respond to customer demand - if you need it, let us know. (I don't work in the ISC UNIX product organization, so it's not me who needs convincing.) Btw, timed has been superceded by NTP which has in turn been superceded by XNTP. For info on these, check out louie.udel.edu [128.175.1.3] ~ftp/pub/ntp and ~ftp/pub/ntp/xntp. It looks like XNTP is the clock-watcher's dream, but I haven't played with it yet. Andrew Tannenbaum Interactive Cambridge, MA +1 617 661 7474
guy@auspex.auspex.com (Guy Harris) (03/15/90)
>Timed was designed to run under BSD, and it relies on the "Berkeley >UNIX Time Synchronization Protocol (TSP)" (See your 4.3BSD Manual >SMM:22) and the BSD adjtime(2) system call. Since neither TSP nor >adjtime(2) are supported by AT&T UNIX or ISC UNIX Sytem V release 3 for >the 386 (formerly known as 386/ix), timed is not supported on ISC UNIX 5.3. Uh, I thought "timed" *was* what implemented the "Berkeley UNIX Time Synchronization Protocol" in BSD systems, so the only reason TSP isn't supported by AT&T UNIX or ISC UNIX System V Release 3 for the 386 (formerly known as 386/ix) is that they don't come with "timed". Saying "timed" isn't supported because TSP isn't supported closes the circle.... The part that breaks the circle is "adjtime", which "timed" uses to adjust the clock in a less disruptive fashion (instead of jumping the clock to its new value, it slows it down or speeds it up temporarily until it syncs up). Since AT&T UNIX System V Release 3.x, for all values of "x" I know about, doesn't support "adjtime()", and since ISC apparently hasn't added it, "timed" won't work without modifications; as Andrew notes, while you can adjust the clock without "adjtime()", there are dangers in adjusting it backwards. Since AT&T UNIX System V Release *4*.x *does* support "adjtime()", as well as supporting various BSD features, it may be easier to bring up "timed" (or other time synchronizers originally developed in a BSD environment) under S5R4 than under S5R3.