[aprssig] IGATE delays
AE5PL Lists HamLists at ametx.comWed Jun 8 14:18:57 UTC 2005
- Previous message: [aprssig] IGATE delays
- Next message: [aprssig] IGATE delays
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> -----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. 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 mailto:pete at ae5pl.net
- Previous message: [aprssig] IGATE delays
- Next message: [aprssig] IGATE delays
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
