Re: [digitalradio] Re: Timing requirements of digital ARQ
Hello Rick, An additive remark to Dave. In Multispk, I have added Pactor 1 (RX/TX) but only in FEC. I would have liked to propose an ARQ Pactor1 but it is impossible. A bit in Pactor1 lasts 10 ms or 5 ms (200 bauds). This obliges to have a precision of at least 2 ms, which would be easy under DOS but impossible under Windows as you don't have a "sample after sample" input as under DOS, but buffers of datas. You can reduce the buffers length, perhaps down to an equivalent of 50 ms, on powerful PC but not less...so FEC (i.e asynchronous exchange of datas as in Pactor 1 FEC or in Pax) is the only solution. 73 Patrick - Original Message - From: Dave Bernstein To: digitalradio@yahoogroups.com Sent: Monday, August 28, 2006 6:35 PM Subject: [digitalradio] Re: Timing requirements of digital ARQ To use your example, Rick, if Windows introduces a 10 ms delay from the time when you strike a button to initiate transmission in MultiPSK until the point where Commander sends a CI-V "Transmit!" command to your 756 Pro2, you'd never notice. However, such a delay in confirming reception of a Pactor-3 packet would break the protocol. The SCS PTC-II Pro, which supports both Pactor-2 and Pactor-3, utilizes a Motorola (now Freescale) 68360 clocked at 25 MHz and a 56303 24-bit DSP clocked at 100 MHz; see http://www.globalmarinenet.net/ptc.htm The 68360 is a descendant of the venerable 68000; its probably being used for administrative tasks like running the serial port and command line interface. The 56303 DSP does the heavy lifting. While its DSP instruction set is advantageous, its performance is modest by current standards; see http://www.bdti.com/articles/benchmark_icspat99.pdf#search=%22dsp% 20benchmarks%22 I am unable to locate a benchmark comparing the performance of dedicated DSP chips like the 56303 DSP with general purpose microprocessors, but I suspect that a 1 GHz Pentium could handle the processing load. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, KV9U <[EMAIL PROTECTED]> wrote: > > Since I am not a programmer, other than taking some rudimentary courses, > reading some of Don Lancaster's books, and knowing that it is not > something I could ever do very well, something still doesn't seem right > to me when it comes to the claim that computers just can not meet the > timing requirements of ARQ digital modes. > > When I use the computer to key my ICOM 756 Pro 2 with Dave's DX Lab > Commander software in order to run other programs that interface with > Commander (such as Multipsk which is my main digital sound card > program), it does not seem to have much latency at all. And if one could > key relatively slow CW as is done with the software for the SDR1000, why > would that not be almost a magnitude faster than you would need for > adequate ARQ switching speed? > > How many ms do you need? > > Rick, KN6KB, the inventor of SCAMP, has said that the power in the > typical Windows OS computer we use is something like a magnitude less > than that available in the dedicated SCS modems and that is why they > perform so well compared to a computer (for the dedicated part). I > wonder where the dividing line will come so that computers will at least > match the SCS type units? > > 73, > > Rick, KV9U > > > Dave Bernstein 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 > > > > > > > [Non-text portions of this message have been removed] 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/
[digitalradio] Re: Timing requirements of digital ARQ
To use your example, Rick, if Windows introduces a 10 ms delay from the time when you strike a button to initiate transmission in MultiPSK until the point where Commander sends a CI-V "Transmit!" command to your 756 Pro2, you'd never notice. However, such a delay in confirming reception of a Pactor-3 packet would break the protocol. The SCS PTC-II Pro, which supports both Pactor-2 and Pactor-3, utilizes a Motorola (now Freescale) 68360 clocked at 25 MHz and a 56303 24-bit DSP clocked at 100 MHz; see http://www.globalmarinenet.net/ptc.htm The 68360 is a descendant of the venerable 68000; its probably being used for administrative tasks like running the serial port and command line interface. The 56303 DSP does the heavy lifting. While its DSP instruction set is advantageous, its performance is modest by current standards; see http://www.bdti.com/articles/benchmark_icspat99.pdf#search=%22dsp% 20benchmarks%22 I am unable to locate a benchmark comparing the performance of dedicated DSP chips like the 56303 DSP with general purpose microprocessors, but I suspect that a 1 GHz Pentium could handle the processing load. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, KV9U <[EMAIL PROTECTED]> wrote: > > Since I am not a programmer, other than taking some rudimentary courses, > reading some of Don Lancaster's books, and knowing that it is not > something I could ever do very well, something still doesn't seem right > to me when it comes to the claim that computers just can not meet the > timing requirements of ARQ digital modes. > > When I use the computer to key my ICOM 756 Pro 2 with Dave's DX Lab > Commander software in order to run other programs that interface with > Commander (such as Multipsk which is my main digital sound card > program), it does not seem to have much latency at all. And if one could > key relatively slow CW as is done with the software for the SDR1000, why > would that not be almost a magnitude faster than you would need for > adequate ARQ switching speed? > > How many ms do you need? > > Rick, KN6KB, the inventor of SCAMP, has said that the power in the > typical Windows OS computer we use is something like a magnitude less > than that available in the dedicated SCS modems and that is why they > perform so well compared to a computer (for the dedicated part). I > wonder where the dividing line will come so that computers will at least > match the SCS type units? > > 73, > > Rick, KV9U > > > Dave Bernstein 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/
[digitalradio] Re: Timing requirements of digital ARQ
--- In digitalradio@yahoogroups.com, KV9U <[EMAIL PROTECTED]> wrote: > > Since I am not a programmer, other than taking some rudimentary courses, > reading some of Don Lancaster's books, and knowing that it is not > something I could ever do very well, something still doesn't seem right > to me when it comes to the claim that computers just can not meet the > timing requirements of ARQ digital modes. > > When I use the computer to key my ICOM 756 Pro 2 with Dave's DX Lab > Commander software in order to run other programs that interface with > Commander (such as Multipsk which is my main digital sound card > program), it does not seem to have much latency at all. And if one could > key relatively slow CW as is done with the software for the SDR1000, why > would that not be almost a magnitude faster than you would need for > adequate ARQ switching speed? > > How many ms do you need? > > Rick, KN6KB, the inventor of SCAMP, has said that the power in the > typical Windows OS computer we use is something like a magnitude less > than that available in the dedicated SCS modems and that is why they > perform so well compared to a computer (for the dedicated part). I > wonder where the dividing line will come so that computers will at least > match the SCS type units? > > The problem is not that the PC's are not fast enough, it's that the timing of events is not predictable enough. In even the smallest microcontrollers, you can control the timing of events and processing down to a microsecond, if you so choose. For example, you can set the state of a pin, wait 8.76 milliseconds, change the state - and you KNOW that the state will be changed at that 8.76ms point, no if's, and's, or but's. In a typical PC OS, however, you lose that predictability. You can tell the OS, "I want to wait 8.76ms", so you can then go and change the state of the pin, but, in reality, you may not actually be able to do it for 8, 10, or 30ms later, because the OS is busy doing other things, in the meantime. Asking for an 8.76ms pause doesn't mean you'll GET an 8.76ms pause. I can't speak as to the accuracy of the posting that indicated that Windows has some facilities to accomodate real-time programming. If that's the case, I have to wonder why nobody has done it under Pactor I, at least, for Windows. Years ago, there were P-I *decoders* that worked under DOS. And now there's a P-I application for Linux called 'hfterm'. But, I've compared on-the-air performance between hfterm and my SCC PTC-II modem in P-I mode, and there's just no comparison - the SCS blows hfterm away. At least, so far. ;-) - Rich 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/
