Precise timing isn't the issue, Steve. WinWarbler originally used
GetTickCount() and QueryPerformanceCounter() in its CW generation
code, but a high-resolution timer using the multimedia library is
sufficiently accurate and more convenient. The problem is thread
scheduling. WinWarbler uses SetPriorityClass to establish
REALTIME_PRIORITY_CLASS and SetThreadPriority to establish
THREAD_PRIORITY_TIME_CRITICAL . Nonetheless, there are many CPU-
consumptive events that Windows insists on handling at higher
priority -- such as displaying and moving the Task Manager window.
Spin locks are not an acceptable solution IMHO; the user would find
it disconcerting if the mouse pointer stopped following mouse
movements during CW generation or Pactor-3 operation, for example.
Yes, one could dedicate a headless Windows PC to executing one
application like Pactor-3, but what would be the point? Even the most
expensive Pactor-3 TNC would be cheaper and more compact to boot.
I didn't comment on the feasibility of implementing AMTOR on Windows;
Pactor-2 and Pactor-3 were the protocols I mentioned.
>From my days as a CPU architect and designer, I have lots of
experience with real-time operating systems and applications -- but
WinWarbler was my first encounter with extracting real-time
performance from Windows. Any suggestions or pointers you have in
this area would be appreciated.
73,
Dvae, AA6YQ
--- In digitalradio@yahoogroups.com, Steve Hajducek <[EMAIL PROTECTED]>
wrote:
>
>
> GM Dave,
>
> Yes, a technical item up for discussion.
>
> I must assume that you have never done any Near Real Time Systems
> development such as ATE or Industrial Control applications under MS-
Windows?
>
> I on the other hand have and the WIN32 API beginning all the way
back
> with Windows NT implemented a number of functions for embedded
> applications with critical timing requirements.
>
> For example you have the GetTickCount() API call which has a
> resolution of 10ms and the QueryPerformanceCounter() which returns
> the resolution of a high-resolution performance counter to 0.8
> microseconds and then there are Spinlocks to synchronize timing
> events during an interrupt response or other similar activity,
> together with Process Priority and Asynchronous I/O and some other
> functions you can achieve nanosecond accuracy and make your
> application own the operating system to prevent other system
> processes from interfering with your critical timing needs.
>
> It is my opinion that ARQ protocols such as AMTOR and others with
> their short ACK/NAK can implemented under MS-Windows 2000
> Professional and above taking the above approach.
>
> /s/ Steve, N2CKH/AAR2EY
>
>
> At 10:23 PM 8/27/2006, you wrote:
> >The issue is control over the operating system's scheduling
> >decisions. There are real-time versions of Linux that are
comparable
> >in this dimension to the firmware running in a TNC; given
sufficient
> >CPU horsepower, a Pactor-2 or Pactor-3 implementation on realtime
> >Linux is feasible.
> >
> >The Windows scheduler cannot be adequately controlled for use
timing-
> >critical applications; as a result, the response time requirements
of
> >protocols like Pactor-2 and Pactor-3 cannot be guaranteed, no
matter
> >how fast the CPU. Generating CW with consistent timing is a
challenge
> >on this platform.
> >
> > 73,
> >
> > Dave, AA6YQ
>
Need a Digital mode QSO? Connect to Telnet://cluster.dynalias.org
Other areas of interest:
The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol (band plan policy discussion)
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/digitalradio/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
