madler@piglet.caltech.edu (Mark Adler) (08/17/90)
So howcums it is that my 25 MHz 32 bit NeXT "mainframe" can't keep up with my 2 MHz 4 bit HP pocket calculator when the latter is running a 9600 bps serial line into the former? Seems like a pretty sorry state of affairs. Mark Adler madler@piglet.caltech.edu
rca@cs.brown.edu (Ronald C.F. Antony) (08/18/90)
In article <1990Aug17.134755.25158@laguna.ccsf.caltech.edu> madler@piglet.caltech.edu (Mark Adler) writes: > >So howcums it is that my 25 MHz 32 bit NeXT "mainframe" can't keep up >with my 2 MHz 4 bit HP pocket calculator when the latter is running >a 9600 bps serial line into the former? Seems like a pretty sorry state >of affairs I guess the main problem is, that the NeXT has not a real time operating system. As in UNIX tasks can be swapped out or otherwise inactive, there is no easy way of making sure that a certain minimum response time can be kept. I guess how NeXT could deal with that is if they had a special thread controlling the serial IO, similar as they do it with the sound. But I don't know if this wouldn't sacrifice UNIX compatibilty. In case you don't know it, as always: The next release will solve the problem :-) Ronald ------------------------------------------------------------------------------ "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." Bernhard Shaw | rca@cs.brown.edu or antony@browncog.bitnet
verket@venice.SEDD.TRW.COM (Paul Verket) (08/18/90)
From article <1990Aug17.134755.25158@laguna.ccsf.caltech.edu>, by madler@piglet.caltech.edu (Mark Adler): > > So howcums it is that my 25 MHz 32 bit NeXT "mainframe" can't keep up > with my 2 MHz 4 bit HP pocket calculator when the latter is running > a 9600 bps serial line into the former? I think you might have a flow control (or lack of it) problem. I run a modem at 9600 without any problems. Paul Verket
kloppen@gmdzi.UUCP (Jelske Kloppenburg) (08/18/90)
verket@venice.SEDD.TRW.COM (Paul Verket) writes: >From article <1990Aug17.134755.25158@laguna.ccsf.caltech.edu>, by madler@piglet.caltech.edu (Mark Adler): >> >> So howcums it is that my 25 MHz 32 bit NeXT "mainframe" can't keep up >> with my 2 MHz 4 bit HP pocket calculator when the latter is running >> a 9600 bps serial line into the former? >I think you might have a flow control (or lack of it) problem. I run a >modem at 9600 without any problems. > Paul Verket and I run two modems at 19200 without any problems. j.k. Jelske Kloppenburg, kloppen@gmdzi.gmd.de, (++49 2241) 14-2433 German National Research Center for Computer Science (GMD)
madler@piglet.caltech.edu (Mark Adler) (08/20/90)
In response to my 9600 bps serial question Paul Verket writes: >> I think you might have a flow control (or lack of it) problem. I run a >> modem at 9600 without any problems. and Jelske Kloppenburg adds: >> and I run two modems at 19200 without any problems. Paul is quite correct---this is a case where the calculator does not respond to xon/xoff flow control. I posted my question aware of that, with the belief that my NeXT should be able to keep up with the incredibly low rate of about 1000 characters per second WITHOUT having to slow down the source to less than that. It seems clear to me that the hardware is more than capable of that, and that the serial drivers are not getting the resources they need (physical memory? cpu?) to do the job. By the way, this is when the computer is not engaged in any other activities (at least no others that I've requested, and I'm the only user). Also, Kermit transfers from my calculator also experience an undue number of packet failures and 9600 bps, and I suspect that the cause is the same: lost characters in long continuous transmissions (in this case, long is only about 100 or so characters, the length of a packet before Kermit wants an acknowledge). I hope that NeXT has tried to improve or is improving the serial drivers for version 2.0. Mark Adler madler@piglet.caltech.edu
robertl@rlaferla.lotus.com (Robert La Ferla) (08/22/90)
Changing the priority of the kermit program and/or terminal processes may help the problem - although I'm not entirely sure. The command to do this is "renice" - You need to be super user to renice anything to a higher priority. Robert La Ferla Disclaimer: "My thoughts are my own."