[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
i/o speed (was: pipes & ptys)
> > 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:
Fwrite(?, 1, "!") ->
and the reader get's:
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
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
> > 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.
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: firstname.lastname@example.org / email@example.com