[aprssig] "Out-of-order" data on APRS-IS

[AE5PL Lists]

> -----Original Message-----
> From: Mark Conner
> Posted At: Tuesday, August 09, 2005 9:51 AM
> Subject: [aprssig] "Out-of-order" data on APRS-IS
> 
> This packet did traverse 3 digipeaters but certainly in less 
> than 3 min 43 sec.  I'm assuming the delay is between 
> KC0QWN-10's antenna and the FindU database.  Where this delay 
> is occurring I'm not sure about.  

Look to RF.  I have seen TNC's delay transmission over 35 minutes (there
is a Kantronics KPC3+ in Oklahoma that was doing this a couple of weeks
ago and may still be doing it, for instance)!  While it is obvious by
your own analysis that this packet traversed a different RF path, you
still think this lies in APRS-IS.  It doesn't.  Look to the RF path when
these problems occur and you will likely find your problem.

There are two instances where we have seen excessive delays in APRS-IS:
improperly configured servers causing delayed loops through their local
environment (RF path will normally be the same in this case) or someone
uses older software and replays a log without disconnecting from RF and
APRS-IS.  The first issue has been eliminated with javAPRSSrvr as it
does not allow those configurations.  Non-javAPRSSrvr servers may still
exhibit this problem although there are no issues currently pointing to
a specific server configuration.

The second issue caused an admonition to be issued to everyone to be
sure that they disconnect from both RF and APRS-IS before replaying logs
in their clients.

Bottom line: Your initial analysis of a separate RF path was a good one.
Don't ignore it.  The problem in all likelihood resides there, not in
the APRS-IS.

73,

Pete Loveall AE5PL
mailto:pete at ae5pl.net