griffin@b11.ingr.com (Tommy Griffin) (07/06/90)
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 occurs when a Telnet session has been established from a PC to a workstation, and the workstation is generating a continuous stream of output to be displayed by the PC. The PC begins to display the output, but instead of displaying a continuous stream of data, new data is displayed at intermittent intervals with 1-20 second delays between bursts of output. The delay usually ramps up to 20 seconds and stays there. 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. We have some Sun workstations here, and a few PCs running Sun's PC/NFS, and when we Telnet from the PCs to the Suns we don't see any delay on continuous output from the Suns to the PCs. So, we got out our Ethernet Sniffer to figure out what the Suns are doing that we aren't. 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. 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. What we would like to know is how does the Sun workstation TCP implementation determine that it is talking to 3-Com PC/NFS? Does it look at the Ethernet address to determine that the board came from 3-Com? Is there something special in the TCP SYN packets that they key on? Any light that can be shed upon this matter would be greatly appreciated. Tom Griffin griffin@ingr.com -- ______________________________________________________________________________ Tommy Griffin
jbvb@VAX.FTP.COM (James B. Van Bokkelen) (07/09/90)
Two points: 1. The "retransmit increases steadily toward a limit, even when data is eventually getting acknowleged" is a TCP bug that at least a couple of "Van Jacobsen" TCPs can be provoked into demonstrating. With the two I'm familiar with (SunOS 4.0.1, Ultrix 3.0) it normally has to do with which ahead-of-sequence segment the receiver drops first if buffers are tight (earliest sequence vs. latest). In my opinion, it would be worth the effort to fix it in the workstation. 2. Read the TCP section of RFC 1122 - it has somewhat to say about the use of Nagle's algorithm to collect data into larger segments. The gateway vendors (and the regional networks) won't be awfully happy about bursts of back-to-back 64-byte packets. Even if the traffic is time sensitive, like X, a larger packet every 10ms would suffice. I can't really blame PC-NFS in this case - my TCP probably wouldn't do much better under that kind of abuse. A receiving TCP is rather limited in what it can do to prevent overrun, or sender retransmit escalation. To answer your original question, I hope the Sun Unix TCP isn't looking at the 3Com manufacturer code in the destination Ethernet address and slowing down (this would fail through routers, or if they were talking to software which sets its own Ethernet address). I think what you're seeing is mostly the effect of code which attempts to send as much data as possible in each segment... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
beame@maccs.dcss.mcmaster.ca (Carl Beame) (07/09/90)
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 occurs when a Telnet session has been established from a >PC to a workstation, and the workstation is generating a continuous >stream of output to be displayed by the PC. The PC begins to display >the output, but instead of displaying a continuous stream of data, new >data is displayed at intermittent intervals with 1-20 second delays >between bursts of output. The delay usually ramps up to 20 seconds >and stays there. > >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. > >Any light that can be shed upon this matter would be greatly >appreciated. > > >Tom Griffin >griffin@ingr.com At McMaster University they are running CS/100s to the IBM 7171 and IVECS cards in the Vaxen. They had the same problem (originaly the IVECS cards had a 16 second retry time). What I did was allow the Telnet window size to be changed. The CS/100s and IVECs cards buffer up to 82 bytes per packet. By setting the window size to 82, everything works and you can get reasonable through-put with telnet. Carl Beame Beame & Whiteside Software Ltd. Beame@McMaster.CA
sjg@sun0.melb.bull.oz.au (Simon J. Gerraty) (07/12/90)
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 <disclaimer> /* imagine something *very* witty here */