Nikolay Denev wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18 Jan, 2008, at 09:04 , David Xu wrote:
davidxu 2008-01-18 07:04:42 UTC
FreeBSD src repository
Modified files:
sys/sys time.h
sys/kern kern_time.c
Log:
Add POSIX clock id CLOCK_THRE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18 Jan, 2008, at 09:04 , David Xu wrote:
davidxu 2008-01-18 07:04:42 UTC
FreeBSD src repository
Modified files:
sys/sys time.h
sys/kern kern_time.c
Log:
Add POSIX clock id CLOCK_THREAD_CPUTIME_ID, this ca
davidxu 2008-01-18 07:04:42 UTC
FreeBSD src repository
Modified files:
sys/sys time.h
sys/kern kern_time.c
Log:
Add POSIX clock id CLOCK_THREAD_CPUTIME_ID, this can be used to measure
per-thread runtime in user code.
Revision ChangesPath
jb 2006-10-03 04:01:31 UTC
FreeBSD src repository
Modified files:
sys/sys time.h
Log:
Solaris compatibility only: Be specific about the fact that
the inline function takes no arguments.
Revision ChangesPath
1.73 +1 -1 src/sys/sys/time.h
_
jb 2006-08-04 23:10:11 UTC
FreeBSD src repository
Modified files:
sys/sys time.h
Log:
Add some OpenSolaris compatibility definitions which are only visible
if _SOLARIS_C_SOURCE is defined.
Add two function prototypes which are required to feed high-resolu
In message <[EMAIL PROTECTED]>, John Polstra writes:
>On 28-Nov-2005 Poul-Henning Kamp wrote:
>> I've looked a lot at this in the ISC eventlib (bind8) but there is
>> no way to save one timestamp per iteration without getting creeping
>> imprecision in the timer controlled events.
>
>Would it help
On 28-Nov-2005 Poul-Henning Kamp wrote:
> I've looked a lot at this in the ISC eventlib (bind8) but there is
> no way to save one timestamp per iteration without getting creeping
> imprecision in the timer controlled events.
Would it help if we had something like select/poll that took an
absolute
On Tue, Nov 29, 2005 at 11:32:59AM +0100, Dag-Erling Smørgrav wrote:
> "Poul-Henning Kamp" <[EMAIL PROTECTED]> writes:
> > [1] Yes, great conference, you missed out. We beat OpenBSD approx
> > 2:1 on the beer drinking contest [...]
>
> Actually, we didn't. They stayed longer, and caught up.
The
"Poul-Henning Kamp" <[EMAIL PROTECTED]> writes:
> [1] Yes, great conference, you missed out. We beat OpenBSD approx
> 2:1 on the beer drinking contest [...]
Actually, we didn't. They stayed longer, and caught up.
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
_
In message: <[EMAIL PROTECTED]>
Bruce Evans <[EMAIL PROTECTED]> writes:
: Even with this, applications would still need to know when select() was
: called to recover the time when it returned. Adding deltas from select()
: to a previous timestamp wouldn't work very well the relative er
On Mon, 28 Nov 2005, [iso-8859-1] Dag-Erling Sm?rgrav wrote:
Bruce Evans <[EMAIL PROTECTED]> writes:
I can see a use for making a timestamp after select() returns, not for
timeout purposes since the timeout should normally be for emergencies and
it's relative so it doesn't need the current time
In message: <[EMAIL PROTECTED]>
"Poul-Henning Kamp" <[EMAIL PROTECTED]> writes:
: This is a joint reply to all that has piled up in my mail-box on
: this topic while I was being Robert Watson at EuroBSDcon2005[1].
So what I want to know is where the little door to Robert Watson's
brain
This is a joint reply to all that has piled up in my mail-box on
this topic while I was being Robert Watson at EuroBSDcon2005[1].
First Bruce:
>(1) tc_windup() has no explicit locking, so it can run concurrently
> on any number of CPUs, with N-1 of the CPUs calling it via
> clock_settime
Bruce Evans <[EMAIL PROTECTED]> writes:
> I can see a use for making a timestamp after select() returns, not for
> timeout purposes since the timeout should normally be for emergencies and
> it's relative so it doesn't need the current time, but just to record when
> things happen.
IIRC, POSIX all
On Sunday 27 November 2005 08:35 am, Norikatsu Shigemura wrote:
> On Sun, 27 Nov 2005 13:23:00 + (GMT)
>
> Robert Watson <[EMAIL PROTECTED]> wrote:
> > > time(3) should use the environment variable too, since the fast version
> > > gives a value that is both imprecise and wrong. It inherits bu
On Mon, 28 Nov 2005, Bruce Evans wrote:
is something I'm quite willing to discuss, but the evidence seems to
suggest that if we want to improve the performance of this class of
applications, we need to provide time keeping services that match their
requirements (run frequently with fairly wea
On Sun, 27 Nov 2005, Robert Watson wrote:
On Sun, 27 Nov 2005, Bruce Evans wrote:
Add experimental low-precision clockid_t names corresponding to these
clocks, but implemented using cached timestamps in kernel rather than
a full time counter query.
These existence of these interfaces is a
On Sun, 27 Nov 2005, Norikatsu Shigemura wrote:
On Sun, 27 Nov 2005 13:23:00 + (GMT)
Robert Watson <[EMAIL PROTECTED]> wrote:
time(3) should use the environment variable too, since the fast version
gives a value that is both imprecise and wrong. It inherits bugs from
the kernel's time_sec
On Sun, 27 Nov 2005, Bruce Evans wrote:
Thus we get a small speedup at a cost of some complexity and large
inerface bloat.
This is partly because there are too many context switches and context
switches necessarily use a precise timestamp, and file timestamps are
under-represented since the
On Sun, 27 Nov 2005 13:23:00 + (GMT)
Robert Watson <[EMAIL PROTECTED]> wrote:
> > time(3) should use the environment variable too, since the fast version
> > gives a value that is both imprecise and wrong. It inherits bugs from
> > the kernel's time_second variable. time_second is not the c
On Mon, 28 Nov 2005, Bruce Evans wrote:
% /*
% * Small wrapper library to substitute implementations of gettimeofday(2)
and
% * time(3) with lower resolution variations. time(3) is unconditionally
% * degraded, since it will return a truncated time anyway. gettimeofday(3)
% * checks the
On Sun, 27 Nov 2005, Bruce Evans wrote:
Add experimental low-precision clockid_t names corresponding to these
clocks, but implemented using cached timestamps in kernel rather than
a full time counter query.
These existence of these interfaces is a mistake even in the kernel. On
all machine
On Sun, 27 Nov 2005, Robert Watson wrote:
... Attached is a small LD_PRELOAD library to
allow applications to be switched to the _FAST variants for gettimeofday().
% /*
% * Small wrapper library to substitute implementations of gettimeofday(2) and
% * time(3) with lower resolution variation
On Sun, 27 Nov 2005, Robert Watson wrote:
rwatson 2005-11-27 00:55:18 UTC
FreeBSD src repository
Modified files:
sys/sys time.h
sys/kern kern_time.c
Log:
Add several aliases for existing clockid_t names to indicate that the
application wishes to request
On Sun, 27 Nov 2005, Robert Watson wrote:
On Sun, 27 Nov 2005, Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Robert Watson
writes:
This offers a minimum update rate of 1/HZ,
but in practice will often be more frequent due to the frequency of
time stamping in the kernel:
Not
On Sun, 27 Nov 2005, Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Robert Watson writes:
This offers a minimum update rate of 1/HZ,
but in practice will often be more frequent due to the frequency of
time stamping in the kernel:
Not quite...
The precision is guaranteed to be
In message <[EMAIL PROTECTED]>, Robert Watson writes:
> This offers a minimum update rate of 1/HZ,
> but in practice will often be more frequent due to the frequency of
> time stamping in the kernel:
Not quite...
The precision is guaranteed to be no worse than 1msec, and is unlikely to
be sig
On Sun, 27 Nov 2005, Robert Watson wrote:
Add experimental low-precision clockid_t names corresponding to these
clocks, but implemented using cached timestamps in kernel rather than
a full time counter query. This offers a minimum update rate of 1/HZ,
but in practice will often be more fre
rwatson 2005-11-27 00:55:18 UTC
FreeBSD src repository
Modified files:
sys/sys time.h
sys/kern kern_time.c
Log:
Add several aliases for existing clockid_t names to indicate that the
application wishes to request high precision time stamps be return
29 matches
Mail list logo
