[aprssig] RE: Delayed packets

[AE5PL Lists]

First, please do not add my personal email address to the reply if you
are replying to the list.  It only causes duplicate emails to arrive
here and tends to make me less likely to respond to either.

> -----Original Message-----
> From: mconner at aer.com
> Posted At: Wednesday, June 07, 2006 12:43 PM
> Subject: [aprssig] RE: Delayed packets
> 
> >The dupe check is independent of APRS packet type so this is not an 
> >option.
> 
> I know it *is now* independent of packet type, but does it 
> have to be, and why?

Yes.  APRS-IS is designed to _transparently_ transport any UI packet.
It is not intended to alter content or intent of RF generated packets.
Also, APRS-IS is made up of over 400 independently run servers running
multiple software.  To try and change how these do their job when the
current method does it properly would be a worthless effort in futility.

> >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.
> 
> I probably should not have said "core servers", but wherever 
> the 30-second dupe checking is performed.

400+ servers.  Ain't going to happen.

> This is true to conclusively prove that an IGate is the 
> problem.  However, this buffering would probably be invisible 
> to the IGate owner unless a duplicate system was running 
> right next to it that did not have these issues.  Because 
> this problem tends to come and go, I don't see this as a 
> viable diagnostic alternative. 

Then you didn't read what I said.  It does not require a duplicate
system.  It does require a _knowledgeable_ use of network monitoring
software on the IGate and proper comparisons with the server that the
IGate is attached to.  The problem does not come and go.  Once it is
identified, it is usually in existence until rectified.

> The alternative is to throw up our hands, say that we are 
> unable to get the data necessary to prove conclusively the 
> source of the problem, and just "live with it".  I say that 

Not at all.  But your "solution" is neither doable or effective.

> I really think any internet user of the APRS-IS, whether it's 
> FindU users, IGates, or whatever, should be concerned about 
> this.  If an duplicate report is the last one received, FindU 
> reports that old position as the "latest" one.  Similarly, 
> APRS clients who use the APRS-IS for their data will also 
> display an old position.  This has happened to me relatively 
> frequently where I check FindU for a mobile station and have 
> to go to the "raw data" display to make sure what I'm seeing 
> is truly the latest position sent out by that mobile.

And how do you do this with Mic-E?  There is no timestamp in Mic-E.
Most of the timestamps in non-Mic-E position packets tend to be
inaccurate, as well.  Your case for your "solution" is based on a number
of invalid assumptions about the data, the architecture of APRS-IS, and
what is available to use for diagnostics.

To isolate these problems, determine the APRS-IS entry point (if
multiple entry points for the problem, then look to common occurrences
in the RF network), and work _with_ the IGate operator to determine
whether his system is delaying packets into the network, is seeing the
packets late (you can always telnet into the server the IGate is
attached to and see when APRS-IS first sees the packet), or if there is
some other issue.

73,

Pete Loveall AE5PL
mailto:pete at ae5pl.net