Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!brl-adm!rutgers!ames!ucbcad!ucbvax!YALE.ARPA!LEICHTER-JERRY From: LEICHTER-JERRY@YALE.ARPA Newsgroups: mod.computers.vax Subject: Re: JERKY output to DECserver-200 Message-ID: <8701120614.AA08920@ucbvax.Berkeley.EDU> Date: Mon, 12-Jan-87 01:14:18 EST Article-I.D.: ucbvax.8701120614.AA08920 Posted: Mon Jan 12 01:14:18 1987 Date-Received: Mon, 12-Jan-87 05:37:15 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 40 Approved: info-vax@sri-kl.arpa I have a C program which does not buffer it's output (called MAIL, our local mailer). It generates a buffered IO for every character sent to my screen. On DMZ lines, the output is very smooth, but on my DECserver-200, the output is jerky, as if the output from one program to one terminal at 9600 baud swamps the ethernet. Ah, now (on the third pass through) the relevent data comes out: When running like this, the C I/O system will, as you noted, do a single I/O per character. This will most likely result in a single character, or at most a very few characters, per packet across the Ethernet - and lousy performance. (You can see exactly the same effect with CTERM - SET HOST to a machine and run the same program; note the very slow, jerky output.) BTW, I doubt you are seeing anything like the Ethernet swamping; rather, you are seeing the rate limit built into the LAT protocols - it sends packets at regular intervals, putting in as much as it can. In "typical" situations, packets may contains tens of characters.... The fix is simple: Change the damn program! While it is giving you accep- table performance on your DMZ lines, it is chewing up an impressive amount of CPU time (compared to what it SHOULD be using) to do it - QIO's are EXPEN- SIVE! Besides, if you DON'T fix it now, you'll just end up doing it later when some- one tries to use the program via SET HOST. -- Jerry (BTW, before someone starts jumping up and down saying "See, Unix did it right, it's not a problem on Unix"...sorry, Unix gets this "right" by taking the "deaf, dumb, and blind" approach - it buffers up stuff written to the terminal until it feels like writing it out (or you use fflush()). I don't know how many students I've had come in, completely puzzled that their program wasn't even getting to the printf that says "I'm running", because the wrote to the terminal, then read from it without first doing an fflush. That doesn't happen on VMS - the C I/O system knows it is talking to an interactive device, and forces output out immediately - sort of like Unix unbuffered mode, except that a printf builds the whole output line, then immediately sends that out, rather than sending out one character at a time.) -------