[aprssig] Aprx v2 beta, now with Viscous Digipeater

[Matti Aarnio]

On Thu, Oct 22, 2009 at 09:38:49AM -0700, Scott Miller wrote:
>> I was thinking more of the buffer for the packets being held for
>> delayed digipeating.  Matti's web page refers to a "4-8 second" hold,
>> which sounds reasonable in operation, but that means a worst case of
>> up to eight 256 byte packets, or 2k RAM.  Even a minimum 4s hold is 1k
>> of buffer space.  This is all in addition to the dupe hash table.
>
> Yes, but in the T2 the buffer space (not a full 2K) is already there.  
> Certainly a 4-8 second hold (I think 3 or 4 seconds ought to do it) is  
> going to put a lot more load on the buffer.  But it can immediately drop  
> anything that isn't eligible for digipeating, and it can drop packets  
> that it hears as dupes.
>
> The biggest problem that's going to cause for the T2 is buffer  
> fragmentation.  It's a circular buffer and it can only delete from  
> either end - it can't reuse space from the middle of the buffer until  
> one end or the other shrinks down.

You could shrink circullar buffers too - move tail part to fill
the hole, but code to make that is -- interesting -- to say the least...
If you discard first packet moving head pointer in "abnormal" direction,
things are simpler, but when you discard from the middle, they become
very interesting.  But then.. you can use single bit to mark the packet
as "do not xmit", and deal with it very quickly once it reaches buffer
head or tail.

I see single packet being rebroadcast around for 1-3 seconds, which
for APRS RF network is sort of dead time because digis are drowning
out mobiles. You do not get entirely new packets all that often,
perhaps up to 3 during the 5 second probation delay.

So lots of packet traffic, but lots of duplicates too.

It is all about probabilities of different Markov chains. Sometimes
you will end up running out of memory buffer to stuff in waiting
packets, but you can tune it to be "low enough" probability..
Furthermore, you can consider it as "self limiting channel transmission
reducer" :-)

> Scott
> N1VG

73 de Matti, OH2MQK