[mod.computers.vax] JERKY output to DECserver-200

BRENT@uwovax.UWO.CDN (Brent Sterner) (01/09/87)

   Hope this get through.  The most logical explanation of my
previous complaint about jerky output follows:

-----

Brent,

You are suffering from a known hardware design error.
DEUNA interfaces in particular have problems on 8600s. It first shows up
in Lat terminal service, and then DECnet starts flaking out too.
We have seen it recover sometimes.

Contact your local DEC software support office to get a copy of
XEDRIVER.EXE version X-16S, which incorporates a software bypass for the
hardware problem. This is a special limited interim release of the
driver. The version distributed with VMS is X-16.

Selden E. Ball, Jr.

Cornell University                 NYNEX: 1-607-255-0688
Laboratory of Nuclear Studies     BITNET: SYSTEM@CRNLNS
Wilson Synchrotron Lab              ARPA: SYSTEM%CRNLNS.BITNET@WISCVM.WISC.EDU
Judd Falls & Dryden Road          PHYSnet/HEPnet/SPAN:
Ithaca, NY, USA  14853             LNS61::SYSTEM = 44283::SYSTEM (node 43.251)

-----

   A very nice try, but alas, the problem remains.  In summary,
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.
   D i g i t a l :  I will be sending an SPR.  Our site is looking
VERY closely at ethernet communications right now, and this doesn't
make it look very good!  Please address asap.
   On the brighter side, at least version 16-S of XEDRIVER did no
obvious harm.  Good for upwards compatibility. :)
   Any other suggestions are most welcome.
--
Brent Sterner
Lord Protector,  d i g i t a l  Systems
Computing & Communications Services
Natural Sciences Building
The University of Western Ontario
London, Ontario, Canada  N6A 5B7
Telephone (519)661-2151 x6036
Network     <BRENT@uwovax.UWO.CDN>  ! VAX 8600
            <A105@UWOCC1.BITNET>    ! IBM 4341

LEICHTER-JERRY@YALE.ARPA (01/12/87)

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