| |
ZL3AI > APRDIG 28.02.03 10:08l 275 Lines 11349 Bytes #999 (0) @ WW
BID : 948-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 25, 1/3
Path: DB0FHN<DB0ZWI<DB0HST<ON0DXC<WA7V<W7NTF<KD7HAH<VK6HGR<ZL2BAU<ZL3VML
Sent: 030227/0940Z @:ZL3VML.#80.NZL.OC #:60541 [Chch-NZ] FBB7.00i $:948-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Tuesday, February 25, 2003.
1. 144.39 channel loading
2. Re: 144.39 channel loading
3. Re: 144.39 channel loading
4. Re: 144.39 channel loading
5. Re: 144.39 channel loading
6. Holy Grail of APRS Network Performance
7. Re: Holy Grail of APRS Network Performance
8. Re: Holy Grail of APRS Network Performance
9. RE: Holy Grail of APRS Network Performance
10. Re: Holy Grail of APRS Network Performance
11. Re: Holy Grail of APRS Network Performance
12. RE: Holy Grail of APRS Network Performance
13. Re: Holy Grail of APRS Network Performance
14. Re: Holy Grail of APRS Network Performance
15. Re: Holy Grail of APRS Network Performance
16. Re: Holy Grail of APRS Network Performance
17. PCsat easy listening
18. APRS at the annual Wyong Field Day
19. OT - need St. Louis Repeater info
20. Re: [amsat-bb] NO44 with AWG Packet Engine
21. For Sale: Motorola Oncore GT+ and TAPR interface board
----------------------------------------------------------------------
Subject: 144.39 channel loading
From: "hasan schiers" <schiers@netins.net>
Date: Tue, 25 Feb 2003 06:53:32 -0600
X-Message-Number: 1
N0BKB and I have been running a Traffic analysis program (UI-Traffic)) that
is just too cool! It posts an object every 10 minutes with the channels
stats listed. When he posts, the Icon jumps to his qth. When I post, it
jumps back. It shows the data of the last station to cause the object to
"relocate".
The format is XXX packets in 10 minutes.
I'm trying to get a "feel" for just what the channel loading limits are in
terms of raw packets being transmitted. The UI-Traffic program does a
beautiful job of displaying channel loading. IT shows 3 continually updating
graphs:
1. Packets per minute for a 24 hour period. (Color coded Red,Yellow,Green
for number of packets in a range)
2. Packets per minute over a 10 minute period (bar graph)
3. Distribution of the number of packets in any 1 minute period...shows the
"second" of the minute when a packet is heard and graphs it. This shows the
number of "holes" in any given minute.
===============================================
The question:
I'm seeing 150 to 180 packets in 10 minutes, or an average of 15 to 18
packets per minute, but before our last network change we were seeing an
average of 250 to 280 packets per minute. In fact it was this number that
led us to make a series of network changes to try to reduce channel loading
before we had a meltdown. What is the "practical" number where there are
"too many" packets to be usefully handled? Is it a safe assumption of 1.5
sec per packet and in a perfectly timed network it could support 40/min? (Of
course that is silly and could never happen). So that's why I'm asking what
the practical limit in a 1 min period would be. I've seen it discussed, but
never had a measuring tool at hand before so I lost it.
Thanks,
....hasan, N0AN
----------------------------------------------------------------------
Subject: Re: 144.39 channel loading
From: "hasan schiers" <schiers@netins.net>
Date: Tue, 25 Feb 2003 07:31:12 -0600
X-Message-Number: 2
A typo....250 to 280 packets per TEN minutes. Sorry.
The program "publishes" as an object XXX packets per 10 minutes, but graphs:
1. packet distribution in 1 sec intervals for 1 minute
2. A bar every minute for 10 minutes
3. A bar every minute for 24 hours.
If you click on the ? TRAFFIC Icon in central Iowa you will see a report in
the "details" of something like 146 in 10 minutes, which was my last report.
That would be an average of 14.6 packets per minute.
Looking at the distribution graph of what second of any given minute has
packets in it, you can see the "holes" for available transmission, which is
a nice visual indication of channel loading.
----------------------------------------------------------------------
Subject: Re: 144.39 channel loading
From: Alex <kr1st@amsat.org>
Date: Tue, 25 Feb 2003 08:37:36 -0500
X-Message-Number: 3
hasan schiers wrote:
>The question:
>
>I'm seeing 150 to 180 packets in 10 minutes, or an average of 15 to 18
>packets per minute, but before our last network change we were seeing an
>average of 250 to 280 packets per minute.
....per 10 minutes I assume? 25 to 28 packets/minute is a pretty darn
good throughput if you'd ask me; even 15 to 18 seems very good to me.
>What is the "practical" number where there are
>"too many" packets to be usefully handled?
I wouldn't look too much at the number of packets per minute, but rather
if you are seeing the traffic you would like to see. If the traffic you
are seeing on your local network (whatever that may be in APRS) is say
90% from outside your area and your local traffic barely gets through
then I would think you have a bad situation even if the number of
packets on the channel approaches some ideal figure. I'd look at the
quality of the traffic rather than quantity.
But just looking at the numbers I's say that your network is performing
rather well. I think Henk, PE1DNN, once said that a more realistic
expectation of the throughput of an APRS network is like 6
packets/minute, but I may be wrong here. Henk?
73,
--Alex KR1ST
----------------------------------------------------------------------
Subject: Re: 144.39 channel loading
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 25 Feb 2003 10:12:49 -0500 (EST)
X-Message-Number: 4
On Tue, 25 Feb 2003, hasan schiers wrote:
>The question: I'm seeing 150 to 180 packets in 10 minutes, or an average
>of 15 to 18 packets per minute, but before our last network change we
>were seeing an average of 250 to 280 packets per minute.... What is the
>"practical" number where there are "too many" packets to be usefully
>handled? Is it a safe assumption of 1.5 sec per packet and in a
>perfectly timed network it could support 40/min?
The theoretical maximum throughput is 36% with Carrier sense multiple
access, no digis and everyone hears each other. We have digis (reduces
channel capacity by 50% for each hop) and no one hears everyone else, so
the actual maximum throughput is closer to the 18% theoretical for pure
ALOHA networks. But we all do hear the digi and avoid colisions with it so
that about cancels the added load of the digi. So I use 20% as the
maximum. I'd use about 1 second per packet average and end up with about
12 packets per minute as the optimum network (20% of 60)...
But notice that a Mic-E packet (Kenwood or other Mic-E) packet only lasts
about 0.5 seconds and some bloated APRS clients have verbose pacekts (1.5
seconds). So shorter packets with shorter paths and shorter TXD's can
significantly improve this number.
A Mic-E position can be only 0.25 seconds, plus a 0.1 second TXD for a
total of about 0.35 seconds. A verbose position report with 37 bytes of
text and a TXD of 300 can be 1.5 seconds. Check your D7 and D700 settings
to be sure you have set a short TXD (that works). Usually 200ms is fine.
For discussion of ALOHA and channel capacity see my FIXING 144.39 WEB
page:
http://www.ew.usna.edu/~bruninga/aprs/fix14439.html
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: 144.39 channel loading
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 25 Feb 2003 11:59:23 -0500 (EST)
X-Message-Number: 5
>The way Andy Pritchard has defined his colors for UI-Traffic (which is what
>I'm using for analysis) is:
>
>1 to 13 packets per minute = Green (Good)
>14 to 25 packets per minute = Yellow (Caution)
>25+ packets per minute = Red (Too many!))
Of course the interesting thing is that you might possibly have a network
that is 800% saturated and only 1 out of every 8 packets gets through and
still only see 1 to 13 packets per minute becasue of all the colllisions..
Remember that througput (as a measure of the reliability of EVERYONE to
equally get heard) peaks and then goes terribly worse. SO packets per
minute is a meaningless number unless it is also compared to RELIABILLITY
of any one station to be heard.
But in a real APRS network with people all over the map, the rapidly
degrading "reliability isnt noticed" as the loading goes up, the only
thing that gets worse is the ability of a 5W HT to be heard. Even in a
800% sturated network, the guy 1 mile from the digi running 50 watts will
ALWAYS get in...
Just some points to ponder...
Hummh... the BEST absolute measure of a NETWORK's performance in one's
local area is to put a D7 on the air on the edge of the desired area of
coverage and set it to say a 20 minute rate via ONE hop and then COUNT
successes. If it is not 90%, then yoru network is too saturated...
See next message!
Bob
----------------------------------------------------------------------
Subject: Holy Grail of APRS Network Performance
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 25 Feb 2003 12:22:59 -0500 (EST)
X-Message-Number: 6
The HOLY Grail of APRS network performance!
Regarding the discussion of 144.39 channel loading, this idea came up in
the last message and bears some further study and possibly
standardization: APRS CHANNEL PROBES:
The ONLY way to measure the reliability of an APRS channel is the sucess
rate of the intended user in the intended area. This cannot be measured
by channel statistics becasue the stronger stations will always get
through no matter how bad the channel (at the expense of the lower power
or more distant station)...
So as I suggested in my previous email, the BEST measure of packet
performance is simply measuring the statistical performance of a "probe"
packet that is transmitted from "the indended user class station" on the
edge of the "intended user coverage area"... If he gets in X% of the
time, then your network is operating at X% reliability!
Now, I would not suggest adding MORE packets just for the sake of
measuring probes, but remember, ANY station can be a probe, as long as we
konw how often it is scheduled to transmit (and he is representative of
the type of station you want coverage for)! All we have to do is compare
its success with its intended rate!
So what I propose is a unique text string or anything that will let
ANYONE designate their station as a "probe". That is, it is on all the
time, it is on a FIXED packet position rate and its path is the
recommended path for that area. Then software can watch these
probes and COUNT statistics and derive REASONABLE reliabiilty figures!
How about we use the unique string of [CPxx] as a unique text string that
identifies a "channel probe" station transmitting one packet every xx
minutes. His path would usually be relatively short (That which is
recommended for his area!).
BINGO! From his path and his [CPxx] value, we can do any number of REAL
statisitical analysis in real time to determine the reliability of the
network wherever there is a probe station! And anyone can be a probe! He
can even use it for messaging and other packets, becasue ONLY the fixed
rate Position packets that contain the [CPxx] exact format would be
counted!
Did I miss something or is this the no cost holy grail of measuring
network performance? Wow, I'd love to see the kind of analysis and
display software that could use this info...
Bob, WB4APR
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
