You can't spell "evil" without "vi".
Denys Vlasenko
vda.linux at googlemail.com
Sun Oct 19 18:59:55 UTC 2008
On Sunday 19 October 2008 06:22:37 am Rob Landley wrote:
> Heh, ok, now I found the message. (Just because I'm paying attention to the
> busybox list again doesn't mean I've got my mail filters set up right yet. :)
>
> > But scheduling in the sender can.
>
> The sender almost certainly is using something like a 16550a UART, which has a
> 16 byte output buffer. (In addition the kernel may insert a pipe buffer on
> the output side.)
>
> If your escape sequences are written to the char device as single blocks,
This case is ok. Bad case is:
while (1) {
n = read(fd1, buf, 1000);
if (n <= 0) exit(0);
write(fd2, buf, n);
}
if fd1 is a serial line, we easily would read ESC sequence byte-by-byte.
If fd2 is a network, we will feed it byte-by-byte to network.
Since read() usually blocks, it can be delayed for *seconds*
if there is enough load on the system.
> the
> main reason for your kernel to block the sending process is because the
> output buffer filled up. (Other reasons to block shouldn't decouple the
> sequences, either it blocks before sending or you're in the kernel and the
> whole sequence gets queued atomically.) This means you have at least 16
> chars worth of transmission time for the sending process to get scheduled
> back, and here slower rates _help_ you; at 1200 bps that's 100ms.
>
> > If sender is not a hardware
> > but a process (say, sitting on the other side of ssh) and it
> > takes input from, say, serial line, it may read only one char, ESC,
> > and send it to us over ssh. Then it will read more and send more to us.
> > Delay between ESC and the rest here is affected by how *that process*
> > is scheduled, and there scheduling delays can not be predicted.
>
> A) Your example seems fairly contrived; ssh by itself can't do that, and ssh
> going _into_ a serial line can't do it either (it gets the 16 byte buffer).
> You need _two_ levels of reblocking for the case you're talking about to even
> come up.
How about "ssh from serial to network"?
Log in to your router over serial line and then ssh from it somewhere.
> B) The http://en.wikipedia.org/wiki/Nagle_algorithm is the default on Linux,
> and its _job_ is to re-coalesce exactly this sort of thing. :)
ssh turns it off for interactivity reasons.
--
vda
More information about the busybox
mailing list