[aprssig] Poor real-time MSG performance

[Robert Bruninga]

Poor real-time MSG performance:

This email describes the differences in MESSAGE performance
during an event between software that uses the original decaying 
APRS  algoirthm with Smart Acking  and many APRS clones that 
use a simplistic fixed rate beaconing and simplistic acking..
(This is in a local event with 50% collisions)

Decay Method: 
    Latency  for delivery averages 15 sec per line
    Latency for receipt of ACK averages 30 sec per line
    Average retries, 9 in first 30 minues. 2 per hour thereafter.

Fixed Method:
    Latency for delivery averages 2 minutes per line.
    Latency for receipt of ACK averages 4 minutes per line.
    For more than 1 hop, probability of getting an ack fall
    to practically zero..
    Fixed systems typically use 5 retries and then quit.

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 events and routine.  
    Users can't screw up the network with bad settings.  AND 
   it also averages fewer packets in the  long term too.  And
   ACKS are more reliable due to smart acking.

2) Fixed rate systems depend on intelligent User settings
    depending on application, number of users, type of net
    and channel loading. And the results of user errors and
    poor settings can do significant damage to the network's
    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 any advantage to Fixed Rate message
transmission on APRS other than Programming 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
a latency of 4 or more minutes PER LINE of message text is 
unsatisfactory for a real-time event.  Any attempt to reduce this 
poor latency by increasing the message retry rate has disasterous
effects on the reliability of the channel.

Remember, APRS was designed for tactical-real-time eevnts
for the rapid dessimination of useable data about everything
at an event.  A latency of even a few minutes per message line
is not acceptible.

For the purpose of analysis, a fixed 1-per minute message retry
rate was assumed and a channel collision rate of 50%. 

If you plan to ever use your fixed-rate-message-retry software
in the field when there are going to be lots of mesages, then
you need to take the poor performance and possible overloading 
of the channel for into account.

de WB4APR, Bob