said:
Hi,
>running at its slightly-fast speed so it will reach the equivalent of
>3:00:00 _before_ the RTC does (since the RTC is being slowed down).
>That's apparently why I "wake up" too soon -- and if my cpu clock ran
>slow instead of fast then I would wake up a little late instead of a
>little early.
Exactly. 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.
>I don't know if cron and other timer programs have a similar problem, I
>haven't tested them.
If they use the same logic, they will have the same problem to a degree
proportional to the average sleep duration.
>I do need to do further testing with OS2NTPD turned off, to see if I then
>"wake up" on time. But I need some insight into how SysSleep() actually
>works so I can design the tests.
You have the Toolkit. Look at the RexxUtil source. SysSleep() is a thin
wrapper around DosSleep(). It's so thin, here's the code
ULONG SysSleep(PUCHAR name, ULONG numargs, RXSTRING args[],
PSZ queuename, RXSTRING *retstr)
{
LONG secs; /* Time to sleep in secs */
if (numargs != 1) /* Must have one argument */
return INVALID_ROUTINE;
/* get number of seconds */
if (!string2long(args[0].strptr, &secs) || secs < 0)
return INVALID_ROUTINE; /* raise error if bad */
DosSleep(secs *1000);
BUILDRXSTRING(retstr, NO_UTIL_ERROR);
return VALID_ROUTINE;
}
This means that Nathan's suggestion is somewhat moot.
Nathan, os2_ntpd is using the same clock sources as your app, so the
results will be the same. os_ntpd is sorta cute because it wraps the
clock adjustments in a PLL. It is also an excellent example of how PLLs
don't handle step changes like daylight savings time very well. :-) It's
also an excellent example of why function keys are not a good user
interface when the rest of the keyboard is avilable for use.
>Question #2: Does anybody have a workaround for the situation where the
>cpu clock isn't exact and an NTP program is occasionally resetting the
>RTC clock? I'd like to test any workarounds.
Your problem is a measurement problem. Remember Nyquist. 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.
>Question #3: Has this problem surfaced on other platforms, such as *nix
>or Windows?
It happens on every system, although I don't consider it a problem so much
as a design error when it causes application problems.
>Somebody is probably going to ask, "Why do you care?" I have a
>radio-broadcast-over-internet project I'm working on and it requires 1/2
>second resolution. Waking up too early or too late is a problem.
Resolution or accuracy? You may have problem guaranteeing this kind of
accuracy with a REXX app if there are any other processes active.
>(One possible workaround: SysSleep() for half the desired time, then
>recalculate the remaining sleep time based on the current RTC value and
>repeat until the desired clock time is reached.)
This will solve your measurement problem. You can probably put a lower
bound of something like 15 minutes on the sleep time and still meet your
1/2 second requirement.
Of course, since SysSleep() is limited to a 1 second resolution, you will
need to find a REXX DLL that provides a more direct interface to DosSleep
if you really need 1/2 second accuracy. It's either that or hog the CPU
and poll the clock for the last 2 seconds or so.
Steven
--
----------------------------------------------------------------------
"Steven Levine" MR2/ICE 2.67 #10183 Warp/eCS/DIY/14.103a_W4
www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
----------------------------------------------------------------------
=====================================================
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".
=====================================================
<< Previous Message <<
>> Next Message >>
Return to [ 12 |
September |
2006 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
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.
