SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Tue, 12 Sep 2006 20:50:32 -0700
From:	Peter Skye <pskye@peterskye.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: Ouch! SysSleep(), NTP, cpu clock

Content Type: text/plain

Steven Levine wrote:
>
> Keep in mind that SysSleep() might wake you up late even if
> there was not a clock frequency offset. Higher priority threads might
> delay when your thread finally gets to run. It might not matter for your
> application, but it's good to plan for this.

Correct.

> >I need some insight into how SysSleep() actually
>
> You have the Toolkit.

I do?

> Look at the RexxUtil source. SysSleep() is a thin
> wrapper around DosSleep(). It's so thin, here's the code
> ...
> DosSleep(secs *1000);

> . . . os_ntpd is . . . also an excellent example of how PLLs
> don't handle step changes like daylight savings time very well. :-)

Tell me about it. I've gone through contortions trying to get through
daylight saving boundaries without manual intervention. Right now I'm
using killem (or somesuch) to kill os2ntpd just before the boundary,
then reset the RTC using NTP just after the boundary (and some of the
NTP servers don't behave at this moment), then restarting os2ntpd. Oh
yeah, you have to zap the os2ntpd error_offset file so it doesn't know
there's been a major clock change. If only the OS/2 internals ran on
Universal time with appropriate offsets as necessary.

> As you suspect,
> what you need to do is wrap the sleep in a loop. You are a better
> mathematician than I am, so I'll let you do the math to figure out exactly
> how long you can sleep and still wake up with sufficient accuracy.

That one's easy. If your clock error is x% then you can only sleep
(100-x)%. I picked the half-way point because it's easy to visualize
the methodology, but 90% or even 99% is sure to work (just don't try
99.999%).

> >I have a radio-broadcast-over-internet project I'm
> >working on and it requires 1/2 second resolution.
>
> Resolution or accuracy? You may have problem guaranteeing this kind of
> accuracy with a REXX app if there are any other processes active.

Actually, both in different parts of the systems. For each hour I'm
counting the number of data points in the transmission to make sure I'm
transmitting exactly one hour of audio.

As a side comment, remember how Jerry Rash was complaining a while back
that his video captures would all of a sudden dump, or the Z! audio
complaints that audio-over-internet would suddenly die? I can't speak
for every instance of this but when the transmitting clock is slightly
different from the receiving clock you'll get a buffer underrun or
overrun causing a major whammy in your received data stream. Suppose
you have 100 radio listeners; the ones whose audio card clocks are
closest to the server's audio clock frequency will "stay on the
broadcast" the longest, while those with larger errors will suffer the
buffer under/over-run condition sooner.

> Of course, since SysSleep() is limited to a 1 second resolution

Hmm. Your code snippet shows that SysSleep() doesn't support partial
seconds but I just retested my software and SysSleep() will accept a
fractional portion of a second (i.e. SysSleep(1.5)) _and_ will sleep for
partial seconds.

Here's my test, using my waitsec.cmd which uses SysSleep():

[G:\]waitsec 1 & waitsec 1 & waitsec 1 & waitsec 1 & waitsec 1
[G:\]waitsec 1.5 & waitsec 1.5 & waitsec 1.5 & waitsec 1.5 & waitsec 1.5
[G:\]waitsec 2 & waitsec 2 & waitsec 2 & waitsec 2 & waitsec 2

The three command lines took 5 seconds, 7.5 seconds and 10 seconds to
execute.

Here is the relevant code from my waitsec.cmd:

parse arg Seconds Options
...
call SysSleep Seconds

Hmm. Your toolkit and my SysSleep() don't seem to match.

- Peter

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"postmaster@scoug.com".

=====================================================

Return to [ 12 | September | 2006 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.