On Fri, 2 Mar 2001, Richard B. Johnson wrote:
> Note that two subsequent calls to gettimeofday() must not return the
> same time even if your CPU runs infinitely fast. I haven't seen any
> kernel in the past few years that fails this test.
i don't see any requirement for this in SuS.
> barn. You will need to request a getnanotimeofday() be created if you
> want to allow two consecutive calls to always return different values
> (modulo SMP systems and ~13 more years of Moore's Law)
Or you use rdtsc instructions for x86. There intel do guarantee that no two
rdtsc's execute in
barn. You will need to request a getnanotimeofday() be created if you
want to allow two consecutive calls to always return different values
(modulo SMP systems and ~13 more years of Moore's Law)
Or you use rdtsc instructions for x86. There intel do guarantee that no two
rdtsc's execute in
On Fri, 2 Mar 2001, Richard B. Johnson wrote:
Note that two subsequent calls to gettimeofday() must not return the
same time even if your CPU runs infinitely fast. I haven't seen any
kernel in the past few years that fails this test.
i don't see any requirement for this in SuS.
On Fri, 2 Mar 2001, Richard B. Johnson wrote:
> Yes and no. It takes microseconds to call the kernel for anything (time
> getpid() ), so it seldom loops. All the kernel has to do is remember
Hi,
c0109286 system_call +<22/40> (0.21) pid(4265)
c011c7e7 sys_gettimeofday +<13/a8> (0.27)
"Richard B. Johnson" wrote:
>
>I think it's a math problem in the test code. Try this:
>
[code deleted]
>
>Note that two subsequent calls to gettimeofday() must not return the
>same time even if your CPU runs infinitely fast. I haven't seen any
>kernel in the past few years that fails this
"Richard B. Johnson" wrote:
>
> On Fri, 2 Mar 2001, george anzinger wrote:
>
> > "Richard B. Johnson" wrote:
>
~snip~
> > > Note that two subsequent calls to gettimeofday() must not return the
> > > same time even if your CPU runs infinitely fast. I haven't seen any
> > > kernel in the past
On Fri, 2 Mar 2001, george anzinger wrote:
> "Richard B. Johnson" wrote:
> >
> > On Fri, 2 Mar 2001, Christopher Friesen wrote:
> >
> > > John Being wrote:
> > >
> > > > gives following result on box in question
> > > > root@**:# ./clo
> > > > Leap found: -1687 msec
> > > > and prints
"Richard B. Johnson" wrote:
>
> On Fri, 2 Mar 2001, Christopher Friesen wrote:
>
> > John Being wrote:
> >
> > > gives following result on box in question
> > > root@**:# ./clo
> > > Leap found: -1687 msec
> > > and prints nothing on all other my boxes.
> > > This gives me bunch of
On Fri, 2 Mar 2001, Christopher Friesen wrote:
> John Being wrote:
>
> > gives following result on box in question
> > root@**:# ./clo
> > Leap found: -1687 msec
> > and prints nothing on all other my boxes.
> > This gives me bunch of troubles with occasional hang ups and I found nothing
>
John Being wrote:
> gives following result on box in question
> root@**:# ./clo
> Leap found: -1687 msec
> and prints nothing on all other my boxes.
> This gives me bunch of troubles with occasional hang ups and I found nothing
> in kernel archives at
>
John Being wrote:
gives following result on box in question
root@**:# ./clo
Leap found: -1687 msec
and prints nothing on all other my boxes.
This gives me bunch of troubles with occasional hang ups and I found nothing
in kernel archives at
On Fri, 2 Mar 2001, Christopher Friesen wrote:
John Being wrote:
gives following result on box in question
root@**:# ./clo
Leap found: -1687 msec
and prints nothing on all other my boxes.
This gives me bunch of troubles with occasional hang ups and I found nothing
in kernel
"Richard B. Johnson" wrote:
On Fri, 2 Mar 2001, Christopher Friesen wrote:
John Being wrote:
gives following result on box in question
root@**:# ./clo
Leap found: -1687 msec
and prints nothing on all other my boxes.
This gives me bunch of troubles with occasional hang
On Fri, 2 Mar 2001, george anzinger wrote:
"Richard B. Johnson" wrote:
On Fri, 2 Mar 2001, Christopher Friesen wrote:
John Being wrote:
gives following result on box in question
root@**:# ./clo
Leap found: -1687 msec
and prints nothing on all other my boxes.
"Richard B. Johnson" wrote:
On Fri, 2 Mar 2001, george anzinger wrote:
"Richard B. Johnson" wrote:
~snip~
Note that two subsequent calls to gettimeofday() must not return the
same time even if your CPU runs infinitely fast. I haven't seen any
kernel in the past few years that
"Richard B. Johnson" wrote:
I think it's a math problem in the test code. Try this:
[code deleted]
Note that two subsequent calls to gettimeofday() must not return the
same time even if your CPU runs infinitely fast. I haven't seen any
kernel in the past few years that fails this test.
I
On Fri, 2 Mar 2001, Richard B. Johnson wrote:
Yes and no. It takes microseconds to call the kernel for anything (time
getpid() ), so it seldom loops. All the kernel has to do is remember
Hi,
c0109286 system_call +22/40 (0.21) pid(4265)
c011c7e7 sys_gettimeofday +13/a8 (0.27) pid(4265)
18 matches
Mail list logo
