Re: [digitalradio] New to Digital HF -- PACTOR setup and hardware maybe needed???
Chris, What is your view on using pipelined programming such as what was used in the SCAMP mode to get around this issue with moving the ACK to the next packet. The main penalty is latency for the user, but it seems manageable. 73, Rick, KV9U Chris Jewell wrote: Suppose you're using your sound card as a modem to receive Pactor I data. Your sound card takes care of turning tones from the receiver into 1s and 0s. There's no problem there. However, when a packet is finished arriving (and getting turned from frequency shifts into bytes of data), the application program running on the PC must verify the check, turn the radio around to transmit, and send either a positive or negative acknowledgement, then turn it back to receive mode so it can hear the next packet. The problem is that the OS may have dispatched some other process at the time, and the process that does the checking and sending of the ACK or NAK may not get a time slice from the OS soon enough to meet the timing requirements of the Pactor acknowledgement. If you were using a TNC, the processor in the TNC would be old and slow by current standards, but it would have nothing else to do EXCEPT check the checksum and send the ack or nak, while the much faster CPU in your Linux (or even worse, Windows) PC may be busy doing something else at the crucial time, since it is running a multitasking, and even potentially multi-user, OS. In principle, it seems that it should be possible to manage that problem in the Linux environment by: 1. adjusting the dispatching code in the OS so that it gives very short timeslices to processes, so the Pactor process can get CPU time sooner; and 2. running the Pactor process with a high dispatching priority (which the superuser can accomplish with a negative priority value on the renice command.) Shortening the time slice means that more of your CPU power is used up on trips through the dispatcher portion of the OS, rather than in running whatever user-mode application programs are ready to run, but with a fast computer that doesn't have a lot to do, that should be okay. In FreeBSD, you would issue a command like this as root: # sysctl kern.sched.quantum=1 The quantum is measured in microseconds. The default value is 100,000, or 100 milliseconds. By changing it to 10,000, or 10 milliseconds, you make it possible for the highest-priority task to get use of the CPU within 10 milliseconds, rather than 100. I'm not really a Linux guy, so I don't know whether there is a comparable sysctl variable in Linux, or whether you can build a custom kernel that uses a shorter scheduling quantum, or what. -- 73 DE AE6VW, Chris Jewell [EMAIL PROTECTED] Gualala CA USA 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/
Re: [digitalradio] New to Digital HF -- PACTOR setup and hardware maybe needed???
KV9U writes: Chris, What is your view on using pipelined programming such as what was used in the SCAMP mode to get around this issue with moving the ACK to the next packet. The main penalty is latency for the user, but it seems manageable. I haven't read any detailed specs of the SCAMP protocol, only vague descriptions, and I understand that the source code is not available for public inspection at this time, but in principle a pipelined approach seems like a good way to handle the problem of OS latency in ACK/NAK at the application level, without requiring expert hackery in low-level OS details. My previous reply was just an attempt to describe the problem of non-realtime operating systems and lockstep ARQ modes such as Pactor for someone who had asked. I note that another reply said that there is a alternative real-time-capable kernel for Linux systems, so for those willing and able to use Linux, the ARQ problem may be already solved. However, a solution available to the Windows and Mac users seems like a good thing even so. In TCP, the receiving host periodically sends an ACK that responds NOT to a specific incoming packet, but instead says I have received correctly everything up to byte number N. If the sending host doesn't get an ACK up through the bytes in a given packet within a certain interval, it resends the data and all following data. This allows communication to succeed eventually if some ACKs or NAKs don't get back to the sending station. Of course, TCP/IP was conceived for full-duplex media: the sender can keep the outgoing pipe full, provided the ACKs arrive soon enough. The window size (how many bytes ahead of the ACK the sender may send) needs to be larger for faster circuit, and also larger for a circuit with a long round-trip time, such as via geosynch satellites or with many overloaded routers in the path; the window can be smaller for terrestrial circuits with few routers between the communicating hosts. Partly because incorrect packets are going to be more frequent on HF radio than on land lines, we probably should not duplicate the TCP solution in ham radio, but it gives us a starting point to think about. A system for half-duplex HF radio circuits has to provide for periodic turnaround. Short packets with frequent ACK/NAK cycles a la Pactor or GTOR allow the receiver to promptly notify the sender of changing propagation on the channel. A deep pipeline postpones that feedback, so more data may need to be resent when the circuit is unstable, BUT also makes it straightforward to implement on a typical multitasking OS. It's all a matter of trade-offs. Given that we deal with noiser circuits than were envisioned by the designers of TCP/IP, we probably want a fixed (or periodically adjusted) packet size, and a fixed number of packets sent before turnaround. The ACK would then say which of the packets arrived clean and which need to be resent. The sender could then resend those packets which need it, and add some more new ones to make up the agreed number to be placed in the pipeline. (For the sake of argument, how about 8 Pactor-sized packets followed by an ACK window 8 times as long as Pactor uses?) This is off the top of my head: if anyone has already been thinking more deeply about this and has better suggestions, by all means offer them. I'm an old computer geek but a new ham: I'm happy to learn about either computers or radio from anyone who can improve my understanding. -- 73 DE AE6VW Chris Jewell[EMAIL PROTECTED]Gualala CA USA 95445 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/
RE: [digitalradio] New to Digital HF -- PACTOR setup and hardware maybe needed???
Back in the late 80's when Mil-STD-188-110 was still in development, a Harris RF Comm Gp engineer/programmer recommended that you send a frame with X number of numbered packets with a CRC. The receiving station would only NAK the packets it didn't receive. The transmitting stations would start transmitting another frame with the missed packets first and then the new packets. The total of the packets, missed and new, would be less than the original number of packets. When no NAKs were received, the transmitting station would start sending more packets in a frame. Walt/K5YFW -Original Message- From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] Sent: Monday, August 28, 2006 2:28 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] New to Digital HF -- PACTOR setup and hardware maybe needed??? KV9U writes: Chris, What is your view on using pipelined programming such as what was used in the SCAMP mode to get around this issue with moving the ACK to the next packet. The main penalty is latency for the user, but it seems manageable. I haven't read any detailed specs of the SCAMP protocol, only vague descriptions, and I understand that the source code is not available for public inspection at this time, but in principle a pipelined approach seems like a good way to handle the problem of OS latency in ACK/NAK at the application level, without requiring expert hackery in low-level OS details. My previous reply was just an attempt to describe the problem of non-realtime operating systems and lockstep ARQ modes such as Pactor for someone who had asked. I note that another reply said that there is a alternative real-time-capable kernel for Linux systems, so for those willing and able to use Linux, the ARQ problem may be already solved. However, a solution available to the Windows and Mac users seems like a good thing even so. In TCP, the receiving host periodically sends an ACK that responds NOT to a specific incoming packet, but instead says I have received correctly everything up to byte number N. If the sending host doesn't get an ACK up through the bytes in a given packet within a certain interval, it resends the data and all following data. This allows communication to succeed eventually if some ACKs or NAKs don't get back to the sending station. Of course, TCP/IP was conceived for full-duplex media: the sender can keep the outgoing pipe full, provided the ACKs arrive soon enough. The window size (how many bytes ahead of the ACK the sender may send) needs to be larger for faster circuit, and also larger for a circuit with a long round-trip time, such as via geosynch satellites or with many overloaded routers in the path; the window can be smaller for terrestrial circuits with few routers between the communicating hosts. Partly because incorrect packets are going to be more frequent on HF radio than on land lines, we probably should not duplicate the TCP solution in ham radio, but it gives us a starting point to think about. A system for half-duplex HF radio circuits has to provide for periodic turnaround. Short packets with frequent ACK/NAK cycles a la Pactor or GTOR allow the receiver to promptly notify the sender of changing propagation on the channel. A deep pipeline postpones that feedback, so more data may need to be resent when the circuit is unstable, BUT also makes it straightforward to implement on a typical multitasking OS. It's all a matter of trade-offs. Given that we deal with noiser circuits than were envisioned by the designers of TCP/IP, we probably want a fixed (or periodically adjusted) packet size, and a fixed number of packets sent before turnaround. The ACK would then say which of the packets arrived clean and which need to be resent. The sender could then resend those packets which need it, and add some more new ones to make up the agreed number to be placed in the pipeline. (For the sake of argument, how about 8 Pactor-sized packets followed by an ACK window 8 times as long as Pactor uses?) This is off the top of my head: if anyone has already been thinking more deeply about this and has better suggestions, by all means offer them. I'm an old computer geek but a new ham: I'm happy to learn about either computers or radio from anyone who can improve my understanding. -- 73 DE AE6VW Chris Jewell[EMAIL PROTECTED]Gualala CA USA 95445 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 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
Re: [digitalradio] New to Digital HF -- PACTOR setup and hardware maybe needed???
Pactor and Amtor use ARQ mode. Because of this timing a computer WILL NOT keep up with the TNC equipped station. I did run some test about 3 years ago and the computer only station on a AMTOR / PACTOR link could only do about 43% of what the TNC equipped station did. At 05:35 PM 8/26/2006, you wrote: On Tue, 15 Aug 2006 15:10:49 -0500, John Becker [EMAIL PROTECTED] wrote: If you are going to operate Amtor or Pactor ARQ mode you will be better with a TNC. Otherwise for the sound card mode you will not need it. ok, IC736 running the rig with HRD from an Intel Pent 4 via CI-V interface USB cable on MARS. running Pactor, do I need a TNC? WHAT IS A TNC exactly. iow, WHAT does it do? Why can I not simply load the Pactor software into the PC along with my HRDeluxe software?? If I need the TNC, how do I hook it up to work with HRD and CI-V?? 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/
Re: [digitalradio] New to Digital HF -- PACTOR setup and hardware maybe needed???
John Becker wrote: Pactor and Amtor use ARQ mode. Because of this timing a computer WILL NOT keep up with the TNC equipped station. I did run some test about 3 years ago and the computer only station on a AMTOR / PACTOR link could only do about 43% of what the TNC equipped station did. Have you tried it with an up-scale sound card on a computer equipped with both a fast processor and a lot of RAM? What was the interface between PC and rig? USB 1.0, 1.1, 2.0, Serial, Parallel, other? I am wondering if the rapidly improving PC hardware may have solved the speed problem? Also, which OS did you test, please? Apple, the MS version of windows (XP?), Linux? I am not questioning your observations just am curious as to the testing context. -- Thanks! 73, doc, KD4E ... somewhere in FL URL: bibleseven (dot) com 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/
Re: [digitalradio] New to Digital HF -- PACTOR setup and hardware maybe needed???
It was on a linux system But that does not matter. The problem is EVERY time the computer thinks what do I need to do now - the timing is lost and so is the link. At 09:53 AM 8/27/2006, you wrote: Have you tried it with an up-scale sound card on a computer equipped with both a fast processor and a lot of RAM? What was the interface between PC and rig? USB 1.0, 1.1, 2.0, Serial, Parallel, other? I am wondering if the rapidly improving PC hardware may have solved the speed problem? Also, which OS did you test, please? Apple, the MS version of windows (XP?), Linux? I am not questioning your observations just am curious as to the testing context. -- Thanks! 73, doc, KD4E ... somewhere in FL URL: bibleseven (dot) com 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 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/
Re: [digitalradio] New to Digital HF -- PACTOR setup and hardware maybe needed???
On Sun, 27 Aug 2006 22:02:33 -0500, John Becker [EMAIL PROTECTED] wrote: It was on a linux system But that does not matter. The problem is EVERY time the computer thinks what do I need to do now - the timing is lost and so is the link. ??? now, I am not a geek for computers, but my Perl mobo has a pair of 3.1ghz cpus running with huge cache, and 2gb of ram. the soundcard is running along with a pretty wide gateway and its own gb or so of ram. i just don't think that the wait states, if there are any, are going to be sufficient to bog down a real, damned slow modem since most of those are probably running at 1200 to 2400bps. which is real slow. I have a dsl which supposedly is running at 3.2kbips but it is uploading slower than my pc is pushing it up the line. I am definitely confused which is NOT unusual in the least. another point, my IC 736 has a modem in it, CI-V compliant or ready, and supposedly, I should be able to load the Pactor/ALE, etc software in the PC and using it and the sound card and the rig running software, -- push traffic out over the USB2.0 interface cable to the rig. and again, that is with HRD controlling the operation. Obviously, the modem even were it running at 56,000 is still far slower than my dsl is capable of or the speed at which my pc is loading.up or down. the slowest thing going is probably the TNC. BUT Pactor I is supposedly designed to work with the old, original slow modems. So, please enlighten me thanks confused chas/73 73/chas -- K5DAM Houston EL29fuAAR6TU http://tinyurl.com/df55x (BPL Presentation) 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] New to Digital HF -- PACTOR setup and hardware maybe needed???
On Tue, 15 Aug 2006 15:10:49 -0500, John Becker [EMAIL PROTECTED] wrote: If you are going to operate Amtor or Pactor ARQ mode you will be better with a TNC. Otherwise for the sound card mode you will not need it. ok, IC736 running the rig with HRD from an Intel Pent 4 via CI-V interface USB cable on MARS. running Pactor, do I need a TNC? WHAT IS A TNC exactly. iow, WHAT does it do? Why can I not simply load the Pactor software into the PC along with my HRDeluxe software?? If I need the TNC, how do I hook it up to work with HRD and CI-V?? What am I not understanding here besides everything? G I am absolutely new to this and the ARRL HF Digital Handbook (isfai can tell from talking to elmers (few of whom agree) and reading these elists) was wasted money... anyone want a copy cheap?? ;-) HELP!!! 73/chas -- K5DAM Houston EL29fuAAR6TU http://tinyurl.com/df55x (BPL Presentation) 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/
