[OZAPRS] UIDIGI

[Richard Hoskin]

Hi Andrew,

This is great advice for the USA or may be Europe where they have 25 time
the APRS stations and can run packet rates of 180 per 10 min, all of which
kill the RF network.

Here in VK we have 25 times less stations, 30 times less digipeater
saturation, and are lucky if we get an average of 100 packets per 10 min
in
all but the major cities. (We even have to supplement our state's RF
traffic
with internet traffic to get 'enough stations on the map')

When you read Bobs recommendations you need to consider whether or not
they
are suitable for our conditions, RF network requirements and philosophy.

If APRS ever became as popular here as it is in the USA then we would need
to change our philosophy.

Cheers
Richard.
VK3JFK

> -----Original Message-----
> From: ozaprs-bounces at marconi.ics.mq.edu.au [mailto:ozaprs-
> bounces at marconi.ics.mq.edu.au] On Behalf Of Andrew Rich
> Sent: Saturday, 11 December 2004 6:43 AM
> To: ozaprs
> Subject: [OZAPRS] UIDIGI
> 
> The WORST digi setting is UIDWAIT ON.
> 
> If you are seeing lots of dupes, then yours or other digis
> around you probably have UIDWAIT *wrongly* set to ON.
> Please make sure it is off (the default) in your digi.
> 
> Like some other TNC parameters, a casual reading may
> make this paramater sound beneficial when in fact, it is
> BAD for APRS.  Here is why.
> 
> APRS was designed around the fundamental principle of
> radiating information outward as efficiently as possible.  That
> is, the next outward tier of digis are all supposed to digi
> the same packet at the same time so that only one time-slot
> is consumed per tier, not per digi.
> 
> Turning on UIDWAIT eliminates this efficiency and leads
> to a factor of 2, 3 or 4 fold increase in the channel load
> and an increase in dupes received by users. Don't do it.
> 
> Example:  lets say all digis can hear 3 others and digi A
> launches a WIDE,WIDE packet,   What should happen
> in 2 seconds is that the 3 surrounding B digis all digipeat
> it at the same time, and then the next tier of C digis all
> do it at once as well for a total ot two time slots (2 sec)
> for 2 hops:  And all digis get only one copy and users
> inbetween digis only see at most 2 copies.
> 
> 1st sec  2nd sec
> ______ ______
> 
> B1*,W
>              B1,C1*
>              B1,C2*
> B2*,W
>              B2,C3*
>              B2,C4*
> 
> B3*,W
>              B3,C5*
>              B3,C6*
> 
> But with UIDWAIT ON you get an explosion of time
> slots drastically cutting throughput and  in this case
> users inbetween digis may hear 3 to 6 copies each
> 
> B1*,W
>              B1,C1*
>                           B1,C2*
>              B2*,W
>                                        B2,C3*
>                                                      B2,C4*
> 
>                           B3*,W
>                                        B3,C5*
>                                                      B3,C6*
> 
> And if the original path was for 3 hops, many of these
> preserved copies have the potential to now propogate
> further outward.  A REAL MESS. Dont do it.
> Set UIDWAIT OFF (the default).
> 
> Of course there are lots of other 2nd order effects
> and considerations that can significantly affect these
> two simple models, but they are secondary to the
> original APRS design principle that packets are
> supposed to radiate outward in tiers and all tiers
> are supposed to transmit at the same time to minimize
> channel load.
> 
> Please, set UIDWAIT OFF (the default).
> 
> The next worst command is ID instead of NOID
> in the UIFLOOD parameter, and the 3rd is the HID
> which should be OFF. etc, etc
> 
> de WB4APR, Bob
> 
> 
> 
> _______________________________________________
> ozaprs mailing list
> ozaprs at marconi.ics.mq.edu.au
> http://marconi.ics.mq.edu.au/cgi-bin/mailman/listinfo/ozaprs


_______________________________________________
ozaprs mailing list
ozaprs at marconi.ics.mq.edu.au
http://marconi.ics.mq.edu.au/cgi-bin/mailman/listinfo/ozaprs