| |
ZL3AI > APRDIG 28.09.03 12:09l 194 Lines 7922 Bytes #999 (0) @ WW
BID : 2011-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 25, 11/11
Path: DB0FHN<DB0RGB<OE5XBL<OE3XSR<OK0PBX<OK0PHK<OK0NAG<OK0PPL<DB0RES<DB0EEO<
DB0GOS<DB0ACC<ON0RAT<ON0DXC<WA7V<WB0TAX<LZ3NP<YV6BTF<EA5AKC<KD4GBA<
ZL2BAU<ZL3VML
Sent: 030927/1423Z @:ZL3VML.#80.NZL.OC #:9146 [Chch-NZ] FBB7.00i $:2011-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: I guess we're going to agree to disagree Bob. Part 1 of ?
From: "Georgette Sampson" <georgette.sampson@cox.net>
Date: Thu, 25 Sep 2003 21:52:01 -0500
X-Message-Number: 44
>Computer operation is not an option.
When you say "computer operation" do you mean a big "honking" PC, or do you
also exclude a 386/486/PII/PIII black box the same size as a KPC-3+?
----------------------------------------------------------------------
Subject: Re: I guess we're going to agree to disagree Bob. Part 1 of ?
From: "Scott Miller" <scott@home.miller.org>
Date: Thu, 25 Sep 2003 19:58:41 -0700
X-Message-Number: 45
RAM would be a plus, but the KPC-3+ and other TNCs already have a fair
amount of RAM originally intended for mailbox features. Now, I still
believe that we should be running digis on a PC platform, but not because
routing algorithms require a lot of CPU power. I don't know of any routing
algorithm that can't be done on an 8-bit CPU. It's just a whole lot easier
to program for a platform where resources aren't an issue.
What we need is a good routing protocol that addresses how APRS is used
today, and supports future expansion in UHF backbones, multiple input
channels, and so on.
Scott
N1VG
----------------------------------------------------------------------
Subject: APRS fundamentals
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 25 Sep 2003 23:24:13 -0400 (EDT)
X-Message-Number: 46
On Thu, 25 Sep 2003, Georgette Sampson wrote:
>Someone suggested the digi guru's all "engineer" the problem, and I
>think that's a good course of action. Gather the data, form an argument,
>and then publish it.
>
>Seems that right now, all we have published arguments with no data.
Believe me, APRS was engineered from the beginning and I have been
"publishing" it for the last 11 years! It is really very simple and
anyone can use these fundamentals to know the RIGHT way to optimize their
network:
APRS is built on these fundamentals:
1) A net cycle time of 10 minutes for local (direct or 1 digi ops)
2) A net cycle time of 30 minutes for area wide operations.
3) A 1200 baud system operating as an ALOHA random access channel
4) An ALOHA channel (with hidden transmitters) has an optimum
throughput at about 20% of channel capacity for maximum reliability.
This means in a 30 minute period the most reliable throughput on
the local RF channel can be about 360 total packets. Yes, you can
get MORE packets through, but at the EXPENSE of reliability (more packets
are lost due to collisions). And the reliability falls
off much FASTER than any improvement in throughput.
Now, how you use your local 360 packets per 30 minutes can be debated
locally. But, by making some rough assumptions about what YOU
want your network to support during EVENTS, or EMERGENCIES or
when you need RELIABLE communications is easy then to arrive at
the number of stations YOUR RF network can reliably support.
Here is an example of how I came up with about 50...
TYPE STATION PKTS/30m ea Total PCT of LOAD
------------------- ----------- ----- -----------
30 Home stations 2 60 16 %
3 LOCAL digis (evy 10m) 3 9 2.5%
9 2nd-tier digis (evy 30m) 1 9 2.5%
5 area WX stations 6 30 8 %
4 Mobiles evy 5m 6 24 6 %
4 Mobiles evy 3m 10 40 11 %
4 mobiles evy 2m 15 60 16 %
4 mobiles evy 1m 30 120 33 %
---
51 TOTAL USER STATIONS
TOTAL PACKETS IN THE 30 MINUTES = 352 Just about right
You can trade these numbers anyway you want, but you cannot
change the laws of physics that says the optimum reliable
throughput for our 1200 baud ALOHA channel is about 360 total
packets. Thus, you can add a lot more fixed stations for every
high-rate mobile you eliminate. Or since you may need
high-rate mobiles at our event, this is why you cannot also
support hundreds of non participating out of area fixed stations.
So set your priorities, add up your load, and THAT is the number
of stations your RF channel can accomodate.
Look at the number of digis that link this TOTAL number of
stations together in the area of interest, and THAT is the
optimum number of HOPS. Any MORE hops is just QRM, adds
NOTHING to your usefullness and reduces local reliability.
If you have MORE TRAFFIC than this (which is the problem in many areas),
then STEP #1 is to reduce the size of your network. The EASIEST way to do
that is to eliminate unwanted out of area packets. The easiest way to do
that in areas with KPC-3 TNC's is to disable WIDEn-N digipeating and
retain the CALLSIGN SUBSTITUTING RELAY and WIDE digipeting functions
because they WILL still serve the local area and will not be filtered.
Thus LOCAL operations is enhanced, RELAY/WIDE works as it is supposed to ,
and yet WIDEn-N long hops can stil be used in areas which can still
support it.
Thats the facts...
Enjoy...
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: I guess we're going to agree to disagree Bob. Part 1 of ?
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 25 Sep 2003 23:32:04 -0400 (EDT)
X-Message-Number: 47
On Thu, 25 Sep 2003, Georgette Sampson wrote:
>The "WIDE digipeater is better than the WIDEN-N digipeater" or
>vice-versa, are arguments that have no meaning when you have a real
>computer device.
>
>Suppose you had a Compact Flash configured as a hard drive, a large
>RAM drive, and a bunch of regular RAM? Would a WIDE or WIDEN-n
>digipeater be your goal?
Ah, apples and oranges. By all means, we need all kinds of new "node"
hardware and software and better algorithms, and higher data rates! there
have been all kinds of good ideas. GO FOR IT. I would LOVE to see
everyone go replace the thousand digipeaters with all these great
ideas....
But I am NOT addressing any of those issues. I am only looking at ways to
solve the OVERLOAD problems WE have NOW, TODAY with the installed base of
KPC-3 TNC's using WIDEn-N, that can be fixed with a single command. No
more. No less.
>I know that I would probably come-up with a system that did quite a bit
>of analysis, and table searches before it ever transmitted a thing.
>Maybe the problem is that proper DUP checking is not possible with the
>technology at hand, and blindly re-transmitting what is essentially
>garbage data, rather than only allowing valuable non-redundant tactical
>data to flow, is the problem.
Good ideas. GO implement them, and get them installed all across the
country and lets move forward. But continuing to support the
continuation of LONG-HOP WIDEn-N FLOODING is killing us... in my opinion.
Bob
----------------------------------------------------------------------
Subject: Re: I guess we're going to agree to disagree Bob. Part 1 of ?
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 25 Sep 2003 23:36:52 -0400 (EDT)
X-Message-Number: 48
On Thu, 25 Sep 2003, Steve Jones wrote:
>You can either make the trip to the site to disable widen-n routing or make
>the same trip and install new firmware/software.
>
>Seems disabling widen-n digipeating is the lazy way to go about solving the
>problem.
Yep. But I dont know of anyone that has new firmware/software for the
KPC-3. And THAT is the ONLY thing I am addressing here. I dont know how
many times I have to re-state this. My idea is ONLY an option for local
SYSOPS to take control of their local KPC-3 digi to cut down on the
overload! Nothing more, nothing less...
Yes a cheap fix. BUT IT IS FAR BETTER than all the HACKS that others are
doing by killiing RELAY and WIDE callsign substitution for local packets!
That is what I am trying to prevent.... the disintegration of APRS as a
consistent common nationwide system and something that FAILS locally.
Bob, WB4APR
---
END OF DIGEST
Read previous mail | Read next mail
| |
