Michael E Fox - N6MEF
n6mef at mefox.org
Mon Jun 9 22:15:38 EDT 2014
Right. Thanks Ken.
These documents are interesting:
They reference at least one TNC that will not really make use of maxframe > 4.
The above papers also show diminishing returns for the throughput for each value above one (in a clear channel). Going from 1 to 2 results in a little better than 10% improvement. But going from 2 to 3, 3 to 4, etc., provides a smaller and smaller advantage, while incurring an increasing disadvantage when conditions are bad. We’ve been using a compromise of maxframe = 2 in our network and it’s worked well.
But I just discovered that the Kenwood TH-D72A has the value hard-set to 1. Perhaps that’s simply a cost reduction engineering choice. But it reminded me of all of the references I’d seen (like the JNOS manual) that said 1 is ideal without any explanation. It got me wondering if there was something I was missing.
From: nos-bbs-bounces at tapr.org [mailto:nos-bbs-bounces at tapr.org] On Behalf Of kd6oat
Sent: Monday, June 09, 2014 6:20 PM
To: TAPR xNOS Mailing List
Subject: Re: [nos-bbs] MAXFRAME
According to my old PK-232 operating manual, "MAXFRAME limits the number of unacknowledged packets the tnc permits on the radio link, and the number of continguous packets your tnc will send in a single trnasmission. The "best" value of MAXFRAME depends on your local channel conditions. In most cases of local keyboard operation, the default value of MAXFRAME of 4 works well. When the amount of traffic is heavy, the path in use is poor or you are using many digipeaters, you can actually impove your throughput by reducing MAXFRAME. Use MAXFRAME 1 for best results on HF packet."
I believe MAXFRAME works in concert with FRACK and RETRY commands. My other old packet handbook explanes that when a MAXFRAME setting of 4 is exceeded, "additional packets will not move into the TNC or controller until awaiting messages area acknowledged or their path has been discontinued."
While the exact "why" remains somewhat elusive, I hope that is helpful.
On Mon, Jun 9, 2014 at 5:54 PM, Michael E Fox - N6MEF <n6mef at mefox.org <mailto:n6mef at mefox.org> > wrote:
Yes, the manual states the optimal value is 1 but gives no reason or
explanation of why.
My email asked for the why.
From: nos-bbs-bounces at tapr.org <mailto:nos-bbs-bounces at tapr.org> [mailto:nos-bbs-bounces at tapr.org <mailto:nos-bbs-bounces at tapr.org> ] On Behalf
Of Charles Hargrove
Sent: Monday, June 09, 2014 3:28 PM
To: nos-bbs at tapr.org <mailto:nos-bbs at tapr.org>
Subject: Re: [nos-bbs] nos-bbs Digest, Vol 118, Issue 1
I have been using a value of 1 ever since I first set up my system back in
late 90's. The JNOS manual was my guide and it makes sense.
>From the JNOS manual:
ax25 maxframe [<count>]
Establish the maximum number of frames that will be allowed to remain
unacknowledged at one time on new AX.25 connections. This number cannot be
greater than 7. Without <count> it will display the current setting. Note
the maximum outstanding frame count only works with virtual connections. UI
frames are not affected. Also note that for optimal performance, a value of
should be used. Default is 1 frame.
This parameter controls the number of I-frames that may be send on an AX.25
connection before it must stop and wait for an acknowledgement. Since the
AX.25/LAPB sequence number field is 3 bits wide, this number cannot be
than 7. It can be shown that the optimal value is 1.
Since unconnected-mode (datagram) AX.25 uses UI frames that do not have
sequence numbers, this parameter does not apply to unconnected mode.
> I'm trying to optimize the value of MAXFRAME.
> I've seen statements on the web such as "for best efficiency, use MAXFRAME
> 1", but no evidence or explanation is provided. In fact, a window size of
> just one is usually the LEAST efficient way to go.
> So, what are you guys using for MAXFRAME out there?
> How did you decided on that value?
> Do you have any evidence (experimental, annectdotal, or otherwise) that
> you to use that value?
nos-bbs mailing list
nos-bbs at tapr.org <mailto:nos-bbs at tapr.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nos-bbs