[aprssig] Delayed packets (yet again)

Sat Aug 26 10:12:44 EDT 2006

Are we over-thinking this situation?

It occurs to me that it may be a combination of things, all contributing to
a built-in delay, which may be characteristic of the IS system.  

Based on recent messages, both here and on the UI-View list, there seem to
be two concerns:

1.                   A delay between the times a beacon is sent out from an
APRS station via RF to when it's seen on APRS IS

2.                   Tracked objects "jumping" back some distance

The delay may be caused by the time lag between a packet going out at 1200
baud, going from the TNC to the computer at 9600 baud, being picked up by an
RF-Internet gateway, going to the server at much higher b/s rates, crammed
into the server's buffer, then sent out on the Internet to each station
connected, some of which are not range-filtered, and finally sent from the
computer at whatever rate the client NIC/computer sends it to the screen.  

Also, here is a recent log of activity of my station alone, from the T2
Midwest server.  Range filtered at 300km:

Packets for W9JBL
Time in UTC

8/26/2006 13:20
W9JBL>APU25N,WA9CJN-15*,IL2-1,qAo,WB9WLS:=4155.50N/08845.11W- {UIV32N}

8/26/2006 13:24
W9JBL>APU25N,WA9CJN-15*,IL2-1,qAR,W9TMW:=4155.50N/08845.11W- {UIV32N}

8/26/2006 13:34
W9JBL>APU25N,TCPIP*,qAC,T2MIDWEST:=4155.50N/08845.11W- {UIV32N}

8/26/2006 13:36
W9JBL>APAGW,WA9CJN-15,WIDE2*,qAS,N9ZIP:Using Elcom uTNT Plus

8/26/2006 13:39
W9JBL>APU25N,TCPIP*,qAC,T2MIDWEST:=4155.50N/08845.11W- {UIV32N}

8/26/2006 13:43
W9JBL>APU25N,TCPIP*,qAC,T2MIDWEST:=4155.50N/08845.11W- {UIV32N}

8/26/2006 13:44
W9JBL>APU25N,TCPIP*,qAC,T2MIDWEST:=4155.50N/08845.11W- {UIV32N}

As the log shows, some packets are picked up directly by the server, others
are received after one AND two hops.  Unless the server is reliably
filtering out ALL dupes, this may account for the jumping I saw in W9JBL-9
last weekend, where a late beaconed tracker packet hit the client computer,
containing GPS data made the icon regress to where the prior beacon located
it.

Just a thot/question.

bl
------------------------------------
"If stupidity got us into this mess, then why can't it get us out?"
- Will Rogers 

  _____  

From: aprssig-bounces at lists.tapr.org [mailto:aprssig-bounces at lists.tapr.org]
On Behalf Of Wes Johnston, AI4PX
Sent: Friday, August 25, 2006 10:04 PM
To: TAPR APRS Mailing List
Subject: Re: [aprssig] Delayed packets (yet again)

Recently kc4pl and I saw enormous delays on RF.  We've seen igate delays
from ww6jc in a nearby town running ui-view.  At anyrate, kc4pl is running
TNC-x and an ax.25 stack connected to javaaprs.  What we saw was /were
delays on the order of 60 to 90 seconds.  I was sending packets that were
uniquely numbered so we'd know which got thru and which didn't.  

We suspected that perhaps TNCx was hearing too many packets on frequency to
TX, so he QSY'ed the radio.  I send a few more packets.  Then it dawned on
us that he wasn't seeing the packets I send for 60 to 90 seconds.  As soon
as he saw them appear in the ax.25 stack, they were digipeater.  In the
process of reaching under the desk, he may have reset or momentarly
interrupted the power to the TNCx.... so we're not sure if the tnc-x is the
problem or the ax.25 stack in linux.  Or maybe some part of the system
needed a break. At this time, we're waiting for the delays to happen again
so we can figure out if it's TNC-x or ax25 stack. 

Possible theories include that TNCx may have a memory leak...

tncx may spend so much time servicing interrupts in a busy channel that it
can't deliver data to the serial port.

ubuntu ax25 may have a problem.

Really don't know anything difinitive at this point.

Wes

On 8/25/06, Tim Cunningham <tim_cunningham at mindspring.com> wrote: 

There was a delayed packet discussion specifically concerning IGates
recently. We did a through study into the problem in my area and isolated
the problem to a UI-View station operating as an IGate. Since that
discussion there were a few other folks across the country who wrote
off-line that they experienced the same issue with UI-View in their areas.
This issue was specifically limited to a UI-View IGate that was injecting
packets greater than 1 minute later than another IGate using APRS+SA. Many
of the packets were time stamped to verify the delay. It was not a
digipeater delay because we could see two IGates hearing the same packet
from the same digipeater being injected into the APRS-IS greater than one
minute apart. 

IGates that are experiencing delays should consider using filtered port
14580 and limit their data to under 100 to 200km using the m/100 to m/200
qualifier. When an IGate tries to process the full feed they are going to
run slower depending on their computer configuration and whether they are
using a dial-up feed or a high speed link. 

There are many sources of delays that also include digipeaters. The first
step is to identify if the delay is the USB to serial converter which should
be fairly easy by visual observation on how long it takes a decoded packet
to appear on the screen. Then, it becomes only a measure of time from that
point to when it appears on the APRS-IS. 

73's,

Tim - N8DEU

Huntsville, Alabama

----- Original Message ----- 

From: J T <mailto:w0jrt at yahoo.com>  

To: TAPR APRS Mailing List <mailto:aprssig at lists.tapr.org>  

Sent: Friday, August 25, 2006 1:26 PM

Subject: [aprssig] Delayed packets (yet again)

In one of the many "delayed packet" discussions there was talk about some
serial-to-USB converters causing issues.  I can't seem to find this
discussion in the archives.  Does anyone recall the make(s)/model(s) of the
serial-to-USB converters that are known or suspected of being problematic?
And perhaps suggest a model that is known to work well? 

I've been communicating with an I-gate owner whose station is injecting
delayed packets into APRS-IS.  He's too busy to study and fix the problem
(unfortunately for the rest of us) so I'm trying to help gather some
information that may make it easier to debug the problem.  He swapped TNCs
but that didn't fix it.  He mentioned that he uses a serial-to-USB converter
so hopefully I can talk him into experimenting with a different one or
coming up with another solution. 

-Jerome, W0JRT

  _____  

All-new Yahoo! Mail
<http://us.rd.yahoo.com/evt=43256/*http:/advision.webevents.yahoo.com/mailbe
ta> - Fire up a more powerful email and get things done faster. 

  _____  

_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig

_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org  <mailto:aprssig at lists.tapr.org> 
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20060826/dee2f926/attachment.html>