<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
The primary delay I see is ww6jc-2, he's a "local" only 30 miles away.
The others are intermittant hits at best due to their distance from me-
my hope was to show that the problem just didn't lie with ww6jc's
station. I did contact him last night by phone. He's running an icom
706 (overkill) hooked to a kpc3plus v9.0 firmware. His PC is running
uiview... not sure of the speed of his PC, but judging from the jist of
the conversation last night, he's gone gung ho into aprs, and I'm sure
he hasn't skimped on his PC. I seriously doubt he's unplugging the
serial cable from his PC during all (or any) of the times in question.<br>
<br>
So, why would a packet heard by him at the same "stage" of it's
lifecycle (ie number of hops) be delayed? <br>
<br>
For example, look at these two:<br>
20050429230931,KD4RDB-14>SS5V5U,KC4PL*,WIDE2-2,qAR,KC4PL-2:'l24l"/j/]"4I}<br>
20050429231204,KD4RDB-14>SS5V5U,KC4PL*,WIDE2-2,qAo,WW6JC-2:'l24l"/j/]"4I}<br>
<br>
KC4PL heard it and did two things... he digipeated on air, and igated,
ww6jc also heard kc4pl's digipeat and igated it... 153 seconds later.
It is possible that kc4pl digipeated the packet late.... becuase his
TNC is in kiss mode and may not have seen dead air for nearly 3
minutes.... causing ww6jc to see the packet eventually... yeah right....<br>
<br>
20050429113413,KD4RDB-14>SS5V7R,AA4QI-1,W4ACS-10*,qAR,KG4YZY-11:'l;Dl"ej/]"5#}<br>
20050429113516,KD4RDB-14>SS5V7R,KC4PL*,WIDE2-2,qAo,WW6JC-2:'l;Dl"ej/]"5#}<br>
In this pair, kg4yzy-11 (400 miles away) made it to the internet
first.... before ww6jc-2 by 63 seconds. This one is funny b/c I was
much closer to ww6jc than kg4yzy.<br>
<br>
20050428174206,KD4RDB-14>SS5U8T,K2JLB-1,KC4PL*,WIDE2-1,qAR,KC4PL-2:'l0~o57j/]"4K}<br>
20050428174905,KD4RDB-14>SS5U8T,K2JLB-1*,WIDE2-2,qAo,WW6JC-2:'l0~o57j/]"4K}<br>
In this one I was heard by k2jlb and digipeated. kc4pl's digined
software digipeated the packet and passed it along to his ax.25
connected javaserver. That copy of the packet was delivered timely.
On the other hand, the copy that was digipeated by k2jlb-1 was also
heard by ww6jc direct, and he igated it 419 seconds later. Now, how
can he hear the same packet that another station heard and igated and
deliver it late? Once it was digi'ed by k2jlb, both igates heard it
direct, one igated timely the other late.<br>
<br>
Here's the same situation, 108 seconds apart....<br>
20050428155958,KD4RDB-14>SS5T1P,K2JLB-1,KC4PL*,WIDE2-1,qAR,KC4PL-2:'l3NoTFj/]"4N}<br>
20050428160146,KD4RDB-14>SS5T1P,K2JLB-1*,WIDE2-2,qAo,WW6JC-2:'l3NoTFj/]"4N}<br>
<br>
<br>
Just to keep me honest, I pulled some packets from when I drove home
from a meeting monday night ( 1am June 7th utc ). During this time I
can definitely say that I was moving the whole time, not parked.<br>
20050607013151,KD4RDB-14>ST0R6R,N4BAM-3,WIDE1*,WIDE2-2,qAR,KC4PL-2:'mXk!pGj/]"4o}<br>
20050607013522,KD4RDB-14>ST0R6R,N4BAM-3,WIDE1*,WIDE2-2,qAo,WW6JC-2:'mXk!pGj/]"4o}<br>
Both of these packets were heard by a plain jane digipeater that was
approx 10 miles west of my position. Both kc4pl-2 and ww6jc-2 heard
the packet from that digi and ww6jc was late by 211 seconds.<br>
<br>
20050607013400,KD4RDB-14>ST0S9R,N4BAM-3,WIDE1*,WIDE2-2,qAR,KC4PL-2:'lW "4Gj/]"5"}<br>
20050607013802,KD4RDB-14>ST0S9R,WIDE1-1,WIDE2-2,qAo,WW6JC-2:'lW "4Gj/]"5"}<br>
In this pair, ww6jc-2 heard me direct (I ended up driving within 1 mile
of his house on my trip), and was still late by 242 seconds.... kc4pl
heard me via 1 digipeater hop and delivered on time. This is similar
to the packet I listed before when it made it to a Florida igate before
the local guy delivered it to aprs-is.<br>
<br>
I understand what you are saying about getting the guys to log my
packets... but with observations of this same situation coming in from
Washington state and Canada, I'd say it's not ww6jc's fault... or the
fault of any RF digi in between his station and mine.... there are too
many variations in the RF world. I've shown enough here to say that RF
is not causing the delays - even when I am heard by ww6jc direct, he's
still late. I've shown that when ww6jc and kc4pl hear the same packet
from either n4bam digi or k2jlb digi, ww6jc consistently delivers
late. Could it be that the montana.aprs.net server (that ww6jc is
connected to) is overloaded, or suffering from intermittant connection
problems upstream that cause packet bunching?<br>
<br>
But I'm game for logging the packets.... when logging packet in Xastir,
there is a time stamp inserted every so many seconds.... does uiview
timestamp packets too? I'm not running uiview at the moment to
check. If it does, I'll ask ww6jc to turn it on and later, I'll
compare his logs to findu. If ui-view does not timestamp packets, can
anyone suggest a way to time stamp received packets under windows?<br>
<br>
Wes<br>
<br>
<br>
<br>
<br>
<br>
AE5PL Lists wrote:
<blockquote
cite="mid478F6623898BBC4DBD692A223D28298A165148@amewebsrvr.webametx.local"
type="cite">
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: Wes Johnston
Posted At: Wednesday, June 08, 2005 8:49 AM
Subject: Re: [aprssig] IGATE delays
I have seen packets delivered ontime by qAR kc4pl-2,qAo
W4HNK-1,qAR WA4SAS-11,qaO w1gre, and many others.
I have seen packet delivered late by qAo,WW6JC-2, qAR KG4YZY-11
If anyone else has seen these problems, I'm glad to analyze
your tracker.... just send me the callsign.
ww6jc-2 is connected to montana.aprs.net:14580.
Anyone have any clues about this? I'm gunna guess this is a
aprs-is tier problem, but really haven't a clue.
</pre>
</blockquote>
<pre wrap=""><!---->
Doubtful. WW6JC-2 is the only one connected to montana.aprs.net None
of the Tier 2 servers are more than 1 server away from the core nor do
they have the convoluted multiple paths made popular with aprsD in
earlier years. It is possible for packets to take 90+ seconds to go 3
hops: a busy channel and a digi (like a Kenwood D700) set with a
persistence other than 255 and a slottime other than 0 can cause
extensive delays. I have seen the Kenwood hold packets for digipeat up
to 30 minutes when it was set to DCD on band A and B!
I have seen this type of delay with IGates directly connected to the
core servers in the past. In those instances, it appeared to be an
issue with the client software. While I am not sure if their was a
resolution, the packets were seen at the station on time but not passed
upstream. This could be because of improper Nagel algorithm settings,
in-stream routers doing bandwidth shaping, etc.
Instead of trying to guess the cause (in all likelihood wrongly) here on
the SIG, why don't you contact each individual IGate operator of concern
and have them log when they see your packets. KG4YZY is running
javAPRSSrvr/javAPRSIGate and he can log both the packets seen on RF and
received via APRS-IS for comparison. Many times, they can also look at
the actual TNC data flow for further confirmation of where the problem
may lie.
73,
Pete Loveall AE5PL
<a class="moz-txt-link-freetext" href="mailto:pete@ae5pl.net">mailto:pete@ae5pl.net</a>
_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a>
<a class="moz-txt-link-freetext" href="https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig</a>
</pre>
</blockquote>
</body>
</html>