[aprssig] IGate to APRS-IS data transfer delays
Tim Cunningham
tim_cunningham at mindspring.com
Tue Jul 18 17:57:58 EDT 2006
Bob,
The intent was to segregate the IGate delay issues from the DCD issues. I
agree that there are some DCD issues, but if you go back to the beginning of
this discussion I weeded out the fact that there were no major DCD issues
with the examples I provided. They were qualified for the 2 IGates in
question where there was a delay problem. This is not to say there are no
DCD delays. We merely qualified one digipeater at 2 seconds which is not
significant. The IGate delays in the examples far exceeded any DCD delay.
When 2 IGates hear the same packet, what is an acceptable time frame for the
IGate to transfer the packet to the APRS-IS ? Your third fact needs
explanation. I provided 2 example where one IGate took 1min 11sec longer and
another around 10mins longer to pass the same data from the same packet
heard by 2 different IGates. Is this amount of delay acceptable? Or, do we
really care how long it takes data to get to the APRS-IS from an IGate?
I am not sure how you can say I am jumping the gun if you read the posts I
presented. Perhaps, I assume too much. In each case data was presented there
was supporting data that highly suggested the IGate was the source of delay
by comparing the delay when 2 IGates heard the same data. It does not take
long to see where the problem resides. When 2 IGates hear the same packet
and the delay in the time it takes for that data to reach the APRS-IS is
significantly different, then something is wrong. You suggest it takes
seconds and that is not the case in my examples. Then again, maybe we have
to accept bouncing position reports when utilizing the Internet connection.
The bouncing position report started this discussion. Data correlation got
to the root cause.
One more time...
Example #1:
20060715003528,W4GPS-7>APZ19,WIDE2-2,qAo,N8DEU-4:!3438.07NS08630.74W#PHG5630/W3,ALn
Huntsville Alabama
20060715003639,W4GPS-7>APZ19,WIDE2-2,qAo,KG4PID-15:!3438.07NS08630.74W#PHG5630/W3,ALn
Huntsville Alabama
20060715004448,W4GPS-7>APZ19,NT4UX-2,NT4UX-3,WIDE2*,qAR,KQ4TV-1:!3438.07NS08630.74W#PHG5630/W3,ALn
Huntsville Alabama
In the above example 2 IGates hear the same packet from W4GPS-7. They are
N8DEU-4 and KG4PID-15. It is the same packet, because the beacon to WIDE2-2
is on a 29 minute cycle. If it is not the same packet the problem is far
more serious. KG4PID-15 sends the same data to the APRS-IS 1min 11sec later
than N8DEU-4. If this were a mobile station beaconing every 1 minute then
you would see position oscillation on FINDU and from the APRS-IS. It is this
simple. There are no digipeaters involved in the first 2 packets, except for
the digipeater originating a beacon.
Now the third packet has 2 digipeaters involved before the KQ4VT-1 IGate
sends the packet to the APRS-IS 9min 20sec later. This is a harsh delay, but
I think Bruce stated he may have fixed a time sync problem at KQ4VT-1. How
did I qualify KQ4VT-1 IGate was the source of the delay. Look at example #2:
Example #2:
1 -
20060715205225,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!3607.19N/08644.47Wj022/005/A=000000
2 -
20060715205516,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!3607.08N/08644.51Wj204/000/A=000000
3 -
20060715210932,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!3607.12N/08644.43Wj220/005/A=000665/Monitoring
443.450+ 107.2 - IRLP 4767
4 -
20060715212237,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!3607.16N/08644.59Wj346/020/A=000557
5 -
20060715212432,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!3607.45N/08645.03Wj033/013/A=000593/Monitoring
443.450+ 107.2 - IRLP 4767
6 -
20060715212738,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!3607.16N/08644.59Wj346/020/A=000557
7 -
20060715212947,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!3607.45N/08645.03Wj033/013/A=000593/Monitoring
443.450+ 107.2 - IRLP 4767
8 -
20060715213045,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!3607.50N/08645.13Wj340/016/A=000636
9 -
20060715213056,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!3607.54N/08645.14Wj059/011/A=000623
10 -
20060715213136,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!3607.54N/08644.73Wj094/031/A=000593
11 -
20060715213252,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!3607.14N/08644.56Wj125/019/A=000511
12 -
20060715213725,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!3607.50N/08645.13Wj340/016/A=000636
13 -
20060715213917,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!3607.54N/08644.73Wj094/031/A=000593
Look closely at the above data. Packets arriving at KQ4VT-1 and KQ4VT-3 from
the same digipeater have a time delta from when they enter the APRS-IS. The
data clearly shows something is wrong between KQ4TV-1 and the APRS-IS in
respect to delays. If you follow the packets you will see KQ4TV-3 gates a
packet and then KQ4TV-1 gates the same packet from the same digipeater at
NT4UX-3, but KQ4TV-1 seems to always be lagging significantly and it varies
up to 10 minutes. So, this is just another piece of data that suggest this
problem is not a DCD problem. Again, two IGates hear the same data at the
same time from the same digipeating station, but they arrive on the APRS-IS
at significantly different times. This data was utilized to correlate the
delay in example #1. Of course, we did not qualify the delays for NT4UX-2
and NT4UX-3 digipeaters. Remember, I was focused on IGate delays. I am not
saying the DCD of these 2 digipeaters is not important, but when I talked to
Bruce I was confident they were set correctly and they were not observing
and major packet delays from these digipeaters.
KQ4TV-JS is the javAPRSSrvr and KQ4TV-1 is the (KISS) TNC-Radio connected to
it. KQ4TV-3 is the xastir (on Mac) station with radios on 144.39 and 144.34.
Both machines are at Bruce's house. While time sync was working fine on the
KQ4TV-3 station, there was a problem with the javAPRSSrvr but Bruce thinks
he has it fixed.
>From example #2. The time lag is as follows:
Line 1 and Line 2 = 2min 51sec
Line 4 and Line 6 = 5min 01sec
Line 5 and Line 7 = 5min 15sec
Line 8 and Line 12 = 6min 40sec
Line 10 and Line 13 = 7min 41sec
Example #3:
20060714194906,N8DEU-12>S4TX1X,WIDE1-1,WIDE2-1,qAo,N8DEU-4:'rEll"9j/]"7+}
20060714195019,N8DEU-12>S4TX1X,W4GPS-7,WIDE1,KU4WW-1*,WIDE2,qAo,KG4PID-15:'rEll"9j/]"7+}
20060714195939,N8DEU-12>S4TX1X,W4GPS-7,WIDE1,NT4UX-2,WIDE2*,qAR,KQ4TV-1:'rEll"9j/]"7+}
We established KG4PID-15 transferred data to the APRS-IS 1min 11sec after
N8DEU-4 in example #1. In this example we see that 2sec are added if a
packet is digipeated by KU4WW-1 on its way to KG4PID-15. The is correlated
data based on the previous time lag as we see in numerous other log files.
So, I pretty much eliminated the digipeater at KU4WW-1 as being a delay
mechanism through correlation of other data that echoes what we see here. It
is a lot of work and it takes a lot of time to get to the root.
The DCD problem is an easy fix and that is why I am excluding it in this
post. It is the IGate delay that has gone without understanding of why it
happens. There is no standard on how long it takes to transfer a packet from
an IGate to the APRS-IS. You state it takes seconds and I concluded through
example and log files that it is not seconds from some IGates. On the
contrary, it can be minutes. The question remains, what is a acceptable time
frame from an IGate to transfer data to the APRS-IS?
Here is a snapshot of some core server statistics based on port usage:
Servers First Second Third Totals
Port 23 57 68 38 163 29.74%
Port 1313 1 0 0 1 0.18%
Port 1314 5 11 3 19 3.47%
Port 10151 0 18 12 30 5.47%
Port 10152 52 29 40 121 22.08%
Port 10154 1 4 7 12 2.19%
Port 10155 3 7 3 13 2.37%
Port 10156 0 0 4 4 0.73%
Port 10157 0 0 1 1 0.18%
Port 10158 0 0 1 1 0.18%
Port 10159 0 0 4 4 0.73%
Port 14578 7 0 0 7 1.28%
Port 14579 0 1 5 6 1.09%
Port 14580 23 37 106 166 30.29%
149 175 224 548
27.19% 31.93% 40.88%
30.29% of the IGates are using the user defined port of 14580. I think if
most IGates used port 14580 and set a limited range of 200km or less to
limit the amount of data coming into their IGate, they could realize a
performance boost. This is merely a suggestion. We use the "r/34/-86/200
t/n" filter option on port 14580 with the core servers to limit the amount
of data our IGate needs to process and it does make a difference for us.
We have established that IGate to APRS-IS delays exist. Now the question is
what can be done to address it.
Does an IGate need to be processing incoming data at all unless it is
specific to their area? There seems to be a huge potential with IGates using
port 14580 and limiting their incoming data. We observed a fairly dramatic
improvement on this end.
This post gets fairly complex, distorted, and it goes off in too many
directions if you try to bring DCD issues into the topic. Please try to keep
DCD issues out of this discussion. It is another topic even though it may
relate to delays.
73's,
Tim - N8DEU
Huntsville, Alabama
----- Original Message -----
From: "Robert Bruninga" <bruninga at usna.edu>
To: <aprssig at lists.tapr.org>; <tim_cunningham at mindspring.com>
Sent: Monday, July 17, 2006 12:46 PM
Subject: Re: [aprssig] IGate to APRS-IS data transfer delays
>>> tim_cunningham at mindspring.com 07/17/06 11:27 AM >>>
>This discussion is not for DCD problems it is for what
>the title suggests. DCD delay is a separate problem
>with digipeaters.
I agree 100% with your assessment and with what you are
trying to do. And I am sorry if I sound like a broken record,
but it seems that going and looking for Igate delays, without
figuring out a method to eliminated the DCD delays from
the process first, is trying to battle one set of unknowns
with a known problem mixed in randomly...
It is extremely tedious to look at every case. I guess what
I am asking, is that someone needs to write an algorithm
that uses a known set of rules to try to separate these two
problems so that energies are not wasted jilting at the
wrong windmill?
Again, I am only kibitzing, and may have missed a break-through,
but without a tool to separate the two problems, it seems
too tedious to do it by hand. I welcome Tim's suggestions
to try to reduce the potential problem on the IGate side. What
are the suggestions for nailing it all down?
Again, here are the facts as I understand them. Correct me
if I am wrong:
1) Delays are seen. These delays could be at DIGIS with DCD
problems or they could be at IGates.
2) The DCD problem has been around over 20 years, is well
known, is well explained, is very very common and is
very easy to accidently cause by wrong setups at the digi
3) There are no known IGate long delay processes other than
the seconds or so inherrent in the internet.
Other than those 3 facts, it seems like jumping the gun
to go looking for IGate delays when it appears to me
(could be wrong) that DCD could still be the problem.
ANd I agree, it is very hard to isolate the two... but since
RF DCD delays are so common, and long delays can perfectly
be described by that process, it just seems like we have
to find a way to eliminate that first.
My guess on an algorithm would be the following:
1) Look for all NMEA sentences (time stamped)
2) Compare times of arrival in APRS-IS
3) If a long delay is observed, then go look
for other data to corroborate whether it is a DCD delay
or not.
Only thing I can thinkn of is to have to then be lucky
enough to get TWO different stations NMEA through
the same digi within the "delay" time. Either, they
are both delayed and come "out" at the same time
(though different going in)...(proving a DCD delay)
Or if you can find one NMEA that is long delayed
and another one that got into-and-out of the
same digi within the time period of the first one's
delay. Then and only then, can you prove it was
not a DCD delay...
Good luck
Bob
Thanks Bob
>>> tim_cunningham at mindspring.com 07/17/06 11:27 AM >>>
This posting has been renamed from "Unreasonable xmission delay" to "IGate
to APRS-IS data transfer delays".
This discussion is not for DCD problems it is for what the title suggests.
DCD delay is a separate problem with digipeaters.
I am posting some discussion to this message to provide the background that
was discussed on the topic of IGate to APRS-IS data transfer delay to
explore why it happens. There has been discussion in the past pointing to
certain APRS gateway software as the problem with no convincing data to
clearly support this suggestion. The problem is position reports oscillate
back and forth when using the Internet feed for APRS data. We have seen data
deays from 1min 11sec to over 10min. Findu cannot filter out these delays
because of the lengthy delay. The end result is oscillating position reports
because they are delayed significantly in reaching the APRS-IS from various
IGates.
We need some basic guidelines for IGates to help reduce this data delay
problem.
After looking at a load of data, the one thing I see that could lead to
delay is the port an IGate uses to connect to an APRS-IS server. Generally,
a true IGate really does not care about what happens 2 digipeater hops
outside the IGate location (this can vary depending on the location). So,
one recommendation would be to use port 14580 and limit your range to say
200 kilometers or less for your Internet feed. If I am in Alabama with an
IGate and I have no reason to see a world feed or a USA feed. All I am
concerned about is what is within a 2 hop path in my area. This greatly
reduces the amount of processing power my computer needs and focuses its
strength in the area it needs to serve.
One correlation I see with IGates that have a large data transfer delay to
the APRS-IS is they are processing large amounts of data when using an
unfiltered feed for their area. Depending on the processing power of their
IGate CPU and I/O speed I think using a filtered feed can help speed up
IGates that seem to have significant delays in transferring what they hear
to the APRS-IS.
We use the "r/34/-86/200 t/n" filter option on port 14580 with the core
servers to limit the amount of data our IGate needs to process. This was
implemented because our IGate less responsive running on a P166 CPU under
Windows 95B. This filtered port dramatically increased the responsiveness on
our IGate. Why? The IGate now has less unnecessary data to process. We do
not care what happens all over the world and find it unnecessary to process
data that is meaningless for our IGate. Our data still gets to the APRS-IS
faster. Our local users still receive their APRS messages from any station
in the world that is directed to them and we still get our weather
bulletins. We do not seem to lose anything that is important using the
filtered port strategy. What we gained in speed was significant.
I am merely suggesting that IGates utilize port 14580 and limit the amount
of data your IGate processes on the incoming feed. You should see a
significant throughput when you implement this change to handle data
applicable to your area of concern. The port an IGate connects is a large
variable that exists in our environment today that can make a significant
impact to the transfer speed of data to the APRS-IS.
I apologize in advance if I am offending anyone by attaching some of the
history on the discussion. That is not the intention. The intention is to
understand and get a grasp on why we see some much variability in the time
between IGates feeding data to the APRS-IS. It is only my opinion that using
filtered port 14580 and limiting data to 200 kilometers or less would make
some significant improvements on existing and future IGates. If you have a
super powered computer, then the improvement by utilizing port 14580 may not
show such dramatic results as it would for a P166 CPU.
73's
Tim - N8DEU
Huntsville, Alabama
<snip> history
On Saturday Jul 15, 2006, at 8:37 PM, KQ4TV wrote:
KQ4TV-JS is the javAPRSSrvr and KQ4TV-1 is the (KISS) TNC-Radio
connected to it. KQ4TV-3 is the xastir (on Mac) station with radios
on 144.39 and 144.34. Both machines at my house. While time sync was
working fine on the KQ4TV-3 station, there was a problem with the
javAPRSSrvr but I think I have fixed it in the last hour or so.
Bruce, KQ4TV
On Jul 15, 2006, at 5:22 PM, Tim Cunningham wrote:
> Here is some additional data from the FINDU server I pulled just to
> see what type of delays were happening closer to the KQ4TV-1 IGate.
> The following data shows something is wrong between KQ4TV-1 and the
> APRS-IS in respect to delays. If you follow the packets you will
> see KQ4TV-3 gates a packet and then KQ4TV-1 gates the same packet
> from the same digipetaer at NT4UX-3, but KQ4TV-1 seems to always be
> lagging significantly and it varies up to 10 minutes. So, this is
> just another piece of data that suggest this problem is not a
> digipeater holding the packets.
>
> If you see the same packet from the same digipeater at 2 separate
> IGates, then the data should not have this type of delay. I could
> not tell how KQ4TV-1 and KQ4TV-3 are connected to the APRS-IS.
> Although I see KQ4TV-JS show up as connected to the server at
> tennessee.aprs2.net using a filtered feed on port 10141.
>
> 20060715204545,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!
> 3607.08N/08644.51Wj204/000/A=000000
> 20060715205225,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!
> 3607.19N/08644.47Wj022/005/A=000000
> 20060715205516,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!
> 3607.08N/08644.51Wj204/000/A=000000
> 20060715210932,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!
> 3607.12N/08644.43Wj220/005/A=000665/Monitoring 443.450+ 107.2 -
> IRLP 4767
> 20060715212237,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!
> 3607.16N/08644.59Wj346/020/A=000557
> 20060715212432,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!
> 3607.45N/08645.03Wj033/013/A=000593/Monitoring 443.450+ 107.2 -
> IRLP 4767
> 20060715212738,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!
> 3607.16N/08644.59Wj346/020/A=000557
> 20060715212947,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!
> 3607.45N/08645.03Wj033/013/A=000593/Monitoring 443.450+ 107.2 -
> IRLP 4767
> 20060715213045,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!
> 3607.50N/08645.13Wj340/016/A=000636
> 20060715213056,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!
> 3607.54N/08645.14Wj059/011/A=000623
> 20060715213136,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!
> 3607.54N/08644.73Wj094/031/A=000593
> 20060715213252,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAo,KQ4TV-3:!
> 3607.14N/08644.56Wj125/019/A=000511
> 20060715213725,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!
> 3607.50N/08645.13Wj340/016/A=000636
> 20060715213917,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!
> 3607.54N/08644.73Wj094/031/A=000593
> 20060715214040,KE4PJW-9>APT202,NT4UX-3,NT4UX-2,WIDE2*,qAR,KQ4TV-1:!
> 3607.54N/08644.73Wj094/031/A=000593
> 20060715214241,KE4PJW-9>APT202,NT4UX-3*,WIDE2-1,qAR,KQ4TV-1:!
> 3607.14N/08644.56Wj
>
> KQ4TV-1 accounted for the largest delay in my initial posting but
> we see that KG4PID-15 also has some delays not related to a
> digipeater from the data I posted. There are delays taking place
> between the IGates and the APRS-IS. What we need to know is where
> does it happen. Is it the IGate or is it the server the IGate
> connects that delays the packet?
>
>
> 73's de Tim - N8DEU
> Huntsville, AL
>
>
>
>
>
> ----- Original Message ----- From: "Tim Cunningham"
> <tim_cunningham at mindspring.com>
> To: "Robert Bruninga" <bruninga at usna.edu>;
> <brent.hildebrand at gmail.com>
> Sent: Saturday, July 15, 2006 1:47 PM
> Subject: Re: [aprssig] Re: Unreasonable xmission delay
>
>
>> Bob,
>>
>> How can I tell these are the same packet when they are un-
>> numbered? There is a way to tell.
>>
>> In the first example, my mobile was moving and only transmitted
>> this packet one time from that location. It is the only location
>> in a 48 hr period that was transmitted. There is only one match
>> for that packet in that time frame. One packet from one beacon
>> from one location. So, I can only conclude there was one packet
>> and it is the same packet. As I mentioned earlier, there are
>> numerous examples of this problem, but I only listed two examples.
>> Since I manage the configuration at W4GPS-7 I know it operates and
>> digipeats packets instantly with no delay. I can confirm this with
>> my local system and there are NO DCD delays on this digipeater or
>> I would see the problem locally. Here is the packet, a single
>> packet, that was beaconed from one location only.
>>
>>> 20060714194906,N8DEU-12>S4TX1X,WIDE1-1,WIDE2-1,qAo,N8DEU-4:'rEll"9j/
>>> ]"7+}
>>> 20060714195019,N8DEU-12>S4TX1X,W4GPS-7,WIDE1,KU4WW-1*,WIDE2,qAo,KG4P
>>> ID-15:'rEll"9j/]"7+}
>>> 20060714195939,N8DEU-12>S4TX1X,W4GPS-7,WIDE1,NT4UX-2,WIDE2*,qAR,KQ4T
>>> V-1:'rEll"9j/]"7+}
>>
>> The first was heard direct by N8DEU-4.
>> The digipeated packet via W4GPS-7 and KU4WW-1 are picked up by
>> KG4PID-15 and put on the APR-IS at 1min 13sec later.
>> The digipeated packet via W4GPS-7 and NT4UX-2 are picked up by
>> KQ4TV-1 and put on the APR-IS at 10min 33sec later.
>>
>> Now, it is possible for KU4WW-1 and NT4UX-2 to delay the packets.
>> I confirmed with Bruce that NT4UX-2 seems to be working correctly.
>> So, yes there could be a DCD delay somewhere. This is possible and
>> without some hard data from those location this cannot be confirmed.
>>
>>
>> In the second example, I can confidently confirm it is the same
>> packet because the digi will not send a second beacon in the time
>> frame documented. So, if you imply that DCD is a problem, this
>> example will erase that thought by the first direct packet:
>>
>>> 20060715003528,W4GPS-7>APZ19,WIDE2-2,qAo,N8DEU-4:!
>>> 3438.07NS08630.74W#PHG5630/W3,ALn
>>> Huntsville Alabama
>>> 20060715003639,W4GPS-7>APZ19,WIDE2-2,qAo,KG4PID-15:!
>>> 3438.07NS08630.74W#PHG5630/W3,ALn
>>> Huntsville Alabama
>>> 20060715004448,W4GPS-7>APZ19,NT4UX-2,NT4UX-3,WIDE2*,qAR,KQ4TV-1:!
>>> 3438.07NS08630.74W#PHG5630/W3,ALn
>>> Huntsville Alabama
>>
>>
>> The first direct beacon from the W4GPS-7 digipeater is picked up
>> by N8DEU-4 and KG4PID-15 IGates AT THE SAME TIME. The data from
>> KG4PID-15 arrives to the APRS-IS 1min 11sec later. This is very
>> similar to the time delay in the previous example. However,. I
>> could infer that there is probably only an additional 2sec delay
>> at KU4WW-1 in the first example. Again, the data from numerous
>> packets also suggest this same delay direct or via a digipeater.
>> However, this example clearly shows a delay to the APRS-IS from
>> the same direct packet heard by 2 separate IGates. So now if you
>> say how can you be sure these are the same packet, then I would
>> say the problem is far more serious if there were not because that
>> packet is only transmitted every 29 minutes. So, I surmise that it
>> must be the same packet in that sequence or the problem is far
>> worse because the specific beacon in question is on a 29 minute
>> cycle. These are only facts that I can confirm and each example I
>> pull from the FINDU server support the same results when they can
>> be confirmed and classified as the same packet.
>>
>> While there may be DWAIT=0 or PPersistance = 255/SlotTime = 1
>> issues out there. I think the examples I provided point to a
>> secondary problem that happens on the data transfer from the
>> IGates to the APRS-IS. In my examples we can confirm there is an
>> data delay on the APRS-IS in the case between N8DEU-4 and
>> KG4PID-15. There are some similarities at KQ4VT-1, but there could
>> be some variables at NT4UX-2 and NT4UX-3 that I cannot see from
>> here, but from what Bruce has explained it does not seem likely
>> that this is a DCD delay issue. I am sure I can pull a ton of
>> examples on the issue, but since I have no control of how fast
>> data gets from every IGate to the APRS-IS, this one is out of my
>> hands.
>>
>>
>> 73's de Tim - N8DEU
>> Huntsville, Alabama
>>
>>
>>
>>
>>
>> ----- Original Message ----- From: "Robert Bruninga"
>> <bruninga at usna.edu>
>> To: <brent.hildebrand at gmail.com>; <tim_cunningham at mindspring.com>
>> Sent: Saturday, July 15, 2006 11:57 AM
>> Subject: Re: [aprssig] Re: Unreasonable xmission delay
>>
>>
>>>>> tim_cunningham at mindspring.com 07/15/06 11:00 AM >>>
>> Tim,,
>> bear with me. Im just tyrying to see the picture. But two things
>> confuse me. How can you tell these are the same packet, but
>> delayed? Why are they not simply the next beacon? There is no
>> serial number or time stamp in them, so there is no way to tell...?
>>
>>> This is not a DCD issue in the examples I provided.
>>
>> And how can you tell that? If the packet is delayed on RF
>> it is going to be delayed getting to an IGate and FINDU.
>>
>>> In my second example, you can clearly see that two separate
>>> IGates hear the
>>> same direct transmission from W4GPS-7 (UIDIGI IGate with a WX
>>> station
>>> attached). W4GPS-7 digipeats quickly, but in this example the
>>> transmission
>>> is a direct beacon from the digipeater.
>>
>> The exmaples below are all -from- W4GPS-7, no indiciation
>> of a digi -by W7BPS-7.... Maybe I am looking at the wrong packets.
>>
>> Anyway, I dont want to waste your time, but from what I see,
>> I dont see how one can rule out an RF delay through a digi
>> that is hearing too much and it's swuelch just wont close so it
>> can transmit for minutes at a time... Its a simple cause,
>> and a simple fix...
>>
>> Bob
>>
>> What captured my attention was when
>> I went to FINDU to list particular stations that had already been
>> IGated
>> from N8DEU-4. I would observe that the typical "find.cgi" on FINDU
>> would
>> display the N8DEU-4 IGate as the gateway station and then a minute
>> to 10
>> minutes later the delayed packets would enter the system and FINDU
>> would
>> then show a neighboring IGate as the gateway station for the same
>> duplicate
>> packets that are delayed. This delay seems to be taking place
>> after the
>> IGate hears it. There are numerous examples of this issue.
>>
>>> 20060715003528,W4GPS-7>APZ19,WIDE2-2,qAo,N8DEU-4:!
>>> 3438.07NS08630.74W#PHG5630/W3,ALn
>>> Huntsville Alabama
>>> 20060715003639,W4GPS-7>APZ19,WIDE2-2,qAo,KG4PID-15:!
>>> 3438.07NS08630.74W#PHG5630/W3,ALn
>>> Huntsville Alabama
>>> 20060715004448,W4GPS-7>APZ19,NT4UX-2,NT4UX-3,WIDE2*,qAR,KQ4TV-1:!
>>> 3438.07NS08630.74W#PHG5630/W3,ALn
>>> Huntsville Alabama
>>
>> I was beginning to wonder why we needed an IGate in my area when
>> FINDU is
>> showing the neighboring IGate was the gateway median. The reality
>> is the
>> N8DEU-4 IGate is gating the local transmissions first, but the
>> delayed
>> packets from neighboring IGates appear to be the gating system
>> only because
>> they are delayed by over 1 to 10 minutes at which point FINDU does
>> not treat
>> them as duplicate packets due to the extended delay. Now, the
>> problem that
>> Coe, K4COE, originally reported is that these delays are
>> unreasonable. If
>> you are watching APRS through the APRS-IS, no wonder we see mobile
>> beacons
>> oscillating between reported locations on the map. The delays are
>> really
>> huge and thus could not be treated as duplicates because the
>> originating
>> packets are not numbered to identify there sequence.
>>
>> Typically, N8DEU-4 (APRS+SA 2.21) connects to the core servers
>> such as
>> first.aprs.net, second.aprs.net, and third.aprs.net using a
>> filtered feed on
>> port 14580.
>> It looks like the KQ4TV-1 (javAPRSIgate) gate appears to be
>> connected as or
>> through KQ4TV-JS connected through a javaAPRSSrvr server at
>> tennessee.aprs2.net using a filtered feed on port 10141.
>> It looks like KG4PID-15 (UI-View32 V2.03) connects through one of
>> the core
>> server such as third.aprs.net using a filtered feed on port 14580.
>>
>> There is clearly a problem and it appears to happen somewhere
>> between the
>> IGates and how the data makes it to FINDU.
>>
>>
>>
>> 73's de Tim - N8DEU
>> Huntsville, AL
>>
>>
>>
>>
>>
>> ----- Original Message ----- From: "Robert Bruninga"
>> <bruninga at usna.edu>
>> To: <brent.hildebrand at gmail.com>; <aprssig at lists.tapr.org>
>> Sent: Saturday, July 15, 2006 7:04 AM
>> Subject: Re: [aprssig] Re: Unreasonable xmission delay
>>
>>
>> I have not been following this closely, but could it be
>> a DIGI that is not set to true DCD? If the digi is not
>> set to "software" in the KPC3, but is left set for
>> "channel busy", then at some digi sites, the squelch
>> will never close due to continutous QRM and so the
>> packets get held off for minutes at a time? WB4APR
>>
>>>>> brent.hildebrand at gmail.com 07/15/06 2:10 AM >>>
>> I see delays of 2-4 minutes on duplicate reports frequently. Here is
>> a sample; you can the RMC time, and the time the packet was received,
>> and the path data. I don't think it is the Igate program per se.
>> N7WLC and N6EX-3 are running the same program javAPRS, with EX-3
>> being
>> one version newer. W9IF is running APRSD. KB6JAG is running UIView.
>> In this example, reports from N6EX-3 are running 2 to 2.5 minutes
>> behind the original report, with the first instance of each report
>> being very soon after the packet was generated. I saw the same type
>> of delay in the Bay area coming from a UIView station. So is it the
>> IGate, or the APRS-IS? I don't know. I do know, this delay problem
>> is common for the stations I observe.
>>
>> KH2JB-9 2/$RMC:150551,A 2006/07/15 05:52:26
>> I:GPSC18,W6SCE-10*,WIDE2-1,qAR,N6EX-3
>> KH2JB-9 1/$RMC:150550,A 2006/07/15 05:52:06
>> I:GPSC17,N6EX-4*,qAR,N6EX-3
>> KH2JB-9 2/$RMC:150551,A 2006/07/15 05:50:59
>> I:GPSC18,W6SCE-10*,WIDE2-1,qAR,N7WLC
>> KH2JB-9 1/$RMC:150550,A 2006/07/15 05:49:59
>> I:GPSC17,W6SCE-10*,WIDE2-1,qAR,W9IF
>> KH2JB-9 2/$RMC:150546,A 2006/07/15 05:48:17
>> I:GPSC18,W6SCE-10*,WIDE2-1,qAR,N6EX-3
>> KH2JB-9 2/$RMC:150545,A 2006/07/15 05:47:09
>> I:GPSC18,WB6JAR-10,W6SCE-10*,qAR,N6EX-3
>> KH2JB-9 2/$RMC:150546,A 2006/07/15 05:46:59
>> I:GPSC18,W6SCE-10*,WIDE2-1,qAR,N7WLC
>> KH2JB-9 1/$RMC:150544,A 2006/07/15 05:45:53
>> I:GPSC17,WB6JAR-10,W6SCE-10*,qAR,N6EX-3
>> KH2JB-9 2/$RMC:150545,A 2006/07/15 05:44:59
>> I:GPSC18,WB6JAR-10*,WIDE2-1,qAO,KB6JAG
>> KH2JB-9 1/$RMC:150544,A 2006/07/15 05:43:58
>> I:GPSC17,WB6JAR-10*,WIDE2-1,qAO,KB6JAG
>> KH2JB-9 1/$RMC:150542,A 2006/07/15 05:43:20
>> I:GPSC17,WIDE1-1,WIDE2-1,qAR,N6EX-3
>> KH2JB-9 2/$RMC:150541,A 2006/07/15 05:42:40
>> I:GPSC18,N6EX-4*,qAR,N6EX-3
>> KH2JB-9 1/$RMC:150542,A 2006/07/15 05:41:58
>> I:GPSC17,WB6JAR-10*,WIDE2-1,qAO,KB6JAG
>> KH2JB-9 2/$RMC:150541,A 2006/07/15 05:40:58
>> I:GPSC18,WB6JAR-10*,WIDE2-1,qAO,KB6JAG
>>
>>
>>
>> On 7/14/06, Tim Cunningham <tim_cunningham at mindspring.com> wrote:
>>> The problem is not the W4GPS-7 digipeater. The problem is deeper.
>>>
>>> I do not think this is a digipeater delay problem. It is likely
>>> an APRS-IS
>>> or FINDU problem. The delays on the network are horrific. Lately,
>>> I have
>>> been watching FINDU to see how things are working on the network. I
>>> noticed
>>> that all the local traffic here was showing up on FINDU as being
>>> relayed
>>> by
>>> KG4PID and KQ4TV internet gates. Since we just repaired the N8DEU-4
>>> gateway
>>> and put it back on the air in place of the temporary N8DEU-2
>>> gateway, I
>>> was
>>> watching the activity and scratching my head on how the remote
>>> IGates
>>> could
>>> be passing the direct and local traffic before the N8DEU-4 IGate.
>>> Then I
>>> seen Coe's message and realized something else was seriously wrong.
>>>
>>> The following sample packets pulled from FINDU show how much
>>> delay is
>>> being
>>> encountered. There is over 1 minute from one gateway and 10
>>> minutes from
>>> another gateway. I doubt this is a digipeater issue from what I
>>> can seen
>>> happening repeatedly in different directions.
>>>
>>>
>>> 20060714194906,N8DEU-12>S4TX1X,WIDE1-1,WIDE2-1,qAo,N8DEU-4:'rEll"9j/
>>> ]"7+}
>>> 20060714195019,N8DEU-12>S4TX1X,W4GPS-7,WIDE1,KU4WW-1*,WIDE2,qAo,KG4P
>>> ID-15:'rEll"9j/]"7+}
>>> 20060714195939,N8DEU-12>S4TX1X,W4GPS-7,WIDE1,NT4UX-2,WIDE2*,qAR,KQ4T
>>> V-1:'rEll"9j/]"7+}
>>>
>>> 20060715003528,W4GPS-7>APZ19,WIDE2-2,qAo,N8DEU-4:!
>>> 3438.07NS08630.74W#PHG5630/W3,ALn
>>> Huntsville Alabama
>>> 20060715003639,W4GPS-7>APZ19,WIDE2-2,qAo,KG4PID-15:!
>>> 3438.07NS08630.74W#PHG5630/W3,ALn
>>> Huntsville Alabama
>>> 20060715004448,W4GPS-7>APZ19,NT4UX-2,NT4UX-3,WIDE2*,qAR,KQ4TV-1:!
>>> 3438.07NS08630.74W#PHG5630/W3,ALn
>>> Huntsville Alabama
>>>
>>>
>>> KG4PID-15 hears the same packet as N8DEU-4 in the second example,
>>> but yet
>>> there is a 1min 11sec delay. Now, NT4UX-2 digipeater hears the
>>> packet
>>> directly and NT4UX-3 picks it up for KQ4TV-1 where there is a
>>> 9min 20sec
>>> delay before it gets to the FINDU system. FINDU cannot remove these
>>> duplicate packets, because of the amount of time that has passed.
>>>
>>> What in the world is happening here?
>>>
>>> We know that W4GPS-7 digipeats packets immediately. N8DEU-4 is
>>> not a high
>>> speed rocket ship computer. It is a measly P166 running APRS+SA
>>> under
>>> Windows.
>>>
>>>
>>>
>>>
>>>
>>> 73's de Tim - N8DEU
>>> Huntsville, AL
>>>
>>>
>>> ----- Original Message -----
>>> From: "Richard Montgomery" <kb4ytm at gmail.com>
>>> To: "TAPR APRS Mailing List" <aprssig at lists.tapr.org>
>>> Sent: Friday, July 14, 2006 10:02 PM
>>> Subject: Re: [aprssig] Re: Unreasonable xmission delay
>>>
>>>
>>> > Hey Bruce,
>>> >
>>> > Considering he (K4COE) is beaconing every 30 seconds, in 5
>>> minutes time
>>> > he
>>> > has sent an additional 10 packets. That would be really strange
>>> for a
>>> > digi
>>> > to hold that particular packet for 5 minutes, when he has sent
>>> that > many
>>> > more.
>>> >
>>> > Looks like W4GPS-7 is a UIDigi firmware digi with a WX station
>>> > connected.
>>> > Possibly a problem with a tnc2 doing both? Too much data from
>>> K4COE?
>>> >
>>> > Let me know if you need any logs or anything from down this way.
>>> >
>>> > Richard
>>> > KB4YTM
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > Bruce W. Martin, KQ4TV wrote:
>>> >> I received the following information today.
>>> >> NT4UX-2 is a UIdigi v1.93 using N8DEU's reccomended settings.
>>> >> KQ4TV-1 is a javAPRSSrvr 3.11b03 Igate.
>>> >>
>>> >> Can anyone shed light on what can be done to eliminate 5
>>> minutes of
>>> >> delay
>>> >> for 100 miles of 3 hops.
>>> >>
>>> >> Bruce, KQ4TV
>>> >>
>>> >>
>>> >> On Jul 14, 2006, at 1:57 PM, Case, Coe wrote:
>>> >>
>>> >>> Bruce:
>>> >>>
>>> >>> Please evaluate the following raw data from FINDU.
>>> >>>
>>> >>> 20060714122325,K4COE>S4TS1V,WIDE1-1,WIDE2-1,qAo,N8DEU-4:`rAf!
>>> hW>/]"3r}
>>> >>> 20060714122427,K4COE>S4TR9X,WIDE1-1,WIDE2-1,qAo,N8DEU-4:`rB
>>> \nsF>/]"3r}CERT,SkyWarn,RACES,ARES
>>> >>> ....
>>> >>>
>>> 20060714122815,K4COE>S4TS1V,W4GPS-7,WIDE1,NT4UX-2,WIDE2*,qAR,KQ4TV-1
>>> :`rAf!hW>/]"3r}
>>> >>>
>>> 20060714122941,K4COE>S4TR9X,W4GPS-7,WIDE1,NT4UX-2,WIDE2*,qAR,KQ4TV-1
>>> :`rB\nsF>/]"3r}CERT,SkyWarn,RACES,ARES
>>> >>> It appears there is a 5 minute delay in nt4ux-2 and kq4tv-1
>>> >>> retransmission and igate posting to the internet. It is
>>> causing >>> FINDU
>>> >>> to overwrite current data with data and locations that are 5
>>> minutes
>>> >>> old. Two hops should be a worst case 20 sec delay, not 5
>>> minutes.
>>> >>>
>>> >>> If you are working/Tracking vehicle to vehicle (not via the
>>> >>> internet),
>>> >>> then getting to the first i-gate means nothing, you still
>>> need to
>>> >>> wideN
>>> >>> to get to the other vehicle's mobile APRS. Besides, as you
>>> can see
>>> >>> from
>>> >>> my track displays over the last 3 weeks, I travel through
>>> area's that
>>> >>> even three hops do not get to any digi/igate. (Colorado, South
>>> >>> Carolina, Louisianna as endpoints)
>>> >>>
>>> >>> Thanks,
>>> >>>
>>> >>> K4coe
>>> >>
>>> >>
>>
>
>
_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
More information about the aprssig
mailing list