On Wed, Jun 9, 2010 at 9:54 PM, Tim Cunningham <[email protected]> wrote:
> It is not a good idea for a digipeater to delay a packet by 15 seconds. 15 seconds would be a very long stand by time. In reality, the hold off time would only need to be a few seconds. I would think that 5 seconds would be a top end standby time waiting for a main digipeater to make noise. With a proper digipeater configuration, the main digipeater should key up immediately after hearing a packet that is asking for a hop. No hold off or wait time. The delay before a SMART fill-in digipeater would step up should be in the neighborhood of a second or two at most. > We have enough delays imposed by digipeater/IGate owners who are > unaware of their own mis-configurations. We aren't talking about a misconfiguration here or a problem. Those need to be dealt with and fixed. The concept here is an advanced smart digipeating routine. > A WIDE1-1 does not hear everything and a mobile station > may hit a WIDEN-n that the WIDE1-1 does not hear. This is true... if the fill-in doesn't hear the digipeat from a far off main digipeater, then it will digipeat the packet in an attempt to help the low powered tracker to get into the network. > Delaying a packet can cause a ping pong effect on the APRS-IS > as well as rob RF network bandwidth. Actually the routines that are used by the current WIDEn-N routines have a built-in anti-dupe routine. The proper implementation will watch for duplicates for close to 30 seconds. By having the smart fill-in digipeater configured to delay for a second or two, the main digipeater anti-dupe routine would catch the occasional instance where the fill-in might accidentally miss hearing a main digipeater, and send a fill-in hop request. Sending a packet immediately or delayed by a second or two does not rob network bandwidth, and by NOT digipeating when a fill-in request is not needed, you are actually keeping the RF network cleaner. > This problem is bigger than you may realize. And the solution may be cleaner than you realize... let's keep discussing. I've gone over all of the issues you are bringing up, but through discussion, we might raise issues that haven't been brought to light yet. > Currently, there are several issues we are trying to educate users in our > outlaying area. Some packets are delayed by 2-3 minutes at some digipeaters > and I-Gates. Actually, what we have been able to find is that the issue seems to be limited to Kantronics KPC-3 TNCs running in KISS mode at i-gates. We went through a lot of this a number of years ago, and we also thought it might be some digipeaters holding off on passing the packets along through the network due to waiting for a clear channel or such, but in depth investigation into the delayed packets, always brought us back to the i-gates, and each time they were KPC-3 units running in KISS mode. > What happens on the APRS-IS stream is the initial packet is > heard and then 15 seconds, 30 seconds, or even 2-3 minutes later that same > packet finally makes it through another path to the same IGate that > initially passed it or another distance IGate. You've got some bad information there... a packet delayed by 15 or 30 seconds won't make it in to the APRS-IS stream. javAPRSSrvr is probably the most common APRS-IS server software in use. The default dupe time is 30 seconds. > In a busy APRS network the > problem is compounded. What you see happen on a map is a stations position > bouncing back and forth. It also takes up addition RF and Internet > bandwidth. The load on the network doesn't really affect the ping-pong issue, and it does not take up additional RF bandwith that we have been able to observe this far. All of the data that we have been able to collect to date points to the i-gate station delaying between reception from RF to passing the information to the APRS-IS server. The ping-pong effect is only observable through clients that are displaying data gathered from the APRS-IS. Stations observing the RF network do not observe the delayed packets as they are not digipeated back into the RF network after being delayed. > The APRS Paradigm changes from 2005 stopped a lot of ping pong > effect by eliminating RELAY an WIDE support because some TNC's could not > substitute their own callsign to know they had already digipeated the > packet. Actually that's not how the changes reduced the load on the RF network, and the ping-pong effect seen via the APRS-IS delayed duplicates is totally different than the multiple copies of the same packet that could be seen due to the use of the old RELAY and WIDE aliases. The multiple copies seen was due to the routines being used not keeping track of which packets that it had handled. The ping-pong effect observed on the APRS-IS is caused by delayed packets being injected into the APRS-IS after subsequent packets have already been delivered to the APRS-IS. The RF based issue was that you could see multiple copies of the same packet being handled by the same digipeater in rapid succession. > Adding a packet delay because a station does not think a signal was > digipeated can in effect produce some of the same ping pong problems. If 2 > digipeaters impose a 15 second delay the cumulative delay can then become a > little over 30 seconds depending on the amount of traffic in an area and > defeat the dupe timer in many digipeater settings. First problem with this concept is that 15 seconds for hold off is FAR too long. Second, to have two 15 second delays imposed would mean that someone is using a path of WIDE1-1,WIDE1-1,... The SMART fill-in digipeater maximum delay time would HAVE to be set well below the standard RF dupe timer value. The SMART fill-in digipeater hold off would ONLY apply to fill-in stations acting upon the WIDE1-1 alias. A main digipeater that acts upon WIDEn-N, where WIDE1-1 is a supported subset by default would never delay. Only the low level fill-in digipeaters would use the hold-off waiting to see if another digipeater acts first. > We see this type of ping pong packet activity every day, so please do not do > this. Then obviously the delays added by SMART fill-in digipeaters are not the source of your woes, since they don't exist yet. The ping-pong issues are caused by existing problems. Get after chasing down and fixing the problems that you currently have! > If the station sending the signal wanted a WIDE1-1 to handle their > packet they would have put it in their path. It is the sending stations > decision on how they choose to route their packet. Yes, and the purpose of the WIDE1-1 path statement is to allow low powered stations to ask for help from fill-in digipeaters IF required. The reason for using WIDE1-1 and not some other alias is so that the high level digipeaters can act upon the path as well, and the packet does not HAVE to go through a fill-in digipeater before being handled by the rest of the network. There is no guarantee that the packet will be handled by a fill-in digipeater. In an area where the high level digipeater has great coverage, there's no need for a fill-in digipeater, and the packet simply gets handled by the main high level digipeater. > The first way I notice > the problem is when I see a distance IGate constantly IGating a packet from > our local network instead of our local IGate according to FINDU. When we > query the FINDU server to pull a history of time stamped data, the problem > can almost always be attributed to delays at digipeaters and/or IGates. If you can find examples where the delay can be attributed to a digipeater and not an i-gate, I'd love to see it. There were a number of us looking for such examples and we couldn't find any. I'm always open to finding more bugs, and passing the issues on to the manufacturer. > When > we alert the digipeater/IGate owner about the issue and they are usually > unaware of it. In some cases the IGate operators actually think their IGate > system is faster at moving the traffic to the APRS-IS because the basic > FINDU screen shows their IGate posting the traffic. When you query FINDU to > review the data, the answer becomes very clear. It is not faster, but it is > much slower due to delays. It's difficult to detect such delays unless you look into the packets in detail. The easiest way to find the problem is when the packets contain a human readable timestamps. Compressed packets or others with less obvious data included make it much harder to observe the problems. James VE6SRV
