| |
ZL3AI > APRDIG 03.10.03 09:39l 227 Lines 9629 Bytes #999 (0) @ WW
BID : 2060-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 30, 3/16
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<WB0TAX<N1UAN<ZL2BAU<ZL3VML
Sent: 031002/1347Z @:ZL3VML.#80.NZL.OC #:9557 [Chch-NZ] FBB7.00i $:2060-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: UIDIGI and DWAIT setting
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Tue, 30 Sep 2003 08:05:29 -0500
X-Message-Number: 6
I have split the DWAIT topic out into another thread.
> 1) SYSOPS who dink with the Dwait parameter. All DIGIS in an APRS system
>MUST have the default D-WAIT of 0!!! Some well meaning, but not
>thoroughly understanding SYSOPS have dinked with the D-Wait parameter to
>try to make sure that the same packet from two digipeaters DONT collide.
>DUH! The are SUPPOSED to collide. It is called fratricide and is part of
>the dupe elimination foundation of APRS.
The best I can tell is that UIDIGI uses Persistence and Slottime controls
instead of the antiquated DWAIT for digipeating. This helps insure there
will not be any packet collisions with an antiquated system using the DWAIT
parameter. DWAIT is something you cannot dink with on UIDIGI because it
does not exist.
These are the controls fro UIDIGI for channel access timing:
PERSISTANCE [n] (n=1-255) (default 64)
- Sets the PPersistance
- Parameter for channel access timing
SLOTTIME [n] (n=1-255 x100ms) (default 10)
- Set the SLOTTIME
- Selects Length of delay between channel access attempts
Of course, one could set Persistence to 255 and Slot to 1 and effectively
disable this channel access method. However, does this make for a reliable
network or does it promote a very aggressive network channel access method?
Bob, I gather that you are advocating that DWAIT is more important than
avoiding a packet collision. It is my recollection that Persistence and
Slottime methods are effective, but everybody on the channel must use it to
be effective. If we use the antiquated DWAIT method, we are guaranteeing
packet collisions at the digipeater site. What kind of reliability does
this offer the APRS community? It seems to me that Persist and Slot would
be a preferred method of channel access timing over DWAIT to avoid any
packet collisions.
Tim - N8DEU
Huntsville, Alabama
----------------------------------------------------------------------
Subject: Re: [ Tim Cunningham ] Re: Take Control of your DIGI part 4
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Tue, 30 Sep 2003 08:42:27 -0500
X-Message-Number: 7
>Thus, if a packet path has been altered
>by callsign substitution the digipeater is brain dead to the fact that it has
>already digipeated the payload. My point has been made the case has
>been presented as the reality of today's network.
I think that it has been stated here before that there are some versions of
the KPC that do not register packets that are RELAY, or WIDE in their dup
check mechanism. So, if they see RELAY, regardless of whether call sign
substitution is done, they will digi it, and if there is something else in
the path that causes another digi to digi the packet again, and there is
still a slot for digi a 3rd time, and the RELAY digi sees the packet again,
it will digi it again. This is the behavior described here many times. Are
you saying that you have discovered that if call sign substitution is off
that this case does not occur, and the RELAY digi will actually then do dup
checking? If so, then it sounds like part of the orginal bug has an extra
behavior related to a particular path in the code...
>Now, we can continue to ignore the reality of the network in how it really
>performs or ignore it and hope the firmware in all the digipeaters will be
>upgraded in the future, but I am not holding my breath that long. We have
>to make do with the current reality and work on the future.
While extra digis of a packet into a particular area are problematic, that
is only part of the problem. The DX traffic is something that others seem
to find more problematic it appears...
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: Take Control of your DIGI part 4
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 30 Sep 2003 09:50:59 -0400 (EDT)
X-Message-Number: 8
On Mon, 29 Sep 2003, Spider wrote:
>Bob, How come 4 land has the brunt of the...(never mind).
Cuz we were first. And old hams never upgrade... :-)
>My KPC 3+ manual states;
>
>"If you assign the same call sign to UIDIGI and MYALIAS, a to-be-digipeated
>frame with that call sign will be digipeated
>according to the rules that apply to UIDIGI."
>
>Another thought...... (flame suit's coolant is activated)
Meaning if both are set to RELAY, they it will callsign substitute. But
if RELAY is only in MYalias and not in the UIDIGI list, then it will just
alias and not callsign substitute. That note is simply saying that in
the confusion of having them both set, that the UIDIGI will overrule...
>I think DIGI's should only run ONE (1) of the three common 'names' (being
>RELAY or WIDE or TRACE).
>In other words, in your local network, if you are going to be a WIDE, then
>be a WIDE and do not be a RELAY. If you are a RELAY, then you are not a
>WIDE, so don't be one. Define them. Use them to take advantage of
>coverage!
Ah, but if a mobile uses the generic path of RELAY,XXXXX and he is
driving near one of your WIDE only digis, then he is out of the network
even though he is under a digi. That is why all digis have to do
RELAY...
>Now with that thinking, you think that might reduce the copies of packet
>flying around if a guy was set to RELAY,WIDE,TRACE? Comments?
I think it is time to obsolete TRACE because we no longer need to
distinguise between the old WIDE-ONLY digis (that cannot do call
substitution) and those that can (because we are going to elminiate all
digs that dont do callsubstitution. This then frees up one of the UIDIGI
calls for local use...
bob
----------------------------------------------------------------------
Subject: Re: UIDIGI and DWAIT setting
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Tue, 30 Sep 2003 09:24:29 -0500
X-Message-Number: 9
>Bob, I gather that you are advocating that DWAIT is more important than
>avoiding a packet collision. It is my recollection that Persistence and
Slottime>methods are effective, but everybody on the channel must use it to be
effective.
>If we use the antiquated DWAIT method, we are guaranteeing packet collisions
>at the digipeater site. What kind of reliability does this offer the APRS
community?
>It seems to me that Persist and Slot would be a preferred method of channel
access
>timing over DWAIT to avoid any packet collisions.
This is a good question! Here's the logic the way I see it.
Digi receives packet.
- If any other non-digi station heard that packet, CSMA says they are
holding off on their transmit.
- If any station transmitted at the same time because of hidden xmit'r
or exact timing, FM capture only let the digi hear one of them, so
that one is already lost.
- Any station preparing to transmit will hear the digi's carrier and
hold off.
Digi immediately retransmits packet
So, if all digi's have DWAIT=0 behavior, all that hear the packet will
transmit it at the time of receipt, and thus create the fratricide that
will make sure that only a single air/time-slot is taken in the local are
of the originating packet, for the first digi.
For a packet that is, or begins with RELAY,WIDE, if three digis hear it
direct from the originating station, they will all transmit it with WIDE
available to the next layer of digis. If the next layer all have DWAIT=0
behavior, they will all take the WIDE. Now, the original RELAY DIGIS will
hear the packet comming back from the second layer that took the WIDE. If
they are all DWAIT=0, and there is anything left in the PATH, they will all
repeat the packet one more time, together, and as long as it is a UIFLOOD
element, the packet will not be retransmited in that area any more.
If the DUPE check was done with RELAY and WIDE packets, then there would be
no dupes.
If DWAIT=0 is off, and the DUPE check bug exists, then there will be many,
many copies of the packet circulating as everyone gets their chance and
RELAY, and then WIDE, and then whatever comes after that.
Fratricide is important, either way, but with this firmware bug regarding
DUPE checks, it seems to me that it is very necessary behavior!
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: UIDIGI and DWAIT setting
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Tue, 30 Sep 2003 09:50:12 -0500
X-Message-Number: 10
>If DWAIT=0 is off, and the DUPE check bug exists, then there will be many,
>many copies of the packet circulating as everyone gets their chance and RELAY,
>and then WIDE, and then whatever comes after that.
>
>Fratricide is important, either way, but with this firmware bug regarding DUPE
>checks, it seems to me that it is very necessary behavior!
Would that opinion be different if the dupe check routine worked correctly?
The point being made is that we should not mask a problem with another
solution. Then, do we tolerate digpeater behavior that creates collisions
with other digipeaters.
What happens to the person who resides between the two digi's during
a digipeat operation heard by both digipeaters. The probability they will
not decode the packet is great.
Would you want that behavior in a system that might used in a life or death
situation?
The issue affects packet reliability and integrity of the network.
Tim - N8DEU
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
