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
for help.
>From: Manfred Spraul <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>CC: [EMAIL PROTECTED]
>Subject: Re: strange nonmonotonic behavior of gettimeoftheday
>Date: Fri, 02 Mar 2001 18:06:05 +0100
>
> >
> > on AMD K6, VIA Technologies VT 82C586, Compaq Presario X
"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 AMD K6, VIA Technologies VT 82C586, Compaq Presario XL119.
> [snip]
> gives following result on box in question
> root@**:# ./clo
> Leap found: -1687 msec
> and prints nothing on all other my boxes.
Perhaps APM or SMI problems?
Could you run the attached program?
--
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:
>
> I've got following problem with 2.2.17 (Redhat stock kernel)
> Linux * 2.2.17-14 #1 Mon Feb 5 14:57:25 EST 2001 i586 unknown
> on AMD K6, VIA Technologies VT 82C586, Compaq Presario XL119.
> Following C program
> #include
> #include
> #include
> #include
> #define
John Being wrote:
I've got following problem with 2.2.17 (Redhat stock kernel)
Linux * 2.2.17-14 #1 Mon Feb 5 14:57:25 EST 2001 i586 unknown
on AMD K6, VIA Technologies VT 82C586, Compaq Presario XL119.
Following C program
#include stdio.h
#include sys/time.h
#include unistd.h
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
for help.
From: Manfred Spraul [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: strange nonmonotonic behavior of gettimeoftheday
Date: Fri, 02 Mar 2001 18:06:05 +0100
on AMD K6, VIA Technologies VT 82C586, Compaq Presario XL119.
[snip]
gives following result on box
"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)
I've got following problem with 2.2.17 (Redhat stock kernel)
Linux * 2.2.17-14 #1 Mon Feb 5 14:57:25 EST 2001 i586 unknown
on AMD K6, VIA Technologies VT 82C586, Compaq Presario XL119.
Following C program
#include
#include
#include
#include
#define ABS(x) (x < 0 ? -x : x)
#define TIME_T
I've got following problem with 2.2.17 (Redhat stock kernel)
Linux * 2.2.17-14 #1 Mon Feb 5 14:57:25 EST 2001 i586 unknown
on AMD K6, VIA Technologies VT 82C586, Compaq Presario XL119.
Following C program
#include stdio.h
#include sys/time.h
#include unistd.h
#include time.h
#define ABS(x)
25 matches
Mail list logo
