[aprssig] Re : Digipeater Dupe Suppression setting?

Thu Apr 9 11:36:26 EDT 2009

Thanks Bob for your help and all informations.
 73 de F4ARO Leszek
12 place de la gare
F-57100 Thionville
http://f4aro.free.fr
www.franceaprs.net 

________________________________
De : Bob Bruninga <bruninga at usna.edu>
À : aprssig at tapr.org
Envoyé le : Jeudi, 9 Avril 2009, 3h40mn 12s
Objet : [aprssig] Digipeater Dupe Suppression setting?

This came up on another group.  Maybe it is time for all APRS network guru's to take a new look at this parameter:

> What is the best setting for Fill-In 
> digipeater for Duplicate Packet Suppression 
> Interval (seconds)?  The default setting 
> is 28 seconds. [Do] I need to change to 30 ?

Background: [EDUCATION OPPORTUNITY for everyone}

The interval only has to be large enough to ignore duplicate packets still bouncing around the digis.  Under the New-N paradigm where people are using hops of 2 or 3 or less, there are rarely any long delayed packets, AND it is impossible to  have a loop on a WIDE2-2 packet.t

This parameter does not filter out obnoxious high-rate mobiles that are moving.  It does not even filter out even 30 second mobiles that are parked!  (but there should not be any 30 scond mobiles anywhere except for occassional special events where there are only a few such mobiles anyway.  Most APRS events have too many mobiles already to even allow 1 minute rates, much less, 30 second ones.

The main damage done by this parameter are the fast-response message retries implemented in the original APRSdos, Xastir APRS+SA, APRSscs and the other programs that properly impemented the fundamental APRS decay algorigthm. (I think UIview compromised half way and I think attempts a 30 second retry?)  These programs using the original algorithm really make messages fly because they retry the first lost packet in only 8 seconds.  Then again in 16 seconds, and so on.  These properly designed systems allow rapid message exchanges in seconds even in the presence of lost packets.

Compare this to most of the other brain-dead programs that only implemented fixed-rate or 1 minute retries.  In a 50% collision system, the message latency in these more popular programs is on the order of a minute PER LINE of message.  These brain-dead APRS systems are what gives APRS a bad name for real time messaging.

But the original systems in the presence of a 50% collision rate have only a latency of about 8 seconds per line.

That is, until people started cranking up that DUPE filter to 28 seconds.  As noted before, this really does not cut down on any proper position report dupes (the majority of packets), but it kills this rapid retry-design of the original APRS system.  This slows even the properly implemented decay-rate systems from a latency of 8 seconds to almost a full minute just like the brain dead systems.

But, these properly implemented APRS systems are in such a minority, that no one really notices or cares.  The majority of users just accept the fact that APRS (as they see it in their software) has significant delays in real-time messaging.

I welcome corrections to my observations

CONCLUSION:

So no one really knows what is the correct value of that setting in any particular area.  Of course , if it is too small, it is a disaster because excessive-hop packets can LOOP back through a given repeater.  BUT!  Under the New-N paradigm where most packets are only going 2 hops anyway, it is impossible for a packet to loop back!  So maybe after 10 years of the WIDEn-N system, and now that we are making progress on the New-N system, maybe it is time to back off on this parameter and allow those properly implemented programs to double if not quadruple their throughput on real-time keyboard exchanges?

So, I would call on sysops (who REGULARLY MONITOR THEIR DIGI OUTPUTS) to experiment with cutting this value back to 7 seconds.  The good news is that this could allow back the originally designed rapid messaging of APRS (but only for those original systems that properly implemented it).  If 7 seconds still had some proplems, just cutting it back to 22 seconds would at least let the 2nd retry through (8+16=24 seconds).

So the good news is that we can fix this parameter in the network to get back rapid message exchange, but the bad news is that it won't make any difference because 95% or more of the APRS programs are brain dead and ignored the decay algorithm that accelerates new data over old data and couldnt take advantage of it even if we fixed the network.

But we have to start someplace.

I welcome other obsrevations and data on the setting of this parameter.

Bob, WB4APR

_______________________________________________
aprssig mailing list
aprssig at tapr.org
https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20090409/b5e40259/attachment.html>