[aprssig] RE: Delayed packets

[mconner at aer.com]

AE5PL wrote:
>N9XTN wrote:
>> 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 know it *is now* independent of packet type, but does it have to be, and why?

>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.  

No misconception here.  FindU is simply a diagnostic tool in this case, not a suspected problem source for this issue.  The FindU time hack (its time of receipt) is to a decent approximation the time of receipt of the packet in the APRS-IS.  The delay from actual entry into the APRS-IS to the entry into the FindU database is far, far less than the few minutes' delay where we see duplicate posits.

>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.

>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.

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. 

We can, however, gather evidence as I laid out before.  I agree it's not 100%, but I think the overall system performance and information readily available is good enough to start isolating the problem in this manner.  If these duplicate posits in the APRS-IS client stream consistently indicate one application as the source, then we have narrowed the issue down a bit.  If it doesn't, then it is more likely to be serial or TCP/IP buffering issues that are independent of APRS application.  My own anecdotal experience points to one application, but I'd like more information.

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 we can collect enough (imperfect) data with the tools at hand to better characterize the problem.  It's not enough to convict anyone in a court of law, but it certainly is enough to target further investigation.

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.

73 de Mark N9XTN