[nos-bbs] Collision avoidance

Fri Aug 11 12:05:56 EDT 2006

Kewl Steve - yes you got no bananas...

On Fri, 2006-08-11 at 11:10 -0400, Steven Stimpson wrote:

>  
> 
>  
>         ----- Original Message ----- 
>         From: George (Skip) VerDuin 
>         To: TAPR xNOS Mailing List 
>         Sent: Friday, August 11, 2006 10:40 AM
>         Subject: Re: [nos-bbs] Collision avoidance
>         
>         
>         > 
>         >  
>         > 
>         Actually - I don't mind the wait to get a 1/2 second opening
>         to jump into.
>         My trouble is not waiting...
>         
>         This is a side-light information...
>         I found some distressing frames I don't know how to produce
>         even if I tried.
>         MAXFRAME allows packing multiple packets into a frame /
>         however / I see multiple repeats of the SAME packet in a
>         frame.
>         This smells BAD to me. 
>          
>          
>          SKIP:
>          
>          1/2 second is too short, that is shorter than most SLOT times
>         and TXD will allow,
>         as a matter of fact a lot of people use an actual TXD greater
>         than 1/2 second.
>         1/2 second between transmissions is way too short, IN short,
>         they
>         are "Hogging" the frequency using aggressive timings. In other
>         words YOU have seen the light of day and are going to use
>         persist and slots.
>          If the time between thier tx is really that short, they are
>         using neither.

One of the reasons for my focus on the RF side is to see what my
neighbors are doing.
Your analysis is pretty good - especially on track for one guy who is
gaining a "reputation" around here...

I'll be adjusting SLOT and PERSIST now that they are functioning - this
is confirmation that Jay was on track.
>          
>          
>          
>         The repeat Packets. I have been complaining about this for
>         years with KISS. The
>         fault is not JNos or your Tnc, it is the fact that the ax.25
>         protocol is seperated
>         from the tnc and resides in your computer. the computer does
>         not know that your
>         tnc has been waiting 5 seconds to transmit frame number one,
>         so IN
>         the computer the frack timer expires, and the computer sends
>         it again. your only solution
>         is to set a really high frack timer. this will slow things
>         down, but will stop
>         the DUP frames. I use KISS mainly on H.F. and the wait times,
>         at 300 baud,
>         between frames can be great, and we run into this problem a
>         lot. This problem
>         would also be solved if the TX'ing stations would reduce
>         maxframe and paclen.

That makes sense.
Now the challenge is to motivate FRAC changes in the neighborhood.
Or possibly the exponential retry formula?
>          
>         the problems you are running into with slots, persist, and
>         frack>kiss expiry are
>         all symptoms of an EXTREMELY busy frequency, or if only a
>         couple stations
>         are present, some rather rude Parms are in place.
>         I see no evidence of duplication thus FRACK may be OK... 

Of course you recognize this reference is to my frac only.
Of course my frack was defeated by my mis-set parameter.
So now my frac is subject to adjustment too...

This is one of those "the deeper you dig the more you find the deeper
you must dig" things.
>          
>          
>          
>          
>         Look up ^^^^^ you said you are seeing multiple dupes in the
>         same
>         "Frame".  A frame and a "Packet" are the same thing. the
>         multiple
>         packets you are seeing sent to the tnc is a matter of
>         the kiss protocol. if you have maxF set greater to one,
>         say, rudely, to four, then your jnos, in KISS< will send four
>         Frames in one Burst to the tnc. If you are seeing more than
>         one
>         of the same "frame" or "Packet" in the same burst then the
>         frack timer is
>         indeed too short for the channel conditions. Channel
>         conditions depending
>         on how many folks or how polite the channel users are being.

This vocabulary is problematic...
"encapsulation" is used with various contexts.
"Frame" seems to have various applications in different OSI model
Layers.
"packet" gets used more broadly perhaps than is appropriate by the
strict definition.
You introduce "burst".
One of my challenges in this business has been to adapt vocabulary in
order to communicate...
It's more art than science (my opinion).

Strictly, I should take exception to your statement " frame and a
"Packet" are the same thing.".
But I believe I understand your point after reading the entire
paragraph...
If I am, then:
The duplication of packets in a burst (I call frame) is the result of
computer software believing the link is broken and in need of repeat
packet transmission.
The solution involves changing timers at the computer and perhaps
reducing packet stacking for the TNC.
>          
>          
>          Only trying to help so please don't tell me to "remove the
>         bananna" this time :-) :-)

My guess for what to do next is to create an awareness for the concept
of "useful traffic thruput bytes per minute" in the area.
Then get measurements established and shared.
I doubt that the stations stacking up repeat packets know it is
happening and don't have tools to "see" it.
And the "speedometer" seems useful in several contexts.

It's part of the hobby?
>          
>         Steven N1OHX
>          
> 
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs

73
de Skip k8rra k

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20060811/761ef76a/attachment.html>