Order Tray | Contact Us | Home | SIG Lists

[aprssig] Tracker Smart Pathing

John Ronan jronan at tssg.org
Tue Mar 21 17:17:12 UTC 2006


On 21 Mar 2006, at 16:02, <scott at opentrac.org> wrote:

>> I have never liked the network making decisions beyond
>> the SENDER's control (other than trapping abusive paths
>> that are PUBLISHED and well known to be trapped).  Only
>> the sender knows his priority and the PATH he needs at
>> any given instant.
> The AUTO thing with preemption fixes that.  No need to run AUTO if  
> you don't
> want to, and if it's not fully implemented yet, you just run  
> WIDE2-2,AUTO.
> Say I put a digi up on Plowshare peak to serve the local area here  
> - you
> transmit with WIDE2-2,AUTO and it gets rewritten as WIDE2*,K6SYV-10  
> and goes
> only one further hop, but hits at least two Igates.  Out in the  
> desert,
> maybe AUTO gets rewritten as WIDE3-3, or CA3-3, or whatever.
>
Ok, that would work when statically configured(remotely or  
otherwise), could it be made to respond to channel load?

Not that I really can envisage a scenario in Ireland that the channel  
would be loaded, but I'm sure it could happen that a channel hits  
overload.  What should the response  of the Digi be? And how does one  
determine the channel is overloaded? (I'm not the expert here)

Firstly it could be a rogue station?  Do we clamp them to a max WIDEn- 
n, relatively easy if they are fixed.  But if they are mobile what do  
we do? I like smartbeaconing (It pains me that the D700 doesn't have  
it).  From Tom's Email I can see the problem with it flattening a  
channel, should there be a 'recommended' (default) setting for all  
the options.

If its just too much traffic from too many stations, should the  
default action to be stop using 'AUTO'(premption) and just become a  
normal WIDE2-2 digi? This could, potentially, make the problem worse,  
but no worse than a 'standard digi', but if we can figure out a  
better way we should probably do that.

Should the Digi try and do some calculations and drop the packets  
coming from furthest away? basically protecting the 'locality' of the  
APRS net from outside incursion.

I'm sure I've missed loads, so I'm just asking questions, I won't  
pretend to have answers.

Scott, if you do put something like AUTO into the OT2, I'll help test  
it for you (when they arrive).  I'm trying to think now how it would  
fit in with NSR? I do like the idea of a DIGIs being able to discover  
each other, figure out their 'place' in the network and acting  
accordingly.  That said having SSn-n available as a fallback that you  
know will 'always' work would probably still be a requirement.

Good discussion, I think I'm learning (slowly!)

Regards
de John
EI7IG

--
John Ronan <jronan at tssg.org>, +353-51-302938
Telecommunications Software &  Systems Group,  http://www.tssg.org







More information about the aprssig mailing list