Date: Thu, 01 Aug 1996 16:19:21 +0000 From: Matt Thomas <matt@lkg.dec.com> To: freebsd-current@freebsd.org Subject: TCP (+ Path MTU) bug / FDDI enchancements Message-ID: <199608011619.QAA04574@whydos.lkg.dec.com>
next in thread | raw e-mail | index | archive | help
This is a multipart MIME message. --===_0_Thu_Aug__1_16:08:29__1996 Content-Type: text/plain; charset=us-ascii [I'm sending this to -current rather than -bugs since I though it might be interesting to folks on -current.] I've updated my FDDI drivers to work under 2.2-current. In testing them I found my FDDI performance to be "only" ~50Mb/s. The code added to use sendpipe/recvpipe to fill the TCP sockbuf highwater marks overrides any size specified by the SO_RCVBUF and SO_SNDBUF socket options. This is not good since FDDI requires large windows so that the maximum amount of data can be transferred per token rotation. I've included a fix but I don't think it is the correct fix (nor could I figure out what the correct fix should be). However, the fix does restore the ttcp performance to a reasonable 85Mb/s. BTW, if I reduce the MTU of the FDDI interface to 1500, the performance drops to ~67Mb/s which is almost exactly what I get over 100baseTX. Which means the it is the per packet costs and not the per byte costs that take over at 1500 bytes / packet. I also updated if_ether.c so that it will initialize the mtu of FDDI interface routes to have a maximum MTU of 4352 (instead of the 4470 now used by FreeBSD). I also included a change which toggles the mtu of an ARP route between 1500 and 4352 depending on whether there is an FDDI/Ethernet bridge between the local system and the remote system. This requires changes to mbuf.h (included) and if_fddisubr.c and if_fddi.h (will be provided separately). Even though 2.2 includes some Path MTU support, there are a number of changes needed in ip_output() to support it. ip_output always bases its MTU decisions on the MTU of the interface. This is incorrect when Path MTU has been implemented. In that case you want to use the MTU of the path. This requires using a separate variable for storing the MTU and initializing it appropriately from the interface / route (whichever is less). Note that this has implications for ATM since a classic IP over ATM will use a 9180 (RFC 1577) but if SVCs are used can negotiate an MTU of up to 65535 bytes. Thus is would be best that for a RFC1577 implentation that supports SVCs to use 65535 as the if_mtu and make the ATMARP code initialize the MTU of an interface route to 9180. An alternative to define an IFF_VARMTU flag and test for that in ip_output(). Since the diffs are small, I've attached (gzip'ed) to this message. I'd appreciate if some one could get them into the -current and/or the -stable streams. --===_0_Thu_Aug__1_16:08:29__1996 Content-Type: application/octet-stream Content-Description: 2.2-960612-SNAP-diffs.gz Content-Transfer-Encoding: base64 H4sICCPWADIAAzIuMi1kaWZmcwCVWOtTIkkS/4x/RV5cxBzIs1EUYSHGHXHWW3UMdeZm70tH 2V0NtfZruwuVW92//TKrqh9A6zqE0lD5qHxV5q9ot9sQcinwvyud2BZhvJQdpxMlYl67XSzh eDkHsMCyRvt7I2sPrKOjg51ms1kltSnQHw16WuDjR2j3e4O91iE0zfPjxx2owS7IBYc0cu65 hLul5/GkBS53Es5SrmhBmnYUZ3cH/ik8l3twffvNvrk6u5rttGvCg3odBVPxPw4TSGR7mkg7 CZ46+G+nPHRjEfMGTCbQa+w0f4gfnp/RtPY0jew0dDvpnb0Qj0zCPyZAXhNzGjMHubu78P37 d20jrgoPLa4Vu1QoGSMH2ZIx/USONkygDg51oNRTBUrG7am0A/aU8jkqRF5UsBaQ63cFJOHO w48EZJ2/FJDEedgKCDH/UEDKSjYDMlUBgT932lii6SrtBkjpLLYqs3cw6h2N9vpFZRbMG3xY k9awKEirv986giY9rL4KM1pNghDfy4WbgOezedoC5qcRiBACWy1opzDsWP61C/vnT8c3t7Va 76ln9Xo11EBl0cVQcPHAXWAp+CK8b/v8gftwl0TMdVgqN5Rc5Er6f68kWPpSZEqahZLzs8tf e6QEDVFKSAZ8tuIJpDF3hCcc5VOFnEVy/R+X65Pc/jvkQEVXB9CJYoFePS54SJ9XIpxjcE3Q kbdd7PHpy9Vvp+fHn29q9Qv76tfbX06uny/s2Rd6V5F/NsFrlC17t9SziZp5WubZbxh7VTXI Vcw3sn5rn17PZui7ytUiWvou3HGIQvASzjEQOjntUncVsR0tZXV37R2O9vdHexXdtSS1JjAc 9azRwCqK+eiodQBNfDcNI5XJ0pHagd2AWkZPnbBQwsLHuOMZxFMW4YEznCJuZAxIb0HkeS3g SRIlyIuyTUUK5HJcaKe+zVw3wQEAu24qSyQR2sIjGuwKlikWaX4AxvoIDg7JbGswzOyu1eaR jOCOuSRUe6E34cVog2DtqWCoNSZjamgJLXrYGIVnG7tqgr7GtpQ+Ei29VGxKAqGdf62jydiH cIkMbZEyFYMX4D5Onz+1iYdDZeKw1xoaE7VRTG3PZCRYPcF+lmA/080TVxvjwvBNorZf9V3t xDpD1nqRVnTpGuBr22WgXdbFlylvNs3usGGYPn4fcF6c2p+Pb2f/Of6toWLuqtjUq9LaWFcx Z5I/stXYTCoLg0ITvWX1THDUQdGbiyCi0XD59fycGjlttJYfpOO3ILLzjkaEMQ6xXH6TThHN VFJY3sNnts7KqJJZpaSyqGj9RdtevdUDruNWbathttEuponTSVVhwUQTKIVICJQUkl9R1jCx He5T3fWPirrTR8ONQp6djayQyO5p2W4dnOozorTQgBHqwL4oGBESjggjiQ+9/RFORQuae71+ C2GfMkAFYNu7CZxdHp+cXNvHl7qcCh7c/ezYvjm7rAvWKI7aOEcFzTfMr7S+u6th4zeeCG+F CBHhxyOHBXvgwMIVOAsWOvhR4tj2sYlhW6bxwu58hJMR/LHkS641qBchTEQshD6x0ZlPXsLm AQ9lanCnAVWZJQTjhPeHTW20CcZZ+tItG4skqwHTSQax3iFdltLdY00C0R/yZeWctebZ5Zef v57ejDd6J+Vwz6Jx0NzrH73VXXGCYUn9SwUseixBlICnKZvj6CMJnkcFJ7eKiXZraeP4S2Sj 5Mh6JtHc5lu8hmfNpYubzzdn/51t+qQsVo7t95Vjg37mWFYWZx6kAWWeh9FyvgAPFeLk4YmH sLQFDgvh9yX6RuUPrkCEJf1VZz3PFWb+NNn26Q3ewqfS+gQWMgrTKplGeXbh4H2VF2lrvOky 0NNZReXwQEVleJCnW8SpZLKDDxtdl5RCMxzKUX1Bz7WF9XIBtxVSaMCHv+CQ+qBh2SbpzqB8 h6FxvDKXxaZryMizOZ7DpAoYDUaDg9HeoAIY5UKbt068DJRA/sAicN+kx74KCnW70PGXLt65 tKLOYrq9aLs+rTe31hUarBBJEKfxinUyOE0UYYOk/Qi3ZQzBfmDJa8TM+y0TM7LnuiLbVKNW oDaMN6p69ZjHy2fBeXJezen6mlMDIzWgLKw66yBrLyRJEIGaveurYBWXyqy4aHVcxS5wCj1t 86tlLWAo/CnGs4ucUgS8Ix/wLu6MKRLqOnx6cnJ2dnVx+1UNQWwN9MDmcIO9nRo+UlRjIL6i O6g+h+hpQxzlHhfCWSB4RWCcpjRyQqVGH5OO4ermcKTCWzUkT/HWQDt++KBF8FXfwHw+BloD tG82GmBu3W8IqBlpbuYVpGnhTENDglqVgoKLgpjf12t3CWf3a5PiOMS+qgYsnsRH7LIyWWEg IOE4WVOcDR2KBJXH/lDdSAYIEfsZgMEc60Sz8hWkzhHZswS72SLHzbmjOtONv0s+zk3UIO17 zuOiEMztjhzXVaAnhFmmjKZYEgxHgVzgF/zD1K5XRYtSHRrZElpwWEC/TyVqyjAl1J3RkQzp h6xEuHPeAbiJjKSbRHFee5GuH9UxqOisQa9HT/YQCTefs0yKKNuY6cLN9a47gbAtd4T04xKp NLIohABIoFVoOW0TRgmOSFA/JmAEBKVT/Qq3wgQGWuGjEc5MRRUdvdTNxjlzMGsOlnmnusjf V9wGH2gY2J4G+R3F+JfRyzWxXuGz219m16RP81UXeMZk8Ly+4L2iclKw57tXKt046Pq6UNmD Xre+OJ9vmb99PunXiXw16z4v9P5SZsmqRF/K1q+BE/iLLoLXs3/PPt2qc+fjQfSZzdJ7BHkK V5jDaAiLyHcpJP8HQAqNMTYWAAA= --===_0_Thu_Aug__1_16:08:29__1996 Content-Type: text/plain; charset=us-ascii Matt Thomas Internet: matt@3am-software.com 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt.html Westford, MA Disclaimer: I disavow all knowledge of this message --===_0_Thu_Aug__1_16:08:29__1996--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608011619.QAA04574>