[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/
