[aprssig] Digipeater Dupe Suppression setting?

Thu Apr 9 12:05:49 EDT 2009

Back in the day, 30 seconds seemed like a nice number.  But really, in the
context of rapid messaging it makes sense to lower it.  8 seconds does seem
a little slim though.  I've never charted the life span of a given packet,
but considering that most packets are 1 second long and could be repeated 7
times, 8 seconds seems reasonable.  But if there are other packets on air,
then surely some digipeated copies would be delayed if DWAIT isn't set
properly on the digi's, so let's just assume a worst case of 14 seconds on
air.  That gets us to less than 16 seconds (less than two messaging
retries).

So shall we push for UIDIGI dupe timer setting of 15 seconds?  And at the
same time push for DWAIT to be 0?  This seems a fair compromise between 8
second retries being possible on a simplex link, and 16 second retries
possible on a digipeated link.

Funny thing is that if we could guarantee hops < 4, or we could guarantee
DWAIT 0, we could use dupe time of 7 or 8 seconds and it wouldn't affect
messaging.
Wes
On Wed, Apr 8, 2009 at 21:40, Bob Bruninga <bruninga at usna.edu> wrote:

> 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
>

-- 
Wes
---
Where there's silence, there is no Hope.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20090409/a18e7fb6/attachment.html>