[nos-bbs] Interested in REPEAT packet statistics?

[Kenneth C Coe Jr]

Sorry about the delay in answering. It is a very hectic time for me
right now.

On Wed, 2010-04-14 at 08:39 -0400, George [ham] VerDuin wrote:
> Specifically to Jay and Kenneth,
> We do have a failure to communicate.
> 
Yes, we do.

> 
> On 04/14/2010 05:23 AM, Jay Nugent wrote:
> > Greetings,
> >     I will add to what both Ken and Barry have stated -- the information
> > you provide is only partial.
> >    
> Correct -- only partial.
> Intentionally so.
> Please stop thinking about *how* to fix something wrong.
> Please focus on *when* do you decide something is broke and worth fixing.
> 
> I have no intent to present WHAT the problem is, nor how to address 
> whatever the problem might be.
> The only issue the stats address is:
> 
>            *Does a problem with re-transmission exist during the period 
> of study.*
> 
Of course there are re-transmits. there is not a network in the world
that doesn't have them. It is written into the standards because it
cannot be eliminated. The question is never if there are re-transmits,
but whether there is an unreasonable number of them given the status of
the network. There is no answer to the re-transmits in your data, and
you make no attempt whatsoever to provide a baseline of what is going on
at the time of your tests.

> Even the answer requires experience and interpretation, some 
> re-transmission is normal.
> We don't live in a perfect world.
> 
> My thesis is that given the kind of data I presented at the beginning of 
> this brew-ha-ha, above  some number seen as:
>      =>percentage of repeat traffic
> the reader would choose to take the kind of action you have outlined.  
> Not before.
> Especially not before because the existence of re-transmission is not 
> monitored in normal operation.
> 
I don't see a brew-ha-ha...

I also didn't see a percentage of traffic. I saw no total of anything
usefull. That would require total data verses retrans data, and would
include a dump to analyze with it. You would also be expected to provide
detailed information on the infrastructure being tested. If you are
talking about RF, we would usually also request a map of any
identifiable sources which, theoretically, could cause interference.

> Remember -- Automotive engineers gave us the idiot light, they didn't 
> choose to tell us oil pressure is low.

This could be because they got many complaints from people who misread
them.
> 
> SO -- On the *single* issue of "Does a problem exist"

Maybe, maybe not...

> Not how big is it
> Not where is it
> Not what caused it
> Especially not what to do about it.
> What do you say?

If you go to a mechanic and say "my car is slow" he might ask if you
have tried hitting the gas. The numbers you gave us can say nothing, and
indicate nothing. there is no answer there, positive or negative.


> Or perhaps you can't say because you have no statistical experience?
> I gave you the script so you could have the experience if you choose.
> If you don't choose -- that is OK too.

You need real numbers to be able to analyze... Any good statistician can
tell you that the only thing that lies more than statisticians are the
statistics themselves. Statistics is just the manipulation of raw data.
The quality of the statistics is a direct correlation to the data, the
selection of the data, and the selector of the data. As they say,
"Garbage in, Garbage out." 

Your data doesn't represent a pattern, a run, or a trend. It doesn't
even have the balance of comparisons. The data has no merit. The script
doesn't provide anything useful. Your script does not include the vast
majority of the information necessary to diagnose anything.

Since you asked I will mention that, as some others here can attest, I
have quite a bit of experience in a very broad range aspects of network
management from over 17 years of professional experience in the field.
Since you referenced Jay in this, I would point out that he has a level
of experience in this that I would rank WELL ABOVE expert. He IS, after
all, a professional network specialist.

Since you reference my experience (I will politely ignore whether it was
a challenge), here is my last piece of advice, taken from 17 years of
experience and the 250,000 or so pages of RFCs sitting on my hard
drive: 

You are starting with broken numbers. Follow the source of the data
flow, and start from the ground up. This is also a simple old school
breakdown for anyone here new to networking:

Keep a baseline if you want to track this. Follow the traffic flow, and
follow the packet. Monitor for the problem, if there is one, and test
when it is consistently failing (if possible) to make it easier to find.

The vast majority of the time, the problem is physical. This is radio,
is there interference? Is the ack delayed by traffic to the second
station that you cannot hear from yours, as this is standard if it is
receiving? IS you radio and equipment in proper order, and is the
equipment on the other side (you never answered this one from over a
month ago, Skip)?

Move on only after you have completed this first step, but I sense that
you may doing some work at this level. In the mean time, provide a link
to download the dump, and we'll try to take a look for you.

Ken