| |
ZL3AI > APRDIG 03.10.03 09:37l 170 Lines 7638 Bytes #999 (0) @ WW
BID : 2067-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 30, 10/16
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<WB0TAX<N1UAN<ZL2BAU<ZL3VML
Sent: 031002/1438Z @:ZL3VML.#80.NZL.OC #:9564 [Chch-NZ] FBB7.00i $:2067-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: aprsnews digest: September 29, 2003 = overblown math
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 30 Sep 2003 16:27:28 -0400 (EDT)
X-Message-Number: 42
On Tue, 30 Sep 2003, Jeff Thomas - KD4EVB wrote:
>How about a little more fact, versus intentional or unintentional fiction
<snip>
>Bob Said:
>>WIDEn-N FLOODS equally in ALL directions with dozens if
>>not almost 200 copies. We can no longer afford this QRM
>>in our network. If each digi can hear 3 others, here is
>>the resulting number of COPIES at each HOP:
>>
>> SETTING 1st 2nd 3rot a problem on 144.390. The
>unanswered question (at least answered with data to back up
>opinions/assertions) is how do we as the APRS community fix it.
I have shown how with the new n-N paradigm and getting back to basics.
It SOLVES ALL PROBLEMS if used correctly...
> We can set here and argue opinions, feed our egos, and so on till the
>cows come home and make ZERO progress. Otherwise we look like Democrats
>and Republican politicians all fussing about how the other is or
>proposes to do something, but never offering up any real solution
>themselves.
Agree. So how about doing it the new way. Clearly the old way is not
working...
>I'll be the first to admit I don't have the solution myself either. I've
>got a few local 'stop gap" ideas for our local rf network for the time
>being, but even they are just temporary and server to just "cover" the real
>problems up like many other ideas I've seen here.
It is those stop gap measures that is KILLING APRS... as a common system
that is EASY to train users. Users give up in total frustration at the
current lack of a cohesive, consistent system that works everwyehre.
(like we had back at the beginning)...
>Yeap, I'm obviously biased FOR widen-n as being the closest thing to a
>halfway decent protocol for todays APRS needs. Yeah it needs to be "suped
>up" and made a lot more configurable for each areas needs, but it's a start
>in the right direction. We're hams, we're supposed to be innovators, let's
>forget egos and personal agendas and start working towards fixing this issue
>for a change. A protocol even better than WIDEn-n would be a great start.
>Iknow, easy to say there Jeff :-)
Yep, that is exactly what I have proposed for those open minded enough to
think it through...
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: Digipeater Duplicate Checking is broke
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Tue, 30 Sep 2003 22:31:20 +0200
X-Message-Number: 43
At 14:25 30-9-03 -0400, Bob Bruninga wrote:
>So APRS was designed to allow FRATRICIDE kill out most dupes at the local
>level, and still MOST of the time, even those in the KILL area will get
>one OR THE OTHER of the packet. THus APRS was designed taking all of
>these details into account and that is why some DUPES and SOME FRATRICIDE
>are part of the design...
If that is the way it is supposed to be then I think that should not be
accomplished by DWAIT=0 or the altenative PERSIST=255 and SLOTTIME=0 for
newer systems. Its still a race condition and digis transmissions can still
be delayed due to QRM or due to, for example, mobile stations. If you want
a direct immediate transmit from a TNC the most straigtforward is just to
set it to FULL-DUPLEX. That way it will ignore any traffic on the QRG and
transmit immediately without waiting. I think that will yield the effect
you want here.
I am for collision avoidance. The effect of two digis transmitting at the
same time looks attractive, but at the same time the digis will start to
yam mobile stations also, especially if two or more packets are received in
a row. If this happens in systems with PERSIST and SLOTTIME set to sensible
values, like 64 and 10ms, then you will be able to receive multiple packets
and send them out in one burst. That also saves load since multiple packets
can be send with one TXdelay instead of for example three TXdelay times of
approximatly 250ms each. So I'm not convinced at all if the advantage
outweights the disadvantage, especially since it only has a big saving if
digis are close to eachother. There are other means to solve that, like
closing one of them down...
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: ***New*** TRACEn-N (LANn-N) Paradigm
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 30 Sep 2003 16:43:21 -0400 (EDT)
X-Message-Number: 44
On Tue, 30 Sep 2003, Scott Miller wrote:
>>MODIFIED proposal for LANn-N operations that solves ALL problems...
>>1) TUrn off WIDEn-N in all areas that cannot afford to be seeing
>> anythign beyond 3 hops without flooding the network
>
>So where does that leave us, in an area where we don't have enough digis
>to have a separate perimiter and local network? If all of Central
>California does this, how do we get packets from Southern California to
>Northern California?
I hate to inform you, but that is completely impossible to do reliably on
a single 1200 baud channel shared by over a thousand stations in California!
With my new UITRACE LANn-N idea, you can have both at the same digi. You
can have a UIFLOOD LINKn-N system that only propogates packets along a
desired linear direction (only) with no dupes, long paths, and only N
copies AND at the same time, that digi can be part of a LANn-N system that
serves the surrounding 50 to 100 users in a dedicated LAN.
If you are trying to serve more than 50 to 100 users, then APRS at 1200
baud on 144.39 WILL NOT WORK reliably. That is why Steve and Sprouls came
up with IGates to SOLVE the long haul problem using the INFINITE
bandwidth of the internet.
>I suppose if you've got enough digis to allow a WIDEn (LINKn? CALn?)
>corridor between the two, that's fine... but the reality is there aren't
>enough digis to cut any out and still have a reliable path, IMO.
You are showing the right mindset, and that it that for the first time,
SYSOPS may need to "think" about their network. Where the density of
ussers is, where the LANS are, who needs to be in a LOCAL AREA network
with WHOM, and to then adjust the DIGIS to match that. FLOODING
everything everywhere can no longer work!
>>4) Notice that a SINGLE digi can now BOTH support LINKn-N, and LANn-N
>>AND is no longer vulnerable to WIDEn-N flooding from out of area!!!
>
>And if the people here on the list - presumably the ones with the most APRS
>knowledge - can't keep straight what path to use where, what are the chances
>that the average user will?
The inability of some of the loudest experts on this sig to understand the
very simple rules for the new paradigm does in fact amaze me too...
>I hope the techniques you've described will be of use somewhere, but I don't
>see that it's going to do us a lot of good here.
Then don't use them and continue to suffer and complain.
Those people who see the light, will use it and be rewarded with a good
reliable local network that does what it was designed to do. THat is the
beauty of this approach. Those that take the action to implement it are
takin gimmediate control over their local nets and seeing the immediate
benefit.
ALl prior solutions and all these local HACKS that are destroying APRS are
dependent on the "OTHER PEOPLE" to change their ways. Well, that never
brings solutions, only a lot of hot air and complaints. But my apporach
lets the local sysops take charge and move out independently...
Bob, WB4APR
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
