You can't spell "evil" without "vi".
Rob Landley
rob at landley.net
Sun Oct 19 19:51:16 UTC 2008
On Sunday 19 October 2008 13:59:55 Denys Vlasenko wrote:
> 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 whole point of the Linux scheduler is to provide something I/O bound like
this with low latency wakeups, even in the face of compute-intensive loads.
Con Kolivas spent years working on that, and Ingo Molnar picked it up when he
burnt out. That's why all the different schedulers.
The only way a truly I/O bound process that uses essentially no CPU can
be "delayed by seconds" is either:
A) You've got a fork bomb setting off thousands of processes and the system
is essentially melting down.
B) Memory is exhausted and parts of your program got swapped out, and I/O is
being heavily hammered so swapping it back in requires working through a
queue.
C) Your scheduler is broken.
I admit it's possible to do this, but if you're worried about that inserting
enough of a delay to defeat the nagle algorithm (defaults to 40 miliseconds I
believe) then why is 50 miliseconds in vi enough? And how is "can be delayed
for *seconds*" the reason for a 50 milisecond delay?
> > 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"?
That would be the two levels of reblocking I was referring to, yes.
> 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.
Ah, that might be an issue then. (Assuming you're connecting via an actual
serial cable to a router that's either running hundreds of processes or so
thoroughly out of memory it's discarding executable pages that were active 6
miliseconds earlier, which again seems unlikely but theoretically possible.)
*shrug* As I've said before, I had 300 miliseconds. I just thought the
comment you added was inaccurate, and a full discussion of the issue is
obviously too big for a source comment... :)
Rob
More information about the busybox
mailing list