"Preload" means that PING is sending (in your case) 20 ICMP packets
to the remote station in a batch. You should get MAXQUEUE of them
back, in fact you only get MAXQUEUE-1 because I didn't serialized
my parallel thinking correctly (if (queue_len >= MAXQUEUE-1),
yikes...)
The general behaviour is intended to avoid a horrible latency due
to congestion on the radio channel. It does not make sense to queue
up frames ad infinitum as you currently cannot tell AX.25 what's going
on and you will never be able to tell a remote station using you as an
IP router.
Your queue will build up until you either run out of buffers or
the retry counters of the connections overflow. But the device
driver will send anything in the queue even though the connections
do not exist anymore, making the congestion even worse... From
what I've experienced it can take up to half an hour until things
settle down (given that nobody tries to establish new connections in
the meantime).
Face it: You can only transmit a certain amount of data in a given
time (limited by the bit rate, S/N rate, amount of users trying to
access the channel, medium access (MAC) algorithm, protocol overhead,
transceiver switch time, etc). I think eight buffered frames are a
reasonable compromise, but depending on your situation you may need
to increase or decrease the value. Or you can use mode vc, which
doesn't let the IP layer access the device driver directly. In this
case often only the TCP connections using the congested AX.25
connection would starve.
> i increased this constand to 80, and no 'buffer overflows' occur. (ping
> works now ok)
Now try it with a preload of 90...
You will get into trouble (especially with AX.25 connections) with
a value *that* high. I'd suggest to stay below 16.
vy 73,
Joerg Reuter ampr-net: lhhfkvnv.paydtj@mailit.tunk.net
Internet: cpv@mx.dy.fi
www : http://poboxes.com/jreuter/
If God had intended man to smoke He would have set him on fire.