[nos-bbs] Unanswered emails & tracking REJ, FRMR, RNR, RR, AX25 performance
George [ham] VerDuin
k8rra at ameritech.net
Mon Oct 18 16:39:51 EDT 2010
Good day Maiko.
On 10/18/2010 01:18 PM, Maiko Langelaar wrote:
> Good day to all,
> <<SNIP>>There really is no way to track RR, RNR,
> REJ, FRMR, and other packet statistics in NOS, is there ?
With some creative GREPing you might come close and it might take
several passes to make numbers out of the trace collection. Getting the
raw numbers may be scriptable, but some manual effort is needed to make
Using grep to find the RR [or whatever] packets, the parameters of "- n"
and "+ n" to pass additional lines, and piping to additional greps has
served me fairly well to grasp some configuration number performance
issues. Ultimately grep can give a packet count number for stat purposes.
As an alternative approach, I used awk to assemble the multiple line
trace into a one-line-per-packet string for later study by grep.
Although one line is simpler, the extra step was never more useful than
the approach in the former paragraph. You are welcome to it if you want.
> If I
> could collect those stats on a per station basis, perhaps it
> would help me in optimizing the parameters (like drive levels,
> volume control, etc, etc). The reason I bring in 'per station'
> as a basis is many times there are problems specific to only
> my station and someone else.
I agree that per-station is most meaningful. However there is some
missing information [I believe] that is most useful for this type study
-- failed packets/frames. I believe only "good" packets make it into
the trace, munged up packets get dropped into the bit bucket. Signal
bursts that fail checksum, character count, or some other features do
happen here and never show up in trace. So trace analysis yields the
tip of the iceberg when fine tuning makes sense, but misses the below
surface berg where stuff is "real bad"?
One of the other tools I have used is audio analysis package with FFT
waterfall and oscilloscope-like signal trace displays. I found it
useful to listen in for clipping, double transmitter collisions, tuning
centerlines, and so forth. I now have a BOONTON 8210 to tune VHF/UHF FM
that I won't trade in until I quit this digital ham stuff.
> Any comments ? Has anyone ever tracked this stuff ? It would
> take very little to add statistics code to JNOS to collect
> this information, so that it could be graphed. I would like
> to do it, so that I can better fine tune my baycom board
> for instance.
A couple(?) years ago I submitted a patch I found useful to you that
spit out tcp/ip packet counts, retry counts, etc,. At the time, I
thought that capturing AX.25 stats was my next step since ip is encapped
in ax. My presentation ran into a buzz-saw with some folks who thought
jnos tuning was already as good as it could get, so I dropped the AX
part for lack of interest.
> Or perhaps I am being too presumptious in saying that drive
> and volume levels have a direct correlation to the number of
> FRMR packets received ? In the end I just to be able to get
> more information to help me optimize my links.
OH NO -- keep at it. The toolkit I developed helped me tune two nodes
of AMPRnet with a noticeable improvement in bandwidth [bytes transferred
per time] and my toolkit is incomplete. If you developed some approach
that captured stats for outside analysis [say by matlab] it would be
The one caveat I offer is that it may be like the doctor who perfects
the appendix transplant [the operation may be a success but nobody wants
> 73 Maiko Langelaar / VE4KLM
Cheers and I hope you will find your stride again without further grief.
More information about the nos-bbs