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]

Yannick Loth <ya*****@loth.be> writes:

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark McIntyre]

On Thu, 07 Apr 2005 19:27:53 +0200, in comp.lang.c , Yannick Loth
<ya*****@loth.be> wrote:

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
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[SM Ryan]

Yannick Loth <ya*****@loth.be> wrote:
# 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.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
I hope it feels so good to be right. There's nothing more
exhilirating pointing out the shortcomings of others, is there?

[jacob navia]

Yannick Loth wrote:

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]

In article <42***********************@news.wanadoo.fr>,
jacob navia <ja***@jacob.remcomp.fr> wrote:

Yannick Loth wrote:

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

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?
--
"[...] it's all part of one's right to be publicly stupid." -- Dave Smey

[CBFalconer]

jacob navia wrote:

Yannick Loth wrote:

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?

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.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[jacob navia]

Walter Roberson wrote:

In article <42***********************@news.wanadoo.fr>,
jacob navia <ja***@jacob.remcomp.fr> wrote:

Yannick Loth wrote:

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

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?

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]

Walter Roberson wrote:

In article <42***********************@news.wanadoo.fr>,
jacob navia <ja***@jacob.remcomp.fr> wrote:

Yannick Loth wrote:

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

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'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.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Alex Fraser]

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:42***********************@news.wanadoo.fr...
[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]

On Sat, 09 Apr 2005 10:05:17 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

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.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[jacob navia]

Alex Fraser wrote:

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:42***********************@news.wanadoo.fr...
[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]

Mark McIntyre wrote:

On Sat, 09 Apr 2005 10:05:17 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

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.

Of course. Any operation will have this problem.

[Alex Fraser]

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:42**********************@news.wanadoo.fr...

Alex Fraser wrote:

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:42***********************@news.wanadoo.fr...
[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]

jacob navia <ja***@jacob.remcomp.fr> writes:

Alex Fraser wrote:

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:42***********************@news.wanadoo.fr...
[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?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark McIntyre]

On Sat, 09 Apr 2005 18:35:09 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

jacob navia <ja***@jacob.remcomp.fr> writes:

Alex Fraser wrote:

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message When doing an HLT operation the counter doesn't tick. Intel (explicitly) say otherwise.

Ahhh that's new to me.

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?
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Randy Howard]

In article <4j********************************@4ax.com>,
ma**********@spamcop.net says...

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. :-)

--
Randy Howard (2reply remove FOOBAR)
"Making it hard to do stupid things often makes it hard
to do smart ones too." -- Andrew Koenig

[jacob navia]

Mark McIntyre wrote:

On Sat, 09 Apr 2005 18:35:09 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

jacob navia <ja***@jacob.remcomp.fr> writes:

Alex Fraser wrote:

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
When doing an HLT operation the counter doesn't tick.
Intel (explicitly) say otherwise.
Ahhh that's new to me.

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?

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

[Mark McIntyre]

On Sun, 10 Apr 2005 11:47:08 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

Mark McIntyre wrote:

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.

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.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Richard Bos]

Mark McIntyre <ma**********@spamcop.net> wrote:

On Sat, 09 Apr 2005 18:35:09 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

jacob navia <ja***@jacob.remcomp.fr> writes:

Alex Fraser wrote:
Intel (explicitly) say otherwise.

Ahhh that's new to me.

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?

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

Richard

[Richard Bos]

jacob navia <ja***@jacob.remcomp.fr> wrote:

Walter Roberson wrote:

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?

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

Let me inform you then that, as a sysadmin, I'd prefer that you do not
recommend anyone to busy-wait on any multi-user system no matter how
cheap it looks to you; and that, if I find one of your programs doing
so, it'll be off the system in no time flat, and none of your other
programs will ever get near it from then on.

Richard

[Richard Bos]

jacob navia <ja***@jacob.remcomp.fr> wrote:

Yannick Loth wrote:

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

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

Fantastic. Not only is it off-topic and inaccurate, it doesn't actually
answer the question in a useful way. You're cute, jacob.

