stevens@hsi.UUCP (Richard Stevens) (02/27/88)
Why is the 3b1's screen so slow ?? Just cat'ing a big file
to the screen shows a baud rate of only about 5500.
I'd guess its something to do with the window driver that
gets loaded by default. Is there any way to disable this
when its not needed - I'd be willing to give up the date,
time and phone status, for example, when using cu, so that
I can get something near the 9600+ baud of the Telebit modem ...
Also, what is everyone else using with Telebits, instead of
cu and the (ugh) ATE package ?? The ATE can't even keep up with the
1200 baud OBM and cu can't keep up with a Telebit. The problem with
cu is that its doing a read() of 1 byte at a time from the modem,
followed by a write() of that single byte to the screen. The system
call overhead destroys its throughput. I really don't want to have
to write a terminal emulator for the system ... (Is the ATE an
AT&T product ? I can't believe anyone let a package like this
out the door.)
Richard Stevens
Health Systems International, New Haven, CT
{ uunet | ihnp4 } ! hsi ! stevenswilkes@mips.COM (John Wilkes) (02/28/88)
In article <864@hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes: >Also, what is everyone else using with Telebits, instead of >cu and the (ugh) ATE package ?? I've been using fthood!egray's mdm program, and I am quite satisfied with it. (Thanks Emmet!!) Another possibility might be kermit, but I've not tried it. Too bad mdm does not support kermit file transfer.... Also, mdm gets a little confused when connecting to the remote system. My guess is that this is because the 'Blazer pumps back slightly different strings than the Hayes stuff that the program is expecting, but it's not enough of a pain for me to dive into the source and fix it. Hey Emmet, are you working on a new terminal program for the 3B1??? John Wilkes -- -- @work: -- {decwrl,ames,pyramid,prls}!mips!wilkes -- OR, for those of great faith: -- wilkes@mips.com
wilkes@mips.COM (John Wilkes) (02/28/88)
In article <1701@electron.mips.COM> wilkes@electron.UUCP (that's ME!) writes: >In article <864@hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes: >>Also, what is everyone else using with Telebits, instead of >>cu and the (ugh) ATE package ?? [...] >Another possibility might be kermit, but I've not tried it. Well, I decided to give kermit a test spin with the 'Blazer. Using it right now, in fact. Seems to update the screen a little faster than mdm, though it's a little hard to tell. Kermit also seems a little jerkier in its writing to the screen. In emacs, for instance, if I type a ^A to go to the beginning of a line, the cursor often does not move until I type a few more characters. Is this the 'Blazer packetizing in action, or is it the way kermit updates the screen. I have not tried any file transfers with kermit yet, though I intend to shortly. I set my protocol to support kermit (s111=10), so we'll see... By the way, my kermit is version 4E(067) 14 Sept 87. I believe this is the Kevin O'Gorman version. When in connect mode, it uses native mode, not vt100/ansi emulation. Which reminds me, I seem to remember someone posting an enhanced termcap for the unix-pc, but I can't seem to find it. Anybody have a better termcap than what's in /etc/termcap??? John Wilkes -- -- @work: -- {decwrl,ames,pyramid,prls}!mips!wilkes -- OR, for those of great faith: -- wilkes@mips.com
david@ms.uky.edu (David Herron -- Resident E-mail Hack) (03/02/88)
In article <864@hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes: >Why is the 3b1's screen so slow ?? I dunno? Is this one of those "Why did the chicken cross the road" questions? >Also, what is everyone else using with Telebits, instead of >cu and the (ugh) ATE package ?? The ATE can't even keep up with the >1200 baud OBM and cu can't keep up with a Telebit. The problem with >cu is that its doing a read() of 1 byte at a time from the modem, >followed by a write() of that single byte to the screen. The system >call overhead destroys its throughput. I really don't want to have >to write a terminal emulator for the system ... (Is the ATE an >AT&T product ? I can't believe anyone let a package like this >out the door.) Well, I don't have a Telebit yet. When I did have one (for testing) I used ATE with it simply 'cause I didn't have time to set anything else up. We've got people around here that use 7300's (1 meg with 20 meg disk models!) as terminals all the time using ATE. It seems to run ok -- at least they don't complain about slowness. um, I suggest you check a little bit into what system calls are available on SysV, especially one as old as what we got on our 7300's. The only way you can write a terminal program on there is with the standard two processes, one read()ing and write()ing from modem -> screen, the other keyboard -> modem. The C Kermit does the exact same sort of thing -- with extra garbage code thrown in to see if it needs to do any logging and maybe even some code to handle parity conversions. And kermit works really well as a terminal program. That is, so long as you use the right kind of termcap entry on the far end. Me? I'm thinking of porting dnet over to the Unix PC. Especially since I've got an Amiga at home as well and he's talking about being able to set up a network of dnet nodes... But right now I'm using ATE 'cause it's really convenient to simply be able to pull up the phone manager screen and hit enter at the phone I want to call... -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- <---- It takes more than a good memory to have good memories.
stevens@hsi.UUCP (Richard Stevens) (03/03/88)
In article <8501@e.ms.uky.edu>, david@ms.uky.edu (David Herron) writes: > um, I suggest you check a little bit into what system calls are > available on SysV, especially one as old as what we got on > our 7300's. The only way you can write a terminal program on > there is with the standard two processes, one read()ing and > write()ing from modem -> screen, the other keyboard -> modem. The cu process that's reading from the modem and writing to the screen does a read() of 1 byte, followed by a write() of 1 byte. That's where the problem is. As Kernighan & Pike pointed out (p. 203) this will kill you every time. What you want to do is read a buffer at a time (say 1024 bytes) after calling fcntl() to make the fd non-blocking. (I can't remember the specific fcntl options - my S5 manuals are at home.) If you're prepared to receive 0 bytes (and do the read system call again) then if more than 1 byte is ready, you can write that same amount to the screen. I found this to be a big (i.e., factor of 20) win for something like cu. What's happening is the Telebit is passing characters to the kernel faster than you can do a read/write of a byte-at-a-time. It does make things a little more complicated if you want to parse the received data checking for special sequences to do things like save a copy of the modem data somewhere, but with modems approaching the speed of the Telebit, you CAN'T do system calls for one byte at a time i/o. Richard Stevens Health Systems International, New Haven, CT { uunet | ihnp4 } ! hsi ! stevens