GEustace@massey.ac.nz (Glen Eustace) (09/06/90)
The following has been raised before but I am raising it again in the hope that some one who knows (understands) TCP (IP) better than I do can throw some light on the situation. I think it is a problem with the TCP part of the Sun PC-NFS (toolkit?) product but I don't know enough about TCP to confirm or deny or even to say whether this behaviour is (ab)normal. As our network load continues to rise we are finding that the performance of the Telnet program that comes with PC-NFS is causing people a great deal of frustration. The problem is that there a alot of pauses in the receipt of characters going to and from the hosts. One can be typing a command and get significantly ahead of the echo on the screen. When running full screen editors like gnumacs, it gets very confussing very quickly as the position of the cursor in reality often differs from the position on the screen by large amounts. We have the CUTE version of NCSAs telnet, i.e. the one modified to run using the PC-NFS socket routines. This version of telnet displays the same behaviour. There are some who will not use PC-NFSs telnet but continue with the original NCSA one. This necesitates rebooting after use as the NFS loses the ethernet card. Anyway the NCSA version of telnet does not suffer from this problem. I have collected the following data from both situations, i.e. my workstation using the modified telnet and a workstation running the standard NCSA telnet. I am hoping it will point to some reason why there is the delay and perhaps some work around can be found that will improve performance. Collected with etherfind on a 386i:- etherfind -x -v -between cc-server1 cc-raman \( -ip -o -arp -o -broadcast \) Using interface ie0 TCP from cc-raman.2998 to cc-server1.telnet seq 83B6FD5, ack BD12E3, window 512, 1 bytes data 08 00 8b 00 04 7e 00 00 c0 b5 ff 10 08 00 45 00 00 29 21 7e 00 00 64 06 2d 54 82 7b 02 04 82 7b 01 03 0b b6 00 17 08 3b 6f d5 00 bd 12 e3 50 18 02 00 a2 50 00 00 6c 00 20 64 69 72 TCP from cc-server1.telnet to cc-raman.2998 seq BD12E3, ack 83B6FD6, window 8192, 1 bytes data 00 00 c0 b5 ff 10 08 00 8b 00 04 7e 08 00 45 00 00 29 fa 7f 00 00 1e 06 9a 52 82 7b 01 03 82 7b 02 04 00 17 0b b6 00 bd 12 e3 08 3b 6f d6 50 18 20 00 84 4f 00 00 6c 00 00 00 00 00 TCP from cc-raman.2998 to cc-server1.telnet seq 83B6FD6, ack BD12E4, window 512, 08 00 8b 00 04 7e 00 00 c0 b5 ff 10 08 00 45 00 00 28 21 7f 00 00 64 06 2d 54 82 7b 02 04 82 7b 01 03 0b b6 00 17 08 3b 6f d6 00 bd 12 e4 50 18 02 00 0e 50 00 00 6c 00 20 64 69 72 (cc-swdev1)CCAdmin: ^raman^eustace^ etherfind -x -v -between cc-server1 cc-eustace \( -ip -o -arp -o -broadcast \) Using interface ie0 TCP from cc-eustace.25157 to cc-server1.telnet seq F62BF, ack C6F672, window 8192, 1 bytes data 08 00 8b 00 04 7e 00 00 c0 c7 3a 10 08 00 45 00 00 29 fc 12 00 00 0f 06 a7 c1 82 7b 02 02 82 7b 01 03 62 45 00 17 00 0f 62 bf 00 c6 f6 72 50 18 20 00 f4 52 6b 19 6c fc 1f 00 00 00 TCP from cc-server1.telnet to cc-eustace.25157 seq C6F672, ack F62C0, window 8192, 1 bytes data 00 00 c0 c7 3a 10 08 00 8b 00 04 7e 08 00 45 00 00 29 1f db 00 00 1e 06 74 f9 82 7b 01 03 82 7b 02 02 00 17 62 45 00 c6 f6 72 00 0f 62 c0 50 18 20 00 5f 6b 00 00 6c 00 00 00 00 00 TCP from cc-eustace.25157 to cc-server1.telnet seq F62C0, ack C6F673, window 8191, 08 00 8b 00 04 7e 00 00 c0 c7 3a 10 08 00 45 00 00 28 fd 12 00 00 0f 06 a6 c2 82 7b 02 02 82 7b 01 03 62 45 00 17 00 0f 62 c0 00 c6 f6 73 50 18 1f ff b2 01 19 6b 6c fc 01 00 56 54 TCP from cc-eustace.25157 to cc-server1.telnet seq F62C0, ack C6F673, window 8192, 08 00 8b 00 04 7e 00 00 c0 c7 3a 10 08 00 45 00 00 28 fe 12 00 00 0f 06 a5 c2 82 7b 02 02 82 7b 01 03 62 45 00 17 00 0f 62 c0 00 c6 f6 73 50 18 20 00 60 52 6b 19 6c fc 1f 00 00 00 In both cases a single 'l' was typed on the workstation, however the behavior of TCP in each case is somewhat different. Can anyone explain the above difference. DOes it have anything to do with the delays being experienced? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Glen Eustace, Software Manager, Computer Centre, Massey University, Palmerston North, New Zealand. EMail: G.Eustace@massey.ac.nz Phone: +64 63 69099 x7440, Fax: +64 63 505 607, Timezone: GMT-12
pilger@uhunix1.uhcc.Hawaii.Edu (Eric Pilger) (09/07/90)
I don't know if this has a bearing on the overhead you are experiencing with PC-NFS Telnet. I have been using the Programmer's Toolkit and found that there is a LOT of overhead on socket writes. By sending a large amount of data in varying size pieces and measuring the throughput for each instance, I came to the conclusion that there is as much as a 1/5 of a second overhead for each write. This value is probably not extremely accurate, but it is in the right ballpark. Sending data 64K at a time, my throughput was 100-300K per second. Sending data 512 bytes at a time, throughput was down to 5-10K per second. First, you can well imagine what this does to telnet. Everytime you press a key, a write has to occur, and you incur a 1/5 of a second overhead. Second, why does this happen? Is it the fault of the socket drivers? Is it the fault of the ethernet card? Inquiring minds would like to know (and fix.) Eric Pilger NASA Infrared Telescope Facility
milne@ics.uci.edu (Alastair Milne) (09/07/90)
In <956@massey.ac.nz> GEustace@massey.ac.nz (Glen Eustace) writes: >As our network load continues to rise we are finding that the >performance of the Telnet program that comes with PC-NFS is causing >people a great deal of frustration. The problem is that there a alot >of pauses in the receipt of characters going to and from the hosts. >One can be typing a command and get significantly ahead of the echo >on the screen. When running full screen editors like gnumacs, it >gets very confussing very quickly as the position of the cursor in >reality often differs from the position on the screen by large >amounts. I'm one of the people who was complained before now, both to our own support group and the net, about this behaviour (or should I say misbehaviour). I want to add my voice to Glen's inquiry. Please, if anybody has made any progress in finding out the cause of these insistent pauses, share whatever you have got. It's one of the few parts of PC-NFS that really seriously frustrate me. Here's a little clue, probably worth very little. This is a description of our PC-NFS setup on a microchannel machine: - PC-NFS 3.0.1 (PCNFS.SYS /f20 /b1 /d5) - SOCKDRV.SYS - WD8003E/A (i.e. microchannel version of the WD8003E) - the N.D.I.S. driver NFS-NDIS.SYS from Clarkson - the protocol manager section from MS's L.A.N. Manager (PROTMAN.SYS, PROTMAN.INI, NETBIND.EXE) - Western Digital's LANMAN driver for the WD8003E/A (MACWD.SYS) PC-NFS telnet pauses as frequently here as when using just WD8003E.SYS on AT-bus machines. Not much, but it's about all I have. That and the fact that using 386Max to load PCNFS.SYS high on the AT-bus machines makes no difference either, though I hardly expected that it would. (Loading it high on the microchannel machine seems to keeping NETBIND from binding correctly.) Please, any clues anywhere? Alastair Milne, U. Calif. Irvine