Richard

[Alan Balmer]

On Sat, 09 Apr 2005 08:31:06 +0200, jacob navia
<ja***@jacob.remcomp.fr> wrote:

Yannick Loth wrote:

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

You are in the wrong newsgroup. Furthermore, your answer is
incomplete, potentially misleading, and quite likely downright wrong.
The previous comments are about all that can be said in this group.
The OP should go to a more appropriate newsgroup - one for his
hardware/OS or perhaps comp.arch.embedded, where he will find people
who do this sort of thing for a living.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Christopher Benson-Manica]

Richard Bos <rl*@hoekstra-uitgeverij.nl> spoke thus:

Fantastic. Not only is it off-topic and inaccurate, it doesn't actually
answer the question in a useful way. You're cute, jacob.

I rather prefer the original:

"This is a wonderful answer. It's off-topic, it's incorrect, and it
doesn't answer the question."

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Randy Howard]

In article <d3**********@chessie.cirr.com>,
at***@nospam.cyberspace.org says...

Richard Bos <rl*@hoekstra-uitgeverij.nl> spoke thus:

Fantastic. Not only is it off-topic and inaccurate, it doesn't actually
answer the question in a useful way. You're cute, jacob.

I rather prefer the original:

"This is a wonderful answer. It's off-topic, it's incorrect, and it
doesn't answer the question."

Then credit it properly. Wasn't it Richard Heathfield that said
that? IIRC that is the case.

--
Randy Howard (2reply remove FOOBAR)
"Making it hard to do stupid things often makes it hard
to do smart ones too." -- Andrew Koenig

[Christopher Benson-Manica]

Randy Howard <ra*********@fooverizonbar.net> spoke thus:

Then credit it properly. Wasn't it Richard Heathfield that said
that? IIRC that is the case.

Yes; I figured it was well-known enough in these circles that an
attribution wasn't necessary. My apologies to Mr. Heathfield :-)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Mark McIntyre]

On Mon, 11 Apr 2005 07:41:10 GMT, in comp.lang.c ,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:

Mark McIntyre <ma**********@spamcop.net> wrote:

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.

Frankly, yes I was, as Jacob, though frequently bl**dy annoying in
CLC, strikes me as a fairly careful person who probably tries to do
the job properly.

I guess there's arcanity that we all don't know. Hands up who
remembers all the digraphs? no peeking now!
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[jacob navia]

Mark McIntyre wrote:

On Mon, 11 Apr 2005 07:41:10 GMT, in comp.lang.c ,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:

Mark McIntyre <ma**********@spamcop.net> wrote:

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.

Frankly, yes I was, as Jacob, though frequently bl**dy annoying in
CLC, strikes me as a fairly careful person who probably tries to do
the job properly.

I guess there's arcanity that we all don't know. Hands up who
remembers all the digraphs? no peeking now!

Well, the text of the documentation states that HLT does NOT change
RDTSC, it goes on ticking.

OK;

But in the next sentence, the doc goes on to say that if the deep sleep
pin is asserted, RDTSC will not tick any more.

I stored wrongly in my head that the HLT instruction makes the timer
stop, instead of remembering that the deep sleep pin makes it stop.

The docs go for several thousand pages. I can't have all the details in
my mind.

Sorry for this error.

jacob

[CBFalconer]

jacob navia wrote:

.... snip ...
Well, the text of the documentation states that HLT does NOT change
RDTSC, it goes on ticking.

But in the next sentence, the doc goes on to say that if the deep
sleep pin is asserted, RDTSC will not tick any more.

I stored wrongly in my head that the HLT instruction makes the timer
stop, instead of remembering that the deep sleep pin makes it stop.

The docs go for several thousand pages. I can't have all the details
in my mind.

Sorry for this error.

But it is still OT for c.l.c, and the subject should never have
arisen. I see no mention of RDTSC, HLT, deep sleep, or even pins
in the C standard, which is the only documentation of interest
here.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson