Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!samsung!usc!hacgate!ladcgw.ladc.bull.com!melb.bull.oz.au!sun0!sjg From: sjg@sun0.melb.bull.oz.au (Simon J. Gerraty) Newsgroups: comp.protocols.tcp-ip Subject: Re: telnet and pc's Message-ID: <1990Jul11.235001.2613@melb.bull.oz.au> Date: 11 Jul 90 23:50:01 GMT References: <8285@b11.ingr.com> Sender: news@melb.bull.oz.au Organization: Bull HN Information Systems Australia Lines: 94 In-Reply-To: griffin@b11.ingr.com's message of 5 Jul 90 20:16:04 GMT In article <8285@b11.ingr.com> griffin@b11.ingr.com (Tommy Griffin) writes: > We're experiencing some difficulty communicating between our > workstations and PCs using Telnet over TCP/IP. The PCs are running > Sun's PC/NFS product through the 3-Com Ethernet card. > [...] > The problem seems to be caused by the PC's inability to receive and/or > process Ethernet/TCP frames which arrive within 5 milliseconds of each > other. Our workstation sends output to the PC in TCP frames carrying > 64 bytes of data. The 512 byte TCP window offered by the PC's TCP > allows us to send up to 8 frames inside one window, so these frames > can arrive with very little inter-frame spacing. When the PC drops a > frame, we have to retransmit the data that was lost. The Jacobson > algorithm in our implementation of TCP causes us to *DOUBLE* our > retransmission timer each time we have to retransmit data. We > eventually increase the retransmission timer to its maximum value, 20 > seconds, which explains why we're seeing bursts of data every 20 > seconds. I found very similar problems when trying to get various PC telnets to communicate with a Pyramid 9810 (I think the model is correct). I was actually there to get a telnet that I had written working with the Pyramid. Other telnets in use at the site were NCSA, and PC/NFS. We had similar performance to what you describe only worse. The Pyramid would echo key-strokes to the PC's within 5ms and in most cases the PC's would miss the echo. This resulted in very sporadic response appearing on the user's screen. The PC's involved were mostly 25MHz 386's using 16bit WD Ethernet cards. Interestingly, using an 8bit 3Com card on an 8MHz 286, got better performance! My conclusion was that the faster PC/adapters were able to get them selves ready to send another frame, just as the echo arrived (and thus miss it), whereas the slower PC/adapter was more often in a state where it could accept the echo. In all cases however we usually got to a point where lots of retries were occuring and apparent performance was poor. Cutting the window size and segment size to a minimum helped but did not solve the problem. > [...] > It seems that the Sun workstations somehow determine that they're > communicating with Sun PC/NFS on a 3-Com card, because they only allow > one TCP frame to be transmitted to the PC at a time. They send a > frame, and wait for an acknowledgement (or a retransmission timeout), > then send another frame, and so on. This occurs even if the frame > contains less data than the offered window size. The PC/NFS telnet does terminal type negotiation and declares itself as type "SUN". This may or may not be the flag the sun notices, since in other respects the telnet connection seems straight forward. Mind you my telnet negotiates a type of VT220, and had no problems with talking to Sun's (using WD or 3Com cards) so I may be wrong. > When we Telnet between Suns, or from Suns to our workstations, the > Suns transmit many small TCP frames containing data in the offered TCP > window before waiting for an acknowledgement. > > We would like to communicate effectively between our workstations and > PCs with the Sun PC/NFS Telnet through the 3-Com Ethernet controller. As I indicated above, it isn't just PC/NFS you need to worry about, nor is it just 3Com cards. The suggestion I made to the Pyramid Tech rep. was (may be a bad idea but here goes :-) Modify the IP implementation so that a frame is not transmitted to an address from which a frame was most recently received or to which a frame was most recently sent. The assumption here is of course that on a host there will always be IP datagrams waiting to be sent to multiple destinations. By ensuring that no destination is sent two frames in a row, or that a frame is not sent to a destination that we just received from, we effectively increase the delay between frames to each destination without affecting the overall throughput of the host. This approach may be too simplistic, and something better might be needed, but the simple fact is that even fast 386 PC's with fast ethernet adapters cannot keep pace with many UNIX hosts. Any UNIX vendor that wants their host to appear to perform well when using PC's as telnet terminals, needs to pace its output to each PC. Sorry if this is all old hat... -- Simon J. Gerraty sjg@sun0.melb.bull.oz.au - NET ..!{hplabs,mcvax,nttlab,ukc,uunet}!munnari!sun0.melb.bull.oz.au!sjg - UUCP #include /* imagine something *very* witty here */