[aprssig] New n-N and 28 versus 30

[Robert Bruninga]

Regarding n-N timers of 30 vs 28:

Due to discussions here, I'm beginning to think that diddling 
with this number wont really change much from abusive
trackers but will have an impact on message retries as Wes
poitns out.  Hence, I'm just going to leave it at 30.

The decaying Message retry algorithm sends:
one now,
one 8 seconds later
one 16 seconds later
one 32 seconds later

so if the original is successful through a digi, then the first 
two retries are lost.  But this is OK, because if the original 
got through the digi (no collisions) then there is no need to 
rush with the next two.  But if it didint get heard
by the digi, then these additional 2 retries give the digi
the chance to hear it the "first" time...

Also, this is why APRSdos schedules a delayed ACK
30 seconds after the first..

This is why the Decaying Algorithm and smart-acking 
work so rapidly and reliably but with *less* impact on the 
network than the simplistic and high delayed try-once-a-minute 
routine of some  simple clients.

de WB4APR, Bob


>>> Wes Johnston <aprs at kd4rdb.com> 12/20/04 2:37:24 PM >>>
Ummm.....  the checksum in the UIFlood is a checksum of the data
portion of a
packet.  So if the data portion changes, so does the checksum.

If I have a tracker that is transmitting a posit every 10 seconds as I
travel,
then every packet's data portion is unique.  Each posit will slip thru
the
checksum filter, right?

If I have a fixed station (or stationary tracker), then the checksum
filtering
will catch it.  So in the case of a parked car, you'd limit the parked
car's
psitions to one every 30 seconds... or in the case of UIFLOOD 32, it
would
round over to the next integer minute.

So on the one hand, if we make the number of seconds something high
like 255
seconds, then we slow the redundant packets from parked cars... but we
also
limit retries on messages from stations...

I'd say the number could be 61 seconds.
Wes
--



Quoting Robert Bruninga <bruninga at usna.edu>:

> I also wonder if it is also time to change  the common
> 28 second filter parameter in most digis' UIFLOOD, and UITRACE
> parameters from 28 to 32?
>
> It was set to 28 so that people running 30 second trackers
> would not get filtered out.
>
> These days, No one should be running 30 seconds *routinely*
> so why not change the filter to 32 so they CANT (routinely).
> Of course the SYSOP can change it to 19 seconds if he
> wants for any special event or for doing mobile coverage
> studies at a 20 second rate if he wants,...
>
> But in general, I dont see why we leave this floodgate
> open for such rare occassions.  Better to keep it closed
> most of the time and only open it up when needed..
>
> I'm changing all my docs to show this.  or at least 30 secs.
>
> Bob
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org 
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig 
>