sleeping during a precise time interval

[Yannick Loth]

Hello
I'm writing a program which needs to pause exactly some microseconds then go
ahead.
I'v tried the nanosleep() function but this is not much precise. I also
tried it with raising the priority of my application, but it still isn't
precise enough.
What maximum precision can I hope to obtain on a linux station?
Would someone have a suggestion on the implementation?
Thanks
Yannick

 

[Keith Thompson]

Hello
I'm writing a program which needs to pause exactly some microseconds then go
ahead.
I'v tried the nanosleep() function but this is not much precise. I also
tried it with raising the priority of my application, but it still isn't
precise enough.
What maximum precision can I hope to obtain on a linux station?

There's no way to do what you want in standard C without extensions.
Try comp.unix.programmer or one of the Linux newsgroups.

 

[Mark McIntyre]

Hello
I'm writing a program which needs to pause exactly some microseconds then go
ahead.

this is impossible in standard C, and quite probably impossible on
anything except dedicated hardware.

I'v tried the nanosleep() function but this is not much precise. I also
tried it with raising the priority of my application, but it still isn't
precise enough.

you'll need to ask this question in a linux / unix programming group,
and bear in mind its hardware-specific

 

[SM Ryan]

# Hello
# I'm writing a program which needs to pause exactly some microseconds then go
# ahead.
# I'v tried the nanosleep() function but this is not much precise. I also
# tried it with raising the priority of my application, but it still isn't
# precise enough.
# What maximum precision can I hope to obtain on a linux station?
# Would someone have a suggestion on the implementation?
# Thanks

You're going to need some kind of real-time operating system. Those make promises
about responses within specific time bounds. Most operating systems guarentee only
that you will wait at least that long, but could wait much longer.

 

[jacob navia]

Hello
I'm writing a program which needs to pause exactly some microseconds then go
ahead.
I'v tried the nanosleep() function but this is not much precise. I also
tried it with raising the priority of my application, but it still isn't
precise enough.
What maximum precision can I hope to obtain on a linux station?
Would someone have a suggestion on the implementation?
Thanks
Yannick

The best way is to use the time stamp counter register in the CPU
if you are running an intel-compatible machine

The instruction RDTSC will leave in EAX:EDX a 64 bit counter
that gets incremented at each cycle. With a 2GHZ processor that
is quite accurate.

CAVEATS:
When doing an HLT operation the counter doesn't tick.
The counter will get incremented by all process, and it goes
on running even if your process is preempted by the linux OS.

C Interface:

extern long long Rdtsc(void);

Asm implementation
.text
Rdtsc:
rdtsc
ret
.globl Rdtsc

jacob

 

[Walter Roberson]

Yannick Loth wrote:

The best way is to use the time stamp counter register in the CPU
if you are running an intel-compatible machine

The instruction RDTSC will leave in EAX:EDX a 64 bit counter
that gets incremented at each cycle. With a 2GHZ processor that
is quite accurate.

Jacob, your description left me unclear as to how Yannick would
write a program that paused "exatly some microseconds then go ahead".
Your description was of a mechanism to get the value of a
high-precision counter, but not of how to wait for a high-precision
time.

Is the implication that Yannick should impliment a busy-wait loop, just
cycling over and over again asking for the counter until finally the
counter meets or exceeds the desired offset time? With there being no
implied mechanism for requesting that the program be given particular
attention when the time has expired, so that if the processor is off
servicing another process that Yannick should be content with finding
out the counter value at the first spare time that the processor has to
get back for the busy-loop after the time expires?

 

[CBFalconer]

The best way is to use the time stamp counter register in the CPU
if you are running an intel-compatible machine

The instruction RDTSC will leave in EAX:EDX a 64 bit counter
that gets incremented at each cycle. With a 2GHZ processor that
is quite accurate.

I believe this attitude is why the LCC-Win system stopped working
on '486s a few years ago, and why Jacob seems unable to find the
cause. Those machines don't have such an instruction. Any such
use should be carefully guarded by code that detects the underlying
CPU. In addition busy-waiting is usually considered poor practice.

Besides which all such hardware specific discussion is miles OT on
this newsgroup. The OP should realize that there is no C answer to
his problem.

 

[jacob navia]

Jacob, your description left me unclear as to how Yannick would
write a program that paused "exatly some microseconds then go ahead".
Your description was of a mechanism to get the value of a
high-precision counter, but not of how to wait for a high-precision
time.

Is the implication that Yannick should impliment a busy-wait loop, just
cycling over and over again asking for the counter until finally the
counter meets or exceeds the desired offset time? With there being no
implied mechanism for requesting that the program be given particular
attention when the time has expired, so that if the processor is off
servicing another process that Yannick should be content with finding
out the counter value at the first spare time that the processor has to
get back for the busy-loop after the time expires?

