| |
ZL3AI > APRDIG 03.10.03 09:40l 236 Lines 10457 Bytes #999 (0) @ WW
BID : 2066-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 30, 9/16
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<WB0TAX<N1UAN<ZL2BAU<ZL3VML
Sent: 031002/1432Z @:ZL3VML.#80.NZL.OC #:9563 [Chch-NZ] FBB7.00i $:2066-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Digipeater Duplicate Checking is broke
From: "Scott Miller" <scott@opentrac.org>
Date: Tue, 30 Sep 2003 12:51:50 -0700
X-Message-Number: 36
>1) there will always be some collisions.
>2) There will always be some success from DIGI A just about everywhere
>3) There will always be some success from DIGI B just about everywhere
I guess I'm not following how this is supposed to work. You've got two
digis equidistant from a fixed station. Both digis have zero DWAIT. A
mobile somewhere between them is picked up by both digis, and digipeated at
the same time, give or take a 200 msec in TXD difference. The fixed station
has a pretty constant multipath situation. How does it ever see ANYTHING
from EITHER digipeater?
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: aprsnews digest: September 29, 2003 = overblown math
From: "Tyler Allison" <tyler@allisonhouse.com>
Date: Tue, 30 Sep 2003 15:47:51 -0400 (GMT+4)
X-Message-Number: 37
>A protocol even better than WIDEn-n would be a great start.
I know Im the new guy around here but why dont we do something that the
physical wire guys have been doing for years on 'shared' ethernet media.
CSMACD
Each digi does a random 'back off' before retransmission of a packet. If
it hears another digi send the message they were going to send out it
incriments the 'number' and transmits as scheduled. If it has come to the
end of the requested path (WIDE3-3 for example) the packet gets thrown in
the trash.
Sorry if Im not using the write APRS protocol terms..like I said..Im new
to APRS...not new to network technology.
-Tyler
----------------------------------------------------------------------
Subject: RE: How to locate someone?
From: "Scott Miller" <scott@opentrac.org>
Date: Tue, 30 Sep 2003 12:55:03 -0700
X-Message-Number: 38
Isn't there some way to determine the IP address of the originating system?
----- Original Message -----
From: "Cap Pennell" <cap@cruzio.com>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Tuesday, September 30, 2003 12:25 PM
Subject: [aprssig] RE: How to locate someone?
>Their temperature and today's precipitation are about right for the posit,
>but the barometric pressure's too low.
>And it's probably not a ham. Probably a civilian running a
misconfiguration
>in WeatherDisplay (or equivalent) software with the Davis Vantage Pro wx
>station on the internet only.
>http://www.jfindu.net/near.asp?Latitude=42.78&Longitude=-85.63
>Iknow, not much help. Sorry.
>73, Cap KE6AFE
>
>>The following packet shows up in my area:
>>APRS>APRS,TCPXX*,qAX,APRS:@301811z4248.00N/08542.00W_325/014g...t050P002
>>h39b10055.DsVP
----------------------------------------------------------------------
Subject: Re: Take Control of your DIGI part 4
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Tue, 30 Sep 2003 21:13:09 +0200
X-Message-Number: 39
Hallo Wes and others on the SIG,
At 16:17 29-9-03 -0400, wes@johnston.net wrote:
>Not arguing about if kantronics tncs use the path in their dupe checking (I
>really don't know if they do or don't).... but why in the world should
>*anything* in the path matter for dupes? It really sounds simple.... keep a
>checksum of the payload portion of the packet in memory for XX seconds. Weigh
>every packet you may digipeat against that array of checksums. Doesn't that
>solve the dupes problem?
>
>Did kantronics miss the boat on this one?
I have the impression that the analysis of the effect is incorrect, here is
what I think.
When I see the sequence of packets in the RELAY,WIDE,WIDE scenario and the
RELAY,WIDE2-2 scenario I get the very strong impression that the Kantronics
TNC's do not do any duplicate checking on WIDE but only on WIDEn-N type
calls. You have to run more test but I suspect that you will even see this
behaviour when no calls substitution is done at all. After RELAY the
Kantronics should have blocked the same packet within 30 seconds, regadless
if the path changed. It seems to work with RELAY,WIDE2-2 but I'm not sure
at all if the failure in the first scenario is caused by call substitution
or by failure to do any dupe-checking when taking the packet on a WIDE call.
According to Tim UIDIGI behaves the same. Maybe somebody could check with
the author. Introduction of WIDEn-N and TRACEn-N also intoduced duplicate
checking with the sole purpose to prevent loops. Maybe this was
misunderstood and interpreted that duplicate checking is only required for
WIDEn-N and TRACEn-N type calls and is not needed on WIDE, TRACE and RELAY.
If that is the case these TNCs are just as bad as the old TNC-2 dumb digis
when using only WIDE, TRACE and RELAY type calls in the path. If that is
true then this is one of the major problems that should be solved.
It would be nice to get some hard data on this. I don't have access to a
Kantronics TNC but there are some people on the list that are able to
construct AX.25 test packets to check its behaviour in a controlled
environment. The idea is to just constuct 2 packets, one which was not
digipeated and one that looks like it has been digipeated already. The
second can come in multiple flavours, with or without call substitution,
digipeated once or multiple times, paths with WIDE, TRACE or WIDEn-N etc.
Fire both packets at the Kantronics TNC and look under what conditions the
TNC will pass the same packet twice and when the second packet is blocked
as duplicate to break a possible loop. That way it is possible to eliminate
if call-substitution plays a role and under what conditions duplicates are
checked.
Is there a teacher on the SIG? This would be a great practical assignment
for a polytechnical school student!
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: Take Control of your DIGI part 4
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Tue, 30 Sep 2003 21:49:02 +0200
X-Message-Number: 40
Hello Steve.
At 20:13 29-9-03 -0400, Steve Jones wrote:
>on 9/29/03 7:38 PM, Bill Vodall - WA7NWP at wa7nwp@jnos.org wrote:
>>
>>I now consider DIGI_NED as the least acceptable level of digipeater
>
>Why is Digined the least acceptable?
As I read it is not "the least acceptable" but at the "least acceptable
level" meaning that the user would want DIGI_NED or a digipeater that is
superiour to that. Up to now such a digipeater is not available but I hope
somebody will take the challenge some day. Competition is good...
Although not configurable as DIGI_NED, as a "standard" digipeater UIDIGI
and UIview are also good.
>Henk can probably correct me but I believe it supports the LANn-N idea as is
>with no modifications necessary except to the rules file.
Correct and the same is ture for LINKn-N or offloading WIDEn-N to a
backbone QRG.
Also note that the source is available too, so if somebody wants something
done that cannot be done out of the box with the rules file, you can always
add the code yourself. If somebody wants to build a better digipeater feel
free to snatch the DIGI_NED code as a basis (as long as the result is also
published under the GNU General Public License it is quite okay to do so).
Maybe DIGI_NED should be a project on sourceforge like Xastir...
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: RE: Random backoff
From: "Jeff Thomas - KD4EVB" <kd4evb@hotmail.com>
Date: Tue, 30 Sep 2003 16:25:03 -0400
X-Message-Number: 41
"> Each digi does a random 'back off' before retransmission of a packet."
We've got most of that in SLOTTIME and PERSIST parms now. The problem with
RF is that it isn't as predictable as fiber or wireline paths and in a way
this 'random" hold off shoots ourselves in the foot as it can reintroduce a
packet that just "died out" on an adjacent digi by putting the one it's been
holding for an open channel (+ the random hold off time value) back into the
rf network as needing to be digi'ed some more. The protocol's/digi's we are
using today, simply don't have enough "brains," they are getting there, but
a long ways to go. There's also the simple undeniable/inarguable factor
that there is just an unmoveable wall called "max throughput" that we can
shove thru a 1200 baud unconnected channel under the best of circumstances
and with the best and smartest protocols.
Akin to trying to get 100mb/s switched wireline LAN performance thru a
10mb/s hub, then do it with only UDP packets (no acks, no retrans, of TCP
etc etc)...nothing you do is going to cure the root problem, you can tweak
and optimize some, but the root problem of NOT ENOUGH BANDWIDTH remains. It
going to be UGLY. There are also a host of other variables that make the rf
world even more of a beast to contain and predict versus the wireline world.
You could say APRS' popularity in many areas has also been it's downfall,
grin. Some math (can't remember the source or credibility to it) was that
2m 1.2kb APRS can only handle about 50 local regular users coming across rf.
If that's really the case, then we are pretty much long past being "screwed"
regardless of what we do as long as we stay on one simplex 2m frequency, UI
type protocol, and stay at 1200 baud.
Sometimes I wonder if we wouldn't be better off killing SLOTTIME and PERSIST
completely, getting tx delays equal on the radios and just let things smash
into themselves (collisions) if more than one digi hears the same packet
needing digipeating. Admittedly I probably don't understand this topic well
enough and here I am firing off just one more opinion into the foray without
data to support it, grin! Be nice if some digi sysops in a fairly
controlled environment (in other words a clear freq other than 144.390)
could coordinate, test, log, review and POST the data from such an
experiment tried both ways.
The solution oversimplified = ADDRESS THE ROOT OF THE PROBLEM = more channel
bandwidth, user education, and much much smarter digi's. All mucho easier
said than done it appears. Everything else is pretty much just treating
symtoms and not the disease itself. Not to say there is anything wrong with
folks trying to come up with solutions to keep things "contained" for the
time being.
Good to see you on the lists Tyler...
73 de Jeff, KD4EVB
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
