Re: Anyone else interested in a high-precision monotonic counter?

[Manfred Bartz]

"Christopher Friesen" <[EMAIL PROTECTED]> wrote:

> Manfred Bartz wrote:
> 
> > Why a new system call?
> Well, you'd be accessing a different kernel variable--"ytime" instead of
> "xtime". This new variable wouldn't be adjusted when the  system
> time/date was, it would start at zero and always increase. 

> > have you looked at the return-value of times(2)
> > Or roll your own using setitimer(2)
> 
> Both of these are precise only to jiffies, which defaults at 10
> milliseconds on x86 and PPC.  If you want microsecond timing, the only
> current standard way to do it is to use gettimeofday(), which is
> sensitive to changes in system date and time.

Ok.  A monotonic, high resolution timer would be useful.

Maybe one should then push for a full implementation of xtime
including TIME_MONOTONIC and TIME_TAI?




-- 
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Anyone else interested in a high-precision monotonic counter?

[Manfred Bartz]

"Christopher Friesen" [EMAIL PROTECTED] wrote:

 Manfred Bartz wrote:
 
  Why a new system call?
 Well, you'd be accessing a different kernel variable--"ytime" instead of
 "xtime". This new variable wouldn't be adjusted when the  system
 time/date was, it would start at zero and always increase. 

  have you looked at the return-value of times(2)
  Or roll your own using setitimer(2)
 
 Both of these are precise only to jiffies, which defaults at 10
 milliseconds on x86 and PPC.  If you want microsecond timing, the only
 current standard way to do it is to use gettimeofday(), which is
 sensitive to changes in system date and time.

Ok.  A monotonic, high resolution timer would be useful.

Maybe one should then push for a full implementation of xtime
including TIME_MONOTONIC and TIME_TAI?

http://www.cl.cam.ac.uk/~mgk25/c-time/
http://cr.yp.to/time.html

-- 
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Anyone else interested in a high-precision monotonic counter?

[Christopher Friesen]

Manfred Bartz wrote:

> Why a new system call?
Well, you'd be accessing a different kernel variable--"ytime" instead of
"xtime". This new variable wouldn't be adjusted when the  system
time/date was, it would start at zero and always increase. 
 
> regarding a:  it could have microsecond resolution but not
>   microseconds accuracy.

On PPC and x86 systems, gettimeofday() is both accurate and precise to
microseconds, since it is based off of jiffies and then offset to get
microseconds.


> regarding b:  have you looked at the return-value of times(2)
>   Or roll your own using setitimer(2)

Both of these are precise only to jiffies, which defaults at 10
milliseconds on x86 and PPC.  If you want microsecond timing, the only
current standard way to do it is to use gettimeofday(), which is
sensitive to changes in system date and time.




-- 
Chris Friesen| MailStop: 043/33/F10  
Nortel Networks  | work: (613) 765-0557
3500 Carling Avenue  | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada| email: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Anyone else interested in a high-precision monotonic counter?

[Christopher Friesen]

Manfred Bartz wrote:

 Why a new system call?
Well, you'd be accessing a different kernel variable--"ytime" instead of
"xtime". This new variable wouldn't be adjusted when the  system
time/date was, it would start at zero and always increase. 
 
 regarding a:  it could have microsecond resolution but not
   microseconds accuracy.

On PPC and x86 systems, gettimeofday() is both accurate and precise to
microseconds, since it is based off of jiffies and then offset to get
microseconds.


 regarding b:  have you looked at the return-value of times(2)
   Or roll your own using setitimer(2)

Both of these are precise only to jiffies, which defaults at 10
milliseconds on x86 and PPC.  If you want microsecond timing, the only
current standard way to do it is to use gettimeofday(), which is
sensitive to changes in system date and time.




-- 
Chris Friesen| MailStop: 043/33/F10  
Nortel Networks  | work: (613) 765-0557
3500 Carling Avenue  | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada| email: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Anyone else interested in a high-precision monotonic counter?

[Manfred Bartz]

"Christopher Friesen" <[EMAIL PROTECTED]> writes:

