> In message <[EMAIL PROTECTED]> "Louis A. Mamakos" writes:
> : One a related, timekeeping note: is there any interest in updating or
> : extending the SO_TIMESTAMP socket option to return higher resolution
> : timestamps? Currently, it returns a struct timeval.
>
> I think that's a great ide
In message <[EMAIL PROTECTED]> "Louis A. Mamakos" writes:
: One a related, timekeeping note: is there any interest in updating or
: extending the SO_TIMESTAMP socket option to return higher resolution
: timestamps? Currently, it returns a struct timeval.
I think that's a great idea. Somethin
In message <[EMAIL PROTECTED]>, Warner Losh writes:
>We found at Timing Solutions when we were trying to measure interrupt
>latency that the system time (getnanotime()) gave us measurements with
>a larger variance than our expensive scopes that does statistical
>gathering.
Uhm, you should have u
One a related, timekeeping note: is there any interest in updating or
extending the SO_TIMESTAMP socket option to return higher resolution
timestamps? Currently, it returns a struct timeval.
I did a quick survey, and it appears that there are applications which
use this facility (though, sur
I did some experiments a few years ago with a FreeBSD 3.x system to
try to measure interrupt latency (and latency jitter). The platform
was a 233MHz Pentium, and I had a PCI board which implemented a
high resolution timer (to 100ns resolution). The PCI board could
be programmed to generate an i
In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: >We found at Timing Solutions when we were trying to measure interrupt
: >latency that the system time (getnanotime()) gave us measurements with
: >a larger variance than our expensive scopes that does statistical
: >gathering.
:
: Uhm, y
6 matches
Mail list logo