[EMAIL PROTECTED] writes: > 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.
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/