[aprssig] Poor Object Performance for Events

Robert Bruninga bruninga at usna.edu
Fri Nov 26 00:06:11 EST 2004


This email describes the differences in OBJECT performance
during an event between software that uses the original decaying 
APRS  algoirthm and  some follow-on clones that use a simplistic 
fixed rate beaconing .  (A 50% reliability channel is assumed):

Original APRS Decay method: 
    Latency  averages 15 sec, average packet rate 6 to 10 per hour.

Simplistic Fixed beacon rate method:
    Latency averages 20 minutes at a packet rate of  6 per hour
    Latency averages 12 minutes at a packet rate of 10 per hour
    Latency averages   4 minutes at a packet rate of 30 per hour


Notes:
1) For the Decay Method, there are *no* user settings.  It
    always works, it always gives very short latency under
    all applications, both immediate and routine.  AND it also 
   averages fewer packets in the  long term too.

2) Fixed rate systems depend on intelligent User settings
    depending on application, number of users, type of net
    and channel loading. And the disasterous results of
    poor settings and user errors can do an order of magnitude's 
    worth of damage to communications reliability.

3) ANY attempt to reduce latency in the fixed method has an
    exactly opposite degrading effect on channel load.

There is just not one single advantage to Fixed Rate beaconing
systems on APRS other than programmer simplicity.

As a 24/7 or Internet User, you may never have experienced the 
poor performance of these fixed rate systems in the field, but
an average latency of 12 to 20 minutes to see a new, or moved
object is unsatisfactory for any real-time event.  Any attempt to
 reduce this poor latency by increasing the OBJECT beacon 
rate has disasterous effects on the reliability of the channel.

Remember, APRS was designed for tactical-real-time evnts
for the rapid dissimination of usable data about everything
at an event.  A latency of even a few minutes is not acceptible.

For the purpose of analysis, a fixed 10 minute Object Beacon 
rate was assumed and a channel collision rate of 50%.  To
account for the variable rate of the decay  method, a total
of 16 objects was assumed with 1/4th not moving during a
4 hour event, 1/4th moving twice, 1/4th moving 4 times and
1/4th moving 8 times.

You should think twice or carefully plan how you will use your
software in the field.  If  you need to keep track of lots of 
objects (Troops at a camporee, or assets at a marathon) you may
need to consider other software just for the objects or suffer
an order of magnitude worse channel performance.

Fixed rate beaconing which does not distinguish new relevant
info from old stale info has no place on a viable real-time 
immediate net.

de WB4APR, Bob





More information about the aprssig mailing list