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