Well, to state the obvious, there is always ntpdate or manual (step) time updates. One can state all one wants that the site *should* use ntp. But that is not always done (and even ntp will step the time if the difference is too large). If an algorithm *needs* monotonically increasing numbers for programatic correctness, the TOD is not a reliable source (without other coding). If the TOD is simply there for (human?) informational value, updates every few milliseconds may very well be sufficient. Your mileage will vary.
Gary -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Troy Benjegerdes Sent: Monday, March 07, 2005 9:28 AM To: Derrick J Brashear Cc: [email protected] Subject: Re: [OpenAFS-devel] fileserver profiling On Thu, Mar 03, 2005 at 08:08:27PM -0500, Derrick J Brashear wrote: > On Thu, 3 Mar 2005, Troy Benjegerdes wrote: > > >I don't see how you'd ever get a clock that goes backwards with this > >method.. it might not increase under high load, but would that be a > >problem? > > We have had a multiprocessor Linux system where the clock went backwards > without the help of ntp during normal operation. How many CPU's did this system have, and what version of Linux? If this is still reproduceable on a 2.4 or 2.6 kernel, it should be fixed. (Also, was this x86, or some other architecture) > >Can we set the "time" thread to real-time priority? Or can we set up a > >small chunk (say 4k) of System-V shared memory (or mmap-ed file) that > >can be updated at some configurable rate (1hz to 100hz maybe) by a process > >with real-time priority? All the AFS processes (not just the fileserver) > >would then map that memory read-only. > > sysv shared memory will have portability issues. mmap() is probably > better. but lwp dealt by having an approxtime and a time call, and if you > needed a real time, you asked, and if you didn't you used the cached time. > e.g. we already had a hack. If we have some process updating the time in a mmap()'ed file, wouldn't that have about the same cost as getting a cached time? If we are paranoid about time going backwards, the process updating the time could check for that as well, and spit out some verbose warning to syslog. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