A busy loop of a few microseconds doesn't look very expensive in CPU
time to me...

Yes, you are right, the whole thing should be something like:

long long wait,start;

start = rdtsc();
wait = MY_WAIT_TIME; // microseconds in rdtsc ticks
while (rdtsc() < (start+wait)) {
// do something stupid fast
start++;
start--;
}

NOTE:

The correspondence between the CPU counter and effective
time will be different for a 1GHZ processor to a 2GHZ
processor of course. The time should be calibrated elsewhere.

jacob

 

[Flash Gordon]

I'm not sure that will work on an 80486, and I'm certain it won't on an
8088. So you need to be rather more specific. You also need to redirect
such things to an appropriate group where the experts can check your
answers.

Jacob, your description left me unclear as to how Yannick would
write a program that paused "exatly some microseconds then go ahead".
Your description was of a mechanism to get the value of a
high-precision counter, but not of how to wait for a high-precision
time.

<snip>

His description also assumes that the process does not get bumped to a
different processor and that no other process and no part of the OS (or
device driver) uses the HLT instruction, and I can't see how he can know
this.

The OP did not even specify that it was intel compatible HW. I'm happily
running Linux on an Apple iMac.

Jacob seems to like giving off topic answers which may or may not be
accurate.

 

[Alex Fraser]

[snip]

The best way is to use the time stamp counter register in the CPU
if you are running an intel-compatible machine [snip]
When doing an HLT operation the counter doesn't tick.

Intel (explicitly) say otherwise.

Alex

 

[Mark McIntyre]

A busy loop of a few microseconds doesn't look very expensive in CPU
time to me...

main problem is that in any modern general purpose OS, you still can't
guarantee to wait the right amount of time. Between one cycle and the
next, the OS may have context-switched to some other app with higher
priority, and when you come back in, its too late.

 

[jacob navia]

[snip]

The best way is to use the time stamp counter register in the CPU
if you are running an intel-compatible machine
[snip]

When doing an HLT operation the counter doesn't tick.

Intel (explicitly) say otherwise.

Alex

Ahhh that's new to me. As far as I understood it the HLT
instruction puts the processor in sleep mode. Can you give
me a reference for this?

Thanks

 

[jacob navia]

main problem is that in any modern general purpose OS, you still can't
guarantee to wait the right amount of time. Between one cycle and the
next, the OS may have context-switched to some other app with higher
priority, and when you come back in, its too late.

Of course. Any operation will have this problem.

 

[Alex Fraser]

[snip]

The best way is to use the time stamp counter register in the CPU
if you are running an intel-compatible machine [snip]
When doing an HLT operation the counter doesn't tick.

Intel (explicitly) say otherwise.

Ahhh that's new to me. As far as I understood it the HLT
instruction puts the processor in sleep mode. Can you give
me a reference for this?

IA-32 Architecture Software Developer's Manual, volume 3
<ftp://download.intel.com/design/Pentium4/manuals/25366814.pdf>
Section 15.8 (p530): "Following reset, the counter is incremented every
processor clock cycle, even when the processor is halted by the HLT
instruction or the external STPCLK# pin."

Alex

 

[Keith Thompson]

[snip]

The best way is to use the time stamp counter register in the CPU
if you are running an intel-compatible machine [snip]

When doing an HLT operation the counter doesn't tick.

Intel (explicitly) say otherwise.
Alex

Ahhh that's new to me. As far as I understood it the HLT
instruction puts the processor in sleep mode. Can you give
me a reference for this?

Can you take this to a newsgroup where it's topical? Please?

 

[Mark McIntyre]

Can you take this to a newsgroup where it's topical? Please?

Is it only me that finds it slightly concerning that a compiler
implementor doesn't know where to find the specs of the chip being
supported?

 

[Randy Howard]

Is it only me that finds it slightly concerning that a compiler
implementor doesn't know where to find the specs of the chip being
supported?

I was thinking the same thing, but was going to let it slide.

 

[jacob navia]

Is it only me that finds it slightly concerning that a compiler
implementor doesn't know where to find the specs of the chip being
supported?

Better not use his compiler, it can't be anything else
than a shit.

 

[Mark McIntyre]

Better not use his compiler, it can't be anything else
than a shit.

I didn't say that, I was just quite worried that someone writing a
compiler wasn't familiar with the operation of the target hardware.
Perhaps its a piece of arcane knowledge that its not necessary to
know.

 

[Richard Bos]

Is it only me that finds it slightly concerning that a compiler
implementor doesn't know where to find the specs of the chip being
supported?

Were you surprised at all, then? This is normal for that particular
compiler suite.

Richard