[aprssig] Delayed packets

[AE5PL Lists]

> -----Original Message-----
> From: mconner at aer.com
> Posted At: Tuesday, June 06, 2006 1:43 PM
> Subject: [aprssig] Delayed packets
> 
> Everyone seems to want to point to another component of the 
> system, resulting in a circular firing squad.  Unfortunately 
> the real data to analyze this exists (perhaps only 
> fleetingly?) at the core servers prior to dupe checking.  It 
> would be interesting to analyze and flag this behavior so the 
> problem can be characterized.

Actually, the only place to analyze this is at the "offending" IGate and
the "offending" server the IGate is connected to.  This is the only
place where true network monitoring (not application data stream
monitoring) can be done on the problem data.

> Another (uglier) fix is to perform more dupe checking at the 
> core servers.  From a previous post, the dupe checking is 
> limited to 30 seconds to allow repeat transmissions of 
> messages through.  Could a longer filtering time be applied 
> to posits only?  Something like 300 seconds would catch all 
> but the most egregious cases.

The dupe check is independent of APRS packet type so this is not an
option.

> I think this would be an interesting diagnostic exercise.  
> This could be speeded up by having this logging on hand 
> already.  If someone has a way to provide me undecoded 
> APRS-IS data with a time hack (similar to the FindU extract 
> above), I may be able to speed this up.  If you have decoded 
> data, I'll need to have path information (everything between 
> the > and :) included.

There are a couple of misconceptions: first, findU is not part of the
puzzle other than the fact its database can be queried.  As I pointed
out earlier, findU is not APRS-IS.  findU is a database application
(like aprsworld.net and www.jfindu.net) that gets its data from APRS-IS
but it has no affect on any latencies in the APRS network since it is a
receive-only application.  Second, not everyone connects to the core
servers.  In fact, less than half do and that keeps those core servers
running because they require significantly less bandwidth than would be
required if everyone connected to them.

This is why the diagnostics must be done at the IGate and entry-level
server.  This is the only place where a true analysis can be done.
Unfortunately, someone looks at their TNC window and says "it all looks
ok to me" without realizing that the packets could be unduly delayed
because of serial driver issues (like the USB issue mentioned earlier)
or because of a TCP/IP buffering issue on the network side of the
application.

73,

Pete Loveall AE5PL
mailto:pete at ae5pl.net