junk1@cbnews.cb.att.com (eric.a.olson) (06/14/91)
I maintain a couple of dozen 386/486s networked
together with RFS and use nmake viewpathing. The current
reference area(s) might be on another machine. I am capable
of syncing any machine to a common machine's time in seconds,
using tools I have found here and within AT&T. However, no matter
how often I sync, it is not often enough to satisfy nmake.
In fact, more frequent sync seem to force recompiles more often.
A newer version of nmake will allow me to fudge the time within
a few seconds; however, this newer version has semantic differences
which make my current makefiles incompatible.
Is there a version of the network time protocol available
for TLI/streams? I suspect that if I could sync them to milliseconds
rather than seconds, it might work. Anybody else have any thoughts
on this?gsf@ulysses.att.com (Glenn S. Fowler) (06/14/91)
In article <1991Jun14.024635.15860@cbnews.cb.att.com> junk1@cbnews.cb.att.com (eric.a.olson) writes: > I maintain a couple of dozen 386/486s networked > together with RFS and use nmake viewpathing. The current > reference area(s) might be on another machine. I am capable > of syncing any machine to a common machine's time in seconds, > using tools I have found here and within AT&T. However, no matter > how often I sync, it is not often enough to satisfy nmake. > In fact, more frequent sync seem to force recompiles more often. > A newer version of nmake will allow me to fudge the time within > a few seconds; however, this newer version has semantic differences > which make my current makefiles incompatible. this may not be true for s5r4 (knowlegable input welcome), but for earlier RFS a client and server negotiate system times when a client fs is mounted skew(client_mount) = time(server) - time(client) then the skew is accounted for in the client struct stat st_?time fields st_mtime(client) = st_mtime(server) - skew(client_mount) this way the server uses its own time to set st_?time but clients see the files in their own time frame this scheme is fine for the duration of a given mount, assuming that the client and server times don't drift much after the initial mount it also keeps make happy without doing network time syncs the side effect is that st_mtime for a given file can change from one RFS mount to the next *even though the file didn't change* now consider nmake -- it keeps the state, including st_mtime, of all files it checked from previous runs, so if the cilent and server times skew between RFS mounts, even by just a second, then all of those files are out of date the fudge time hack for RFS, mentioned above, treats times equal if the difference is less than the fudge (if the fudge is too big then some changes may go unnoticed) first, this behavior breaks common sense file system semantics second, the real solution (for the RFS vendor) is to drop the skew hack and use a modern method to *keep the network times in sync* Glenn Fowler (908)-582-2195 AT&T Bell Laboratories, Murray Hill, NJ uucp: {att,ucbvax}!ulysses!gsf internet: gsf@ulysses.att.com
rbraun@spdcc.COM (Rich Braun) (06/17/91)
For a couple of months, I had a network time server running which actually kept accurate time (in file /etc/tcp, uncomment the line which starts up 'timed -M' on *one* of the systems, and just run 'timed' on others), but as soon as a second machine was brought up running 3.2.2, the clock started losing time (similar to the way it does if two machines are brought up with 'timed -M'). I'm about to give up on synchronization myself and just write a script for each system's startup file which just does 'set rsh <server> date' followed by 'date $1 $2 $3' or some such kludge. There seems to be no way to win by merely using software shipped by SCO. Software can be downloaded from the University of Delaware and other places, but I'm not yet convinced that's necessary. My network presents a bit of a problem, because it contains onesies and twosies of systems from various vendors, making it rather difficult to compile any software which has to run on all systems. -rich