Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!TOPAZ.RUTGERS.EDU!root From: root@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Terminal Concentrators Message-ID: <8705060815.AA01928@topaz.rutgers.edu> Date: Wed, 6-May-87 04:15:08 EDT Article-I.D.: topaz.8705060815.AA01928 Posted: Wed May 6 04:15:08 1987 Date-Received: Sat, 9-May-87 02:02:44 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 50 I just took a look at some statistics from three of our Cisco terminal servers. Since it's 3am, packet rates wouldn't show much, but I have some other data which is probably in the long run more useful. This shows the total number of packets in and out for each session, the total number of bytes, and the number of packets with data. By looking at the fraction of packets with data, you can get a feeling for how much you are paying for TCP ack and window updates. Note however that even with LAT, there surely has to be some sort of acknowledgements, so it can't be 100% efficient either. The original data contains a lot more info about the innards of the TCP protocol handling, but I have omitted it as it didn't seem relevant to this discussion. It looks like well over half (typically over 2/3) of the packets received have data (i.e. are not just acks), and the amount of data per packet is fairly high. It looks like around half, or maybe slightly less of the packets sent have data, and as you would expect it is about one char per packet. (A couple of the connections have been idle for long periods, so you see packets that aren't doing much.) It looks to me like this is about as efficient as one can hope for. It looks like acks for stuff we send typically gets piggybacked on the echo, but the stuff that comes back requires separate acks. This is what you'd expect with a simple model of what is going on, and is presumably going to be the same for any protocol that is designed to use unreliable networks. The number of characters per packet also seems good. Obviously I can't compare this with LAT without seeing data on LAT, but there doesn't seem to be a lot of room for improvement. dialup to Sun (4.2 IP, 4.3 beta TCP), though one gateway Rcvd: 4694 (out of order: 0), with data: 4374, total data bytes: 160181 Sent: 6456 (retransmit: 1), with data: 3988, total data bytes: 4220 dialup to Pyramid (4.3 TCP/IP, with telnetd in the kernel) Rcvd: 1981 (out of order: 0), with data: 1634, total data bytes: 119314 Sent: 1626 (retransmit: 0), with data: 824, total data bytes: 900 hardwired to Sun, through one gateway Rcvd: 2472 (out of order: 0), with data: 1265, total data bytes: 114771 Sent: 2489 (retransmit: 0), with data: 175, total data bytes: 191 hardwired to Pyramid Rcvd: 12195 (out of order: 0), with data: 7116, total data bytes: 88935 Sent: 9044 (retransmit: 0), with data: 6957, total data bytes: 7206 hardwired to Sun, through one gateway Rcvd: 671 (out of order: 0), with data: 406, total data bytes: 10684 Sent: 834 (retransmit: 0), with data: 340, total data bytes: 349 hardwired to DEC-20 Rcvd: 14579 (out of order: 0), with data: 410, total data bytes: 54371 Sent: 492 (retransmit: 0), with data: 207, total data bytes: 249