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
[-- Attachment #1 --]
[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.
[-- Attachment #2 --]
# 2 2.2-diffs XS"IE^\ ȳQa! q[u ufKG]
k [ݿ2 @:P|Uhr)+a %b^],x9F{#kfY%)
zZGh{!4 .4r.wRhAvgw)<{p};:kz S?Hd{H; :o<tcL&k4 Ѵ44t;靽L?&@^s3wm#
-T(#ْ1D6LuSJ9*D^Tw$Ïdy
1P@J62U?wX*H,*w0 Ee|Xְ(H:&=
3ZM˅y[-h0X O7Zgz5@ePp]`)"opDuX*7\J$XRdJ_{
QJH| 1w' SEr ;@EWЉb^=.xHW"cpMБ]oǟoj _N/zW6k-{ԳyZo{U5U7~k^f"Z.qB1:9Rw -euw G{ݵ$&0 *u M|7
#ґځ݀ZFOPǸS3"nd HoAy-I%ȋME
r\h\7 n*K$#
)i~ lk0摌$T{7h``5&cjh -zgjƶ>-TlJ؇p m2>N?CeQLmd$X=~`?WM_]:CzVtke]ŗ)o6a>~ p^ڟog9bԫXW1g?L* BeLpAћ p9m F1\~NTRXgʨYhE^Vma.IUaD(H_Q0 SGÍBin 3Ѐ(#NE {~ a2@`ۻ ] \Ǘ
ؾ9 (8G7̯a7o#{8 :Qa[|K5!LD,>љO^ejpU%Mm Y-$I!]cM e圵嗟ތ7z'pϢq ]qaIK,z,A)# G'vkiKdz&[gͥ7gm,Vc~XVg er ቇ %F@%Ug=f4
§2
*Fyv}ik2YE@Eex[ĩd]B3 Q}AϵrRha&Π|q2Ŧkȳ9ä
FޠBN @"pߤǾ
u.bh>7Iu28Mae ~`k-3"TV67zgyr^S#5,: k/$I`ʬhu\.p
=me-`()ƳR# .):|zrrvvuqU
Al
p>RTc ;>iC Y xE`4rBF p[5$O@;~EU|>Zo6`noiniLCCZkw gk8ľ,G2Ya 8YS
PH Dٳ":ӍK>M { U'YX G\ԮWER ZpX@O%j0%ԝё 釬DsDq^{ 1AGO 7L(ۘ;-w4( HUh9mF HP?&`S
ZLE 9s0kyW h؞ 5^_fפOUxdརrRW*8Pك^8o}>|5>/RfɪD_֯.׳>ݪsA{y
Whw)$@
16
[-- Attachment #3 --]
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608011619.QAA04574>