[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]
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 mind. 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. John