> Has anyone ever considered including a microsecond-precision
> monotonically-increasing counter in the kernel?  This would allow for
> easy timing of alarms and such by using absolute values of when the
> alarm should expire rather than a list of deltas from previous alarms.
> 
> The thing I have in mind would store a value something like "xtime"
> (maybe call it "ytime"?) in the kernel.  This value would be initialized
> to zero on startup, and would be incremented at the same time as
> "xtime".  However, while "xtime" reflects adjustments to the actual
> system time (settimeofday(), date, ntp, etc.), this value would not. 
> Finally, it would be accessed with a system call essentially identical
> to sys_gettimeofday(), only it would access "ytime" instead of "xtime"
> before going down and getting the microseconds from the RTC.
> 
> This doesn't seem to me as though it would be all that tricky to add,
> and I could see it being very useful in providing a timing source that
> is guaranteed to 
> a) be accurate to microseconds and 
> b) never go backwards.

Why a new system call?  

regarding a:  it could have microsecond resolution but not
  microseconds accuracy.
regarding b:  have you looked at the return-value of times(2)
  Or roll your own using setitimer(2)
-- 
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Anyone else interested in a high-precision monotonic counter?

[Christopher Friesen]

Has anyone ever considered including a microsecond-precision
monotonically-increasing counter in the kernel?  This would allow for
easy timing of alarms and such by using absolute values of when the
alarm should expire rather than a list of deltas from previous alarms.

The thing I have in mind would store a value something like "xtime"
(maybe call it "ytime"?) in the kernel.  This value would be initialized
to zero on startup, and would be incremented at the same time as
"xtime".  However, while "xtime" reflects adjustments to the actual
system time (settimeofday(), date, ntp, etc.), this value would not. 
Finally, it would be accessed with a system call essentially identical
to sys_gettimeofday(), only it would access "ytime" instead of "xtime"
before going down and getting the microseconds from the RTC.

This doesn't seem to me as though it would be all that tricky to add,
and I could see it being very useful in providing a timing source that
is guaranteed to a) be accurate to microseconds and b) never go
backwards.


Chris

-- 
Chris Friesen| MailStop: 043/33/F10  
Nortel Networks  | work: (613) 765-0557
3500 Carling Avenue  | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada| email: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Anyone else interested in a high-precision monotonic counter?

[Christopher Friesen]

Has anyone ever considered including a microsecond-precision
monotonically-increasing counter in the kernel?  This would allow for
easy timing of alarms and such by using absolute values of when the
alarm should expire rather than a list of deltas from previous alarms.

The thing I have in mind would store a value something like "xtime"
(maybe call it "ytime"?) in the kernel.  This value would be initialized
to zero on startup, and would be incremented at the same time as
"xtime".  However, while "xtime" reflects adjustments to the actual
system time (settimeofday(), date, ntp, etc.), this value would not. 
Finally, it would be accessed with a system call essentially identical
to sys_gettimeofday(), only it would access "ytime" instead of "xtime"
before going down and getting the microseconds from the RTC.

This doesn't seem to me as though it would be all that tricky to add,
and I could see it being very useful in providing a timing source that
is guaranteed to a) be accurate to microseconds and b) never go
backwards.


Chris

-- 
Chris Friesen| MailStop: 043/33/F10  
Nortel Networks  | work: (613) 765-0557
3500 Carling Avenue  | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada| email: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Anyone else interested in a high-precision monotonic counter?

[Manfred Bartz]

"Christopher Friesen" [EMAIL PROTECTED] writes:

 Has anyone ever considered including a microsecond-precision
 monotonically-increasing counter in the kernel?  This would allow for
 easy timing of alarms and such by using absolute values of when the
 alarm should expire rather than a list of deltas from previous alarms.
 
 The thing I have in mind would store a value something like "xtime"
 (maybe call it "ytime"?) in the kernel.  This value would be initialized
 to zero on startup, and would be incremented at the same time as
 "xtime".  However, while "xtime" reflects adjustments to the actual
 system time (settimeofday(), date, ntp, etc.), this value would not. 
 Finally, it would be accessed with a system call essentially identical
 to sys_gettimeofday(), only it would access "ytime" instead of "xtime"
 before going down and getting the microseconds from the RTC.
 
 This doesn't seem to me as though it would be all that tricky to add,
 and I could see it being very useful in providing a timing source that
 is guaranteed to 
 a) be accurate to microseconds and 
 b) never go backwards.

Why a new system call?  

regarding a:  it could have microsecond resolution but not
  microseconds accuracy.
regarding b:  have you looked at the return-value of times(2)
  Or roll your own using setitimer(2)
-- 
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/