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=10000 >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/
