| |
ZL3AI > APRDIG 28.08.06 23:08l 101 Lines 3688 Bytes #999 (0) @ WW
BID : 8676-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 26 #27, 1/1
Path: DB0FHN<DB0MRW<DK0WUE<DB0RES<TU5EX<F3KT<IW2OAZ<ZL2BAU
Sent: 060828/2104Z @:ZL2BAU.#87.NZL.OC #:907 [Waimate] $:8676-ZL3AI
From: ZL3AI@ZL2BAU.#87.NZL.OC
To : APRDIG@WW
Today's Topics:
1. So. Ohio (J D Delancy)
2. RE: Delayed packets (yet again) (Cap Pennell)
3. RE: Delayed packets (yet again) (AE5PL Lists)
----------------------------------------------------------------------
Message: 1
Date: Sat, 26 Aug 2006 10:58:15 -0400
From: "J D Delancy" <W1JD_at_drix.net>
Subject: [aprssig] So. Ohio
Is APRS not in use in Southern Ohio? Travelled last week on I-70 and
between Columbus OH and Charleston WVA, there was no apparent APRS activity
or stations
jd
------------------------------
Message: 2
Date: Sat, 26 Aug 2006 09:17:20 -0700
From: "Cap Pennell" <cap_at_cruzio.com>
Subject: RE: [aprssig] Delayed packets (yet again)
Adrian reports his KG6MRC-1 San Francisco IGate (and fill-in digi), which
uses UI-View32 with a direct serial port connection to a Kantronics KPC-3+
in KISS mode, and occasionally displays this "delay porting to APRS-IS"
problem, can be cured (for a while) by ONLY a TNC power cycle or ONLY a
laptop power cycle or both. A useful clue? Hope so.
73, Cap KE6AFE
------------------------------
Message: 3
Date: Sat, 26 Aug 2006 11:31:03 -0500
From: "AE5PL Lists" <HamLists_at_ametx.com>
Subject: RE: [aprssig] Delayed packets (yet again)
>From: john b. leonard, jr.
>Posted At: Saturday, August 26, 2006 9:14 AM
>Subject: RE: [aprssig] Delayed packets (yet again)
>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.
The delays are not caused by a "characteristic" of the IS system (see
below).
>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.
We are talking less than 5 seconds total of which 95% is taken up in the
transmission/reception on RF. The servers do a 30 second dupe check to
eliminate these dupes caused by multiple IGates seeing and gating the
same packet to APRS-IS. Internet delays are normally under 100 ms with
peaks towards 1 second when bandwidth shapers are in use.
So what does cause these excessively delayed packets (over 30 seconds)?
As has been discussed:
1: Malfunctioning/misconfigured digipeater causing excessive RF delays.
2: IGate connected to a full APRS-IS feed but unable to keep up.
3: Malfunctioning serial port or driver (this includes USB-serial ports,
improperly configured AX.25 drivers, etc.).
4: Malfunctioning IGate or server software causing packets to be either
delayed or duplicated inside of the software.
5: Someone playing log files while connected to RF or APRS-IS.
6: And more.
I would venture to say the first three are significantly more prevalent
than the others. None are a "characteristic" of APRS-IS but they are
anomalies of improperly configured APRS software and hardware. The other
comments made in this thread are good hints for finding the cause of why
that specific IGate is exhibiting issues. These types of delays should not
be ignored because they are generating anomalies in the packets on APRS-IS
and they are signs of either improper configuration or operation.
73,
Pete Loveall AE5PL
mailto:pete_at_ae5pl.net
------------------------------
aprssig mailing list
aprssig_at_lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
End of aprssig Digest, Vol 26, Issue 27
Read previous mail | Read next mail
| |
