Re: pipes & ptys

[Juergen Lock <nox@jelal.north.de>]

itschere@TechFak.Uni-Bielefeld.DE writes:
> Juergen Lock
> > 
> > > Well, what else can I do in a Program like a window manager, if I've
> > > got to look for every char?
> > 
> >  well Eric said that already but in different words... :)  a 1k RAW
> > read() does not block until it has read 1k, only until _some_ data is
> > available. (pty master reads are always RAW)  if it receives 200 bytes
> > (i.e. pty slave write()s 200 bytes) it returns 200 bytes, if data comes
> > in 1-byte-at-a-time it reads 1 byte, or whatever has accumulated in the
> > buffer (pipe) since the last read.
> > 
> >  so look at each char does not mean you need one system call for each
> > char...
> 
> Ok, got this, but: (see my other mail) it will return as soon as ther is
> some data, say, when it get's its next time slice, which is 16ms long on
> my 60Hz TT-VBL, right? Now I estimate that the writer (if really (worst case,
> of course, but that's what counts.)) using 1 bytes I/O, doesn't manage
> to output more than something like 30 chars per timeslice, so 60 slices
> a 30 bytes (always completely ignoring the time I need to read the data),~

 this is the time we're trying to improve...

> makes 1800 CPS, and that looks like the number I've measured.

 how much cps does the writer get when you send it to /dev/null
instead?  the difference between that and your 1800 is the only thing
we can improve here of course... for more the writing program has to
use longer writes.
> 
> > >   Point is that system calling overhead is soooo big that it doesn't matter
> > > a lot if the pipefs has got to do 1 or 4 bytes read.
> > 
> >  yes but it doesn't... have to do single-char IO.  and when you have
> > larger read/writes this character shuffling can cause overhead of
> > n times the size of the actual device IO.
> 
> Perhaps we can start a personal dispute about this, but so far I heavily
> doubt this. Sorry, no proofs so far... :-(
> 
> > type			read	write	speed (CPS)	% CPU load (top)
> > -----------------------------------------------------------
> > pipe			4096	4096	270000
> > pty			4096	4096	a bit less
> > 
> >  pty output would get nearly as fast as the pipe, and serial ports could
> > run full speed and no longer eat up all available cycles...
> 
> If a) you really use big chunks and b) modems are operated by interrupt...

 yup!  actually modems are operated by interrupts already, only
the buffer status is still polled and data is read/written
one-byte-at-a-time...
> 
> > >  At least at my setup the involved device
> > > drivers can easily be fixed.
> > 
> >  hmm how do you mean that?
> 
> Well, to make the biosfs drives expect char pointers instead longs. None
> of my program _seems_ to complain about this. But obviously that's no
> compatible solution... ;-)

 and i guess none of your programs use scan codes...

 :-)
	Juergen
-- 
J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
								...ohne Gewehr
PGP public key fingerprint =  8A 18 58 54 03 7B FC 12  1F 8B 63 C7 19 27 CF DA