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/