Date: Thu, 18 Apr 2002 06:26:19 -0700
From: Terry Lambert <tlambert2@mindspring.com>
To: John Hay <jhay@icomtek.csir.co.za>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, arch@FreeBSD.ORG
Subject: Re: get{bin,micro,nano}[up]time() - what precision ?
Message-ID: <3CBEC97B.40AFD6ED@mindspring.com>
References: <200204171046.g3HAkZZ32677@zibbi.icomtek.csir.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
John Hay wrote:
> Uhm Terry, aren't you mixing up get{bin,micro,nano}[up]time() with
> {micro,nano}[up]time()? The last set gives you up to the machine's
> capability precision. That can be 1ns or better depending on the
> machine. Both sets are available for use in the kernel
Not really. The time resolution in the kernel is not really
relevent for the number one use in user space, which is logging.
I built a "zero system call" gettimeofday(2) and time(3) using
double mapped pages for the timecounter state for the 8254 and
the Pentium TSC, based on Poul's code.
Limiting the resolution on these limits the accounting granularity
to approximately one quantum, even when the operations per request
can be handled in significantly less than one quantum.
If you look at the TSC code, using the data from the last interrupt,
and using the timecounter "calibration" data, along with a current
reading of the cycle counter, the reading of the current cycle counter
is functionally equivalent to the SunOS 4.1.3 approach, except that
it has a real value, instead of a statistical value, to do the job.
Personally, I'm more concerned with the clamping as it relates to
things requiring timestamps in the kernel -- not intervals. The
proposed changes seem (to me) to be damaging to profiling.
The original complaint by Poul was:
] I'm soliciting input from users of the get*time() family of functions
] in the kernel on what the minimal desirable precision is.
]
] Currently they return a timestamp which is no more than 1/HZ out
] of date. For contemporary values of HZ, that seems to be adequate.
]
] As people increase HZ to above 10000, it starts to cost more to
] update timecounters every tick, and the question naturally arises:
] what is the target resolution for get*time() functions ?
This was not the question which naturally arose, for me. The
question which arose for me was "Why the limear relationship
between timecounter update frequency, cost, and resloution?".
I'm not complaining about the work Poul has done on the time
counter code in FreeBSD; if he hadn't perservered, we would
all still be seeing "timecounter moved backwards" console
messages. I'm sure we would all buy him a beer for fixing
that problem (8-)). But I do question the assumption of a
linear relationship being impossible to overcome by any means
other than a decreased update resolution.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CBEC97B.40AFD6ED>