[nos-bbs] Tuning nos

[(Skip) K8RRA]

Thanks Jay for the technical briefing, it leads to a couple parameters
being reset from their previous values.

On Sun, 2008-03-23 at 02:37 -0500, Jay Nugent wrote:
> Greetings Skip,
> 
> On Sun, 23 Mar 2008, (Skip) K8RRA wrote:
> 
> > I have a situation and I wonder if others here have an improvement 

> >>SNIP<<
> > Further:  It *seems* like a huge waste of bandwidth.  Yet, I can't find
> > anything to change...
> 
>    It certainly can be.  But when users hear these "monster frames"
One fact I left out of my original story is that the requests and answer
packets were somewhat interspersed with each other, there was no
"monster frame" in this example...

>  being
> sent it is a good idea to identify WHO is sending them.  Then work with
> that user to determine why the frames became backlogged.
OK - contacting the originator IS something to put in the list of
remedial actions.  In the one case I put forward in this thread may have
a non-adjustable source.  I don't know this yet for sure, but I suspect
the smtp client was on a windows box configured for Internet with very
short timers not intended for radio -- and not resettable.  In order to
generate 38 requests to start up SMTP, "round trip time", "backoff
formula", and "smtp timer", all had to be set very short to cause this
size pile-up.

Perhaps the option that plays out will be to not use a particular
software when any of the TCP hops is carried by 1200B radio.  I'm not
convinced this is a jnos specific problem, just the bad karma rests
here.

>>SNIP<<
>    In the Michigan AMPRnet I still have a few nodes out there that have 
> their SMTP TIMERs set at 300 (5 minutes).  This is too short in some 
> situations and I have been extending them out to 15 to 20 minutes.  YMMV.
OK - ours were set at 10min, we will change both "smtp t4" and "smtp
tdisc" to 20.  As you know these timeouts can create a good period of
quiet to allow the channel to purge the backlog if the "smtp timer" is
set at least twice "smtp t4" [ours were set at 3x] to delay when smpt
will begin the next attempt to deliver.

> 
>    Skip, I had a LONG smtp message recently try to get across a rather
> slow RF path the other day.  It was unsuccessfull after several attempts.  
> It appeared the TCP session was timing out before the message completed.  
Yup -- I've seen similar effects.  Most of my observations involve jnos
going into "recovery" mode and it seems to take for ever to return to
"connected" mode.  Meanwhile back at TCP more repeat packets are being
queued because the ACK has been caught up in the log jamb.

> I never did figure that one out and finally gave up and read the contents
> of the senders /nos/spool/mqueue/<job_num>.txt file,
I'm presuming you telneted to the remote site for this look-about?

>  then deleted it
> (along with the matching .wrk and .lck files).  Sure, this didn't FIX the
> offending problem, but it quieted all the chatter on the air that
> afternoon :)
> 
>    Good luck in your diagnosis, sir!
Thanks Jay.  You know we've become pretty spoiled by Internet where we
can ship packets over many hops around the world faster than we can to
our 15mi away neighbor who is but one hop at 1200B.  Maybe I've just out
lived my TNC.  

73
de [George (Skip) VerDuin] K8RRA k