[OpenAFS-devel] fileserver profiling

[Buhrmaster, Gary]

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=20
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: openafs-devel-admin@openafs.org =
[mailto:openafs-devel-admin@openafs.org] On Behalf Of Troy Benjegerdes
Sent: Monday, March 07, 2005 9:28 AM
To: Derrick J Brashear
Cc: openafs-devel@openafs.org
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:
>=20
> >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?
>=20
> We have had a multiprocessor Linux system where the clock went =
backwards=20
> 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)
=20
> >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.
>=20
> sysv shared memory will have portability issues. mmap() is probably=20
> better. but lwp dealt by having an approxtime and a time call, and if =
you=20
> 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
OpenAFS-devel@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-devel