[nos-bbs] Throughput measurements

[George (Skip) VerDuin]

Actually pretty simple Steve,

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

>  
> 
>  
>         ----- Original Message ----- 
>         From: George (Skip) VerDuin 
>         To: TAPR xNOS Mailing List 
>         Sent: Friday, August 11, 2006 12:05 PM
>         Subject: Re: [nos-bbs] Collision avoidance
>         
>         
>         Kewl Steve - yes you got no bananas...
>          
>          
>         Lost 'Em long ago... :-) :-)  Wait.... those were my marbles.
>         sorry.....
>         
>         
>         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.
>         
>          Oh boy would that be useful for KISS H.F. Jnos in particular.
>          Jnos adheres strictly to the ax.25 protocol, but Msys,
>         another
>         popular H.F. BBS program does not. It sends one ack for every
>         frame, even if those
>         acks are in the same TX. This causes a runaway condition
>         between Tnos
>         and Jnos stations when forwarding with Msys on H.F. via KISS.
>         WA8DED does not have this problem. 
>          
>          I am interested in your concept of "Useful bytes per minute",
>         how
>         to measure it, 

Apply KISS: Extract 120 seconds of trace, remove all header [overhead]
text, remove all duplication (including digis) text, probably the
received ACK for a transmitted TEXT needs to be included in the
filtering, count the first 60 sec of the result / this is the
measurement for channel traffic and is R#1.  Now count only text
for&from the specific node doing the measurement / this is measurement
for station traffic and is R#2.  Display "Max based on baud". R#1, R#2,
in bargraph or double line form for the past hour with MAX as display
top.

Now shift the extracted 60sec off the buffer, add 60sec from the trace
and repeat the process.  This shifting stuff is to be accurate over the
60-sec sample boundry.  And my use of "remove" should probably be stated
"exclude" since there is useful information for the analysis contained
in headers...

There are tools to measure backlog, like ax25 stat, but this leads to
tuning without considering the other guys...?  I'm like lot's other
users - my principle measure is how quickly I get a response to my
question.  Frustration raises as the square of the time.  Your other
premise is very well taken however, in even-handed use of spectrum you
simply can not tune to hog the channel.  My hope is that when your
personal demand goes higher and you see the channel thruput begins to
decline corrective action will maximize the channel.  Ever hear of
Utopia?

>         and then share.

Sharing only a string of Rs with time-of-day becomes useful to see
combined graphs to view the "unheard" traffic on channel.

>          It would bring much relief
>         to many H.F. forwarding networks, many of which involve
>         Jnos, so it's not too far off topic here. KISS is a problem
>         on H.F.

So is impatience?
>          
>          Regards Skip,
>          
>         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/b60d2857/attachment.html>