i/o speed (was: pipes & ptys)

[itschere@techfak.uni-bielefeld.de]

Juergen Lock

> > 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 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...

feel free to do so... :-)

> > 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.

naturally more, don't know exactly, but sure not 10 times as much... :-(

to summarize it:

if a program chooses to output one char, say, through a piped pseudo
terminal, it looks more or less like this:

Cconout('!') ->
Fwrite(?, 1, "!") ->
tty_write(...) ->
tty_putchar() ->
pipe_write().

and the reader get's:

Fread() ->
tty_read() ->
tty_getchar() ->
pipe_read().

and in the meantime, half an hour is gone... ;-(

> > 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...

to be more accurate, only incoming bytes raise an interrupt, but for outgoing
the i/o chip is polled to see if it's ready. perhaps not immediately after the
byte was send away, but before a char is to be send. at least the MFP does also
support an interrupt for "output-buffer-empty", the newer chips also, I think.
but as far as I know, these are not used so far.

by using these and a new buffer managing, completely obsoleting the bios,
you'll gain lots of speed, I presume... :-)

bios routines may then be emulated with an fwrite(1,...) call for
backwards compatibility.

> > 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...

good question... I THINK not, since if I use a modem channel, the remote one
is likely not to be an atari, and if i use pseudo ttys, all I want are things
like cursor keys, and I can get these by using XKEY emulation. at least it
looks like this works for tcsh, jove & emacs on pipes. correct me if I'm
wrong. So I THINK just MiNT itself and... well... really, for me, nothing
else uses scan codes.

bye,
TeSche
---
PS: If the above written looks weird, than that's because it probably IS.
WhoDunnIt: Torsten Scherer (Schiller, TeSche...)
Technical Faculty, University of Bielefeld, Germany (53'5"N 8'35"E)
EMail: itschere@techfak.uni-bielefeld.de / tesche@dave.hrz.uni-bielefeld.de