Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!tut.cis.ohio-state.edu!ucbvax!VAX.FTP.COM!jbvb From: jbvb@VAX.FTP.COM (James Van Bokkelen) Newsgroups: comp.protocols.tcp-ip.ibmpc Subject: Fast ethernet card for PC Message-ID: <8907241400.AA09311@vax.ftp.com> Date: 24 Jul 89 14:00:06 GMT References: <8907202244.AA05284@asylum.sf.ca.us> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 26 Reply-To: romkey@asylum.sf.ca.us Date: 20 Jul 89 22:44:31 PDT (Thu) From: John Romkey >Buffer size doesn't matter too much with TCP/IP, unless you've got >broadcast storm problems. I'm not sure of the exact context here, but buffer size does matter if you go to extremes. A TCP sending packets with 1 byte of data will get a total effective bandwidth that's a lot smaller than a TCP sending 1024 or larger packets. Not so extreme is in the middle, working with 100 or 200 byte datagrams; generally the slow down is still perceptible. Dave Feldmeier at MIT did some work a few years ago verifying experimentally that there is a plateau point where larger packets don't give you an appreciable speedup, but it tended to be > 1024 bytes. The context was "how much on-board RAM buffering is needed in a 3rd-generation LAN card". The drivers I'm familiar with generally use a 256-byte granularity for their buffers, so you can create pathological situations with 1-byte TCP packets. Most TCPs know better than to send mini-grams when they have bulk data to move, though... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901