rrichter@link.ph.gmr.com (Roy Richter) (06/10/91)
In article <90C443480021E50F@ecl.psu.edu>, JDB@ECLA.PSU.EDU ("John D. Balogh, PSU OTC, 814.863.1252") writes: |> Back on Nov. 12, 1990, Dave quoted Van Jacobson on the following: |> "Sun has incorporated the System V timekeeping code in 4.x and that |> this code is broke to max." I think there are several groups of people syncing clocks who are distinguished by their desired level of accuracy. Comments like the above are from an extremum group, who desire sub-millisecond accuracy. This group is needed to further clock research, but I personally don't think such accuracy is needed for daily operations. I'm willing to be proved wrong, however. Here we run 4.1.1 and seem to be keeping time to the 10-20 millisecond level with little problem. If you are happy with this accuracy, do it and don't worry. If you are not happy, and you know who you are, worry. -- Roy Richter Internet: rrichter@ph.gmr.com Physics Dept, GM Research UUCP: {umich,cfctech}!rphroy!rrichter
JDB@ECLA.PSU.EDU ("John D. Balogh, PSU OTC, 814.863.1252") (06/10/91)
Folks,
A little kick in the right direction would be appreciated...
Back on Nov. 12, 1990, Dave quoted Van Jacobson on the following:
"Sun has incorporated the System V timekeeping code in 4.x and that
this code is broke to max. The preferred solution is to abolish the
clock interrupt code and retrieve the corresponding code from older
releases, which admittedly is ugly."
Dave goes on to say that "I suspect fixes will be forthcoming ..."
We are about to upgrade our SPARC-1 to SunOS 4.1.1 ... should we look
for any particular patch level or part number beyond that to help
with the above problem?
Thanks!
John Balogh, Data Engineer | Usual disclamers apply.
----- +---------------------------
Penn State, Office of Telecommunications | Your mileage may vary.
Internet: JDB@ECL.PSU.EDU | Eat lots of fruit.
Bitnet: JDB@PSUECL.BITNET | Be nice to your neighbors.
AT&Tnet: +1 814 863-1252 (with voicemailgizmo) | Keep the time :-)
Fax: +1 814 863-4092 | Use standards.
SNAILmail: 205 Pine, Univ. Park, PA 16802 | Push for Interoperability.
-----------------------------------------------+---------------------------
--- For a good time : TELNET CLOCK.PSU.EDU 13
--- From a talk on NTP : 'Duncan' Jim Duncan : "Loose MIPS Sync Chips"Mills@udel.edu (06/11/91)
John, I am told the VJ fixes for SunOS are "not completely done yet." I am also told that distribution of these fixes will require agreement with Sun, which will likely delay distribution, not to mention enrich the lawyers. You are invited to complain to your Sun rep about the timekeeping problems. Dave
Mills@udel.edu (06/11/91)
Roy, Forget the submilliseconds. The extreme problem comes from writing out file-system updates, which occurs every 30 seconds and can cause glitches up to several hundred milliseconds with busy file servers. There are other problems, too, involving glitches of lesser amounts, but greater than a few tens of milliseconds. The real downer is when the clock gets yanked over the 128-ms linear-tracking interval, which causes the algorithms to perform a complete reset. Should you not care about such things, you might consider upping that interval. Dave
net@opal.cs.tu-berlin.de (Oliver Laumann) (06/11/91)
In article <9106101426.aa07183@huey.udel.edu> Mills@udel.edu writes: > The real downer is > when the clock gets yanked over the 128-ms linear-tracking interval, > which causes the algorithms to perform a complete reset. This is what happened on some of our SPARCStations after I installed xntp on them (and boy was it a downer :-). The problem was gone after a couple of days when the value in the drift file stabilized (according to the drift file, the drift is currently -1.31 on the Sun where I'm posting this article).
budden@MANTA.NOSC.MIL (Rex A. Buddenberg) (06/11/91)
------- Anybody got any idea what happens to this glitch if you demand POSIX .4 ilk for real time and use it? -------