Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ncar!csn!boulder!daemon
From: BILLW@mathom.cisco.com (WilliamChops Westfield)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Terminal server hangs
Message-ID: <35153@boulder.Colorado.EDU>
Date: 17 May 91 01:28:45 GMT
Sender: daemon@boulder.Colorado.EDU
Lines: 67


   We have experienced delays as well.  ... between our TS and our Sun 4/490.
	...
   Terminal server acks with window size of 870,
   Sun responds immediately with 7 bytes
   Terminal server acks with window size of 863,
   Sun responds 5 seconds later with 863 bytes......

This is the SWS avoidance algorithm bug I mentioned eariler - it tends to
cause short pauses, 5-10 seconds or so.


    This isn't what we're seeing.  We see it on connections to at least
    half a dozen different systems and the symptomology is very different
    from what you describe.  The pauses are substantially longer than 5
    seconds (I timed one at a minute and a half) and are most noticed
    during interactive echoing as delays in the echo time.

And this is apparently something entirely differen; something we don't
understand at all yet.


    In our case the symptoms seem to have gone away again.  This coincided
    pretty closely with end of classes, so I'm getting more convinced that
    it's a total box load issue.  I wonder if BillW could comment on how
    the system degrades when the total output rate approaches the box's limit.

In all the performance tests that I've run, the system has degraded
"gracefully" when run past its limit.  That is, all the lines slow down
a little bit, rather than a partiular line being starved.  Input is still
processed and sent on to the host, and so on.


    Could this affect other lines without as much output?

Yes, but not catastrophically.  Essentially, the scheduler is a round-robin
sort of thing, so that all other users get some cpu time before the current
user gets to run again.  The IP input process is the only one that runs
at a higher priority - if you send the box a fast stream of IP packets, say
filling up the window with 1 byte TCP packets), it is conceivable that the
box would be unresponsive durring that time.


    Might it cause lost interrupts on the Ethernet interface?  What affect
    would THAT have?

Very doubtful.  The ethernet drivers (what kind do you have?) do not assume
that there is only one packet per interrupt, or anything so foolish...


    Would it just drop an incoming packet or two (which would cause short
    delays awaiting retransmit timers) because you didn't pick them up
    from the interface in time?  Might it cause packet output to stop
    (this was one symptom we thought we noticed last time but didn't have
    sufficient data to prove) because you missed an interrupt that said
    you could send now.

The ethernet driver could "hang", but it includes code to detect such
things, and will reset the interface when it happens.  No one who has
this problem has had an inappropriate number of interface resets...

If the console responds during these periods, I'd like to get the output
from show process/interface/tcp DURRING the hang.  That might help a lot.

Bill Westfield
cisco Systems.
-------