[nos-bbs] Unanswered emails & tracking REJ, FRMR, RNR, RR, AX25 performance

[George [ham] VerDuin]

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 
stats.

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 
outstanding.

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 
it].

>
> 73 Maiko Langelaar / VE4KLM
Cheers and I hope you will find your stride again without further grief.
Skip