[aprssig] EchoLink APRS-IS Ojbects Mothballed

Robert Bruninga bruninga at usna.edu
Tue Aug 4 09:49:19 EDT 2009


> Your [original] 8, 16, 32, 64 and 128 
> second [APRS  decaying retry] algorithm 
> has a nice binary ring to it, but it 
> isn't necessarily better. It's just different. 

It is better because it works across-the-board in all situations
without user messing around with parameters and then forgetting
and having wrong parameters in other situations.  The Decay
Algorithm works great in real-time events with immediate
delivery needs and long-term routine where slower, but ultimate
delivery was desired.

I guess it depends on what "better" means.  The original intent
of APRS was to have something that worked any-time, anywhere,
and did the best and most consistent job at delivering real-time
information fast, while not cluttering the network with old
info.
In otherwords it did not require a highly trained or clever
operator to figure out the best settings under each
circumstance.  And on the flip side, then the network be
vulnerable to incorrect sesttings most of the rest of the time.

> UI-View does a pretty good job with retries. 
> It allows you to set the retry interval and 
> how many times to try, and whether to "retry 
> on heard" and whether to expire and stop 
> after X minutes. 
>
> e.g. set retry interval to 10 seconds, try 5 times...
> If I told UI-View to retry 10 times, the retry 
> interval couldn't be any 
> shorter than 20 seconds.

Yes, it is flexible, in the hands of someone who is cognizant of
the network impacts of his settings, but that sometimes leads to
indfficiencies due to the human nature of error.

> If I told it to retry 100 times, the retry 
> interval couldn't be any shorter than 200 
> seconds or 3 mins and 20 seconds. Obviously, 
> setting it to values like this wouldn't lead 
> to either quick delivery or quickly 
> letting you know the message hadn't been delivered.

I do not mean to sound critical when I raise these point, I only
bring them up to help provide some background to anyone who
might want to some day write a current APRS client program so we
can move onward.

Bob, WB4APR





More information about the aprssig mailing list