[aprssig] Draft Copy of Thesis on APRS

[Kenneth Finnegan]

Viscous delay digipeating is a very different concept than the APRS dedup
behavior. If you set the dedup timer to be 4-6 seconds, and there happens
to be any viscous digis on the network, it would disastrously double the
network load.

Viscous delay is relatively controversial. I haven't been able to even
convince myself that it is definitely a good thing.

I don't follow the argument for why you would want to allow identical
packets through the network more often than every 30 seconds. What's the
advantage of allowing repeated packets every 6 seconds on RF?

Kenneth Finnegan, W6KWF
On Dec 12, 2014 8:51 AM, "David Huff" <david.huff at rockwellcollins.com>
wrote:

> "6.3 Deduplication Behavior
> As the APRS network grew and the density of digipeaters and stations
> increased in the late
> 1990s and early 2000s, it became increasingly important that digipeaters
> don't \ping-pong"
> packets between themselves.
> To prevent this, a new behavior was implemented in digipeaters where an
> "aging hash table" was used to store a hash of each
> packet for a limited length of time *(this period is never formally
> specif ed, so the author suggests 30 seconds be used as it is a popular
> choice)."*
>
> I was under the impression the deduplication hash was specified as
> recommended 4-8 seconds in APRX <
> http://wiki.ham.fi/Viscous_APRS_Digipeater>, and determined by DWAIT in
> other digipeaters. <
> http://www.tapr.org/pipermail/aprssig/2014-May/043331.html>.
>
> The 30 seconds here might be too long for RF.  The APRS-IS (internet)
> folks also have a duplication filter in the APRS-IS system that is about 30
> seconds.  I suggest you split the RF deduplication filter from the APRS-IS
> (internet) deduplication filter.  Section 6 is still mostly RF based ideas,
> therefore 30 seconds sounds high for RF.
>
> We have had many digipeaters store a position for too long before
> repeating it, which causes your position to "jump back and forth" as an
> example.  the internet duplication check should be separated from RF.
> Thanks
> Dave
> w0im
>
>
>
> On Wed, Dec 10, 2014 at 11:14 AM, Curt Mills <curt.we7u at gmail.com> wrote:
>>
>> Morse code ID:  I mentioned that because it is legal to do so, not
>> because it would be recommended.  You could also do an ID to no path,
>> which would also be legal.
>>
>> !DAO! extension:  It isn't implemented by a lot of packages.  We
>> haven't implemented it in Xastir yet.
>>
>> The nice thing about the SS aliases is that you can flood a state with
>> alerts intended just for that state.  Weather and Amber Alerts would
>> be two good instances.
>>
>> As far as Version 2.0 versus 2.2 of the spec:  Most of the TNC
>> implementations (not talking about APRS trackers) were done prior to
>> that, so only support 2.0.  I seem to remember that there were both
>> digipeater limits and changes to the flags in the new spec, which were
>> hotly debated after it came out (on the lists), and most chose to not
>> support 2.2 at the time.  So then most of the new tracker
>> implementations only supported 2.0 after that as well.
>>
>> Regarding the APRS spec again:  Version 1.0 was ratified.  Addendum
>> 1.1 was ratified (which consists of a bunch of web pages, a difficult
>> thing to get my head around WRT a spec).  Addendum 1.2 was not
>> ratified as far as I know, but there are several things in there that
>> have been implemented by later versions of APRS software.  So...  To
>> get your head around the entire spec, you need 1.0, 1.1, and maybe at
>> least parts of 1.2.  I think the addendums address a few of the
>> concerns in your paper.  !DAO! was in the addendums I think, so I'm
>> sure you've considered them.
>>
>> Good luck Friday!  Excellent paper by the way!
>>
>> --
>> Curt, WE7U
>> _______________________________________________
>> aprssig mailing list
>> aprssig at tapr.org
>> http://www.tapr.org/mailman/listinfo/aprssig
>>
>
>
> --
> Thanks,
> Dave
>
> David.Huff at rockwellcollins.com
> CS Reliability, Maintainability, & Safety
> 319.295.8949
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20141213/022f1303/attachment.html>