[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]

RE: Line send delay (I've seen the problem)

John Stoffel john.stoffel@taec.toshiba.com
Fri, 14 Dec 2007 07:35:52 -0800 (PST)

David>   I agree with John, that problem should be mitigated by the
David> controlling (script-sending) host.

This is really the only place that this can be handled, since the
problem is NOT that the speed of sending the data is too fast, it's
that the device on the other end doesn't buffer it's input properly
when it's doing it's own processing, so you can overrun it.

This is not a new problem at all, it's been around for ages and trying
to fix it in Conserver isn't the right place.  

David>   But, it would be nice if there were a way to tell a Console
David> Server port to slow the outbound traffic (from the console
David> server to the attached serial console), so that many different
David> admins using different clients wouldn't all have to learn how
David> to solve this problem individually. 

Fine, drop you conserver to 300 baud, I'm sure that would be slow
enough.  *grin*

David> Of course, the inbound traffic (from the serial attached
David> console to the console server) should not be 'paced', as that
David> would reduce the capacity of how much you could log in a given
David> time window.

But what if my conserver host can't log data that fast?  Shouldn't we
have the ability to slow down the receiving side as well, so that many
different admins using different servers wouldn't all have to learn
how to solve this problem individually?  

Ok, so I'm being a smartass here.  But the issue is the same to my

David>   So far, I can't find a way to do this on the console
David> servers. I guess this is another 'feature request' to be
David> considered by the Console Server manufacturers... and they'll
David> only add it if we (their customers) ask for it. Even if you
David> don't need it today, you might need it later. ;-)

For this specific problem, just use expect, it's the real solution,
since you need to implement a hand-shaking like process here.

      -> send input
      <- wait for response
      -> send more input
      <- wait again...

There's nothing in here that conserver can help with, it's just the
wrong place to try to slow things down.

Really, look at expect first.