[aprssig] Delayed Packets

[AE5PL Lists]

javAPRSSrvr utilizes a real-time buffer to process packets.  In other
words, packets are processed as they are received and then sent to the
individual TCP connections.  Different operating systems handle TCP/IP
packet buffering differently and could cause delays beyond the control
of the application.  This OS buffer caveat is the same for all IGate and
server software.  The largest buffers I have seen are implemented in the
-ix operating systems (Linux, Unix, etc.) which normally use a variable
sized buffer.  Windows uses a default of 8k bytes.  Mac OS 9 uses 16k
bytes.  An average packet is about 150 bytes (including IP header).  If
javAPRSSrvr sees more than 15 seconds of packets being buffered for a
connection (this is above and beyond the OS buffer which it has no way
of determining), the connection is severed and all packets for that
connection are discarded.

Could this OS buffering cause an hour delay or even few minutes delay?
In all likelihood, no but it is possible.  The upstream connection from
the IGate or server would have to be very unreliable or very slow (the
total bandwidth of APRS-IS is only about 20 Kbps including IP headers).
If the link is that unreliable, it will normally be severed before those
buffered packets can make it through.  Once a connection is severed, all
packets for that connection, whether in the OS buffer or the server
connection buffer, are discarded.

Other sources of delays:

1) digipeaters with an improperly set squelch or persistence (delays of
over 30 minutes seen with a D700 as a digi);
2) IGate sysops replaying logs while connected to APRS-IS (some versions
of software have trouble with this);
3) IGates or servers connecting to history ports on aprsD
(bidirectional) or using a separate connection to a javAPRSSrvr history
port (unidirectional);
4) servers or IGates using multiple concurrent bidirectional upstream
connections with some connecting to non-server ports (port 14579 TNC
port on aprsD, for instance);
5) IGate or server software buffering packets between connections.

I am not aware of software that falls into the last category although it
might exist.  #4 is an issue because packets can end up being gated to
RF and then reintroduced back into APRS-IS.  We have also seen long
running loops from this (although usually in the minute or less range).
#3 is an issue because it can confuse IGate software and defeat dupe
checking.  #1 and #2 are the most common case of lengthy delays.
Monitoring RF directly in the problem area will help determine if #1 is
an issue.  Contacting the IGate operator directly will help with #2.
Also, this list of sources is not all-inclusive.  I am sure there are
other potential causes.

In all cases, it is important to _not_ assume that the problem is here
or there just because of what you see on one of the APRS-IS databases.
Keep in mind that all of the servers do dupe checking (for a 30 second
interval) so the database will only see the first packet to make it
through APRS-IS.  The dupe checking is not a function of the database,
it is a function of all of the servers.

73,

Pete Loveall AE5PL
mailto:pete at ae5pl.net