Hi,
Thanks for the reply(s)... If I understand you correctly, then:
%route -n get netapp01
route to: 192.168.21.52
destination: 192.168.21.52
interface: fxp1
flags: <UP,HOST,DONE,LLINFO,WASCLONED>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
0 0 0 0 0 0 1500 10
says that I have a specific interface route to get to the
fileserver... The recv/send values being 0 means that we are using
the default memory/window sizes. I'm not sure what the 3rd & 4th
columns are... (possibly what I'm looking for below)...
From SunOS, I can get the following values:
tcp_cwnd_max == 262144 <-- same as recv/send sizes, or windowsize ??
tcp_xmit_hiwat == 8192
tcp_recv_hiwat == 8192
udp_xmit_hiwat == 8192
udp_recv_hiwat == 8192
I'm now trying to determine how to get the hi & lo water marks
from FreeBSD...
net.inet.tcp.rfc1323: 0
net.inet.tcp.rfc1644: 0
net.inet.tcp.mssdflt: 512
net.inet.tcp.rttdflt: 3
net.inet.tcp.keepidle: 14400
net.inet.tcp.keepintvl: 150
net.inet.tcp.sendspace: 16384 <-- SunOS uses 260k...
net.inet.tcp.recvspace: 16384 <-- are these small?
net.inet.tcp.keepinit: 150
net.inet.tcp.log_in_vain: 0
net.inet.tcp.delayed_ack: 1
net.inet.tcp.path_mtu_discovery: 1
net.inet.tcp.pcbcount: 155
net.inet.tcp.always_keepalive: 1
net.inet.udp.checksum: 1
net.inet.udp.maxdgram: 9216
net.inet.udp.recvspace: 41600
net.inet.udp.log_in_vain: 0
If I may re-phrase.. How do I determine if the send/recv spaces
are large enough, and if not, how many times I bumped into the
wall?
Thanks!
John
> :> net.inet.tcp.recvspace: 16384
> :...
> :> send/recv space might be what I'm looking for...
> :
> :They're the default send/receive window sizes, yes. You can tweak them
> :with socket ioctls on a per-socket basis.
> :
> :> delayed ack sounds interesting....
> :
> :Turning that off disables TCP slow-start. It's a huge performance
> :booster for things like SMB service, where you have lots of short-lived
> :TCP connections on a local net.
>
> Note that you can also tweak TCP send/receive window sizes on a
> per-route basis. The recvpipe and sendpipe parameters in route
> table entries can be changed. This will override the sysctl defaults.
>
> However, it may be a little complex for some people to grasp. The
> route table is a radix tree. In order to set the send/receive pipes
> for particular ip addresses you may have to create a route to that
> IP address in order to effect it rather then a more global route.
>
> For example, if I am getting the route to some host that runs through
> my default gateway, I get my default route entry. If I were to
> change this route entry I would be changing it for default, not just
> for idiom.com:
>
> route -n get idiom.com
>
> # route -n get idiom.com
> route to: 209.157.64.1
> destination: default
> mask: default <----- this is not a host route!
> gateway: 209.157.86.1 <----- this is not a host route!
> interface: de0
> flags: <UP,GATEWAY,DONE,STATIC,PRCLONING>
> recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu
> expire
> 0 0 0 0 0 0 1500
> 0
>
>
> On the other hand, a route to another host on the same ethernet is usually
> specific:
>
> # route -n get lander
> route to: 209.157.86.6
> destination: 209.157.86.6
> interface: de0
> flags: <UP,HOST,DONE,LLINFO,WASCLONED>
> recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu
> expire
> 0 0 10411044 172 219 0 1500
> 1131
>
>
> To change the pipes associated with a route, I would do the following.
> But in this example if I were to try to change the pipe size to idiom.com,
> I would actually wind up changing the pipe size for my default route.
>
> route -n change idiom.com -sendpipe BYTES -recvpipe BYTES
> route -n change 209.157.86.6 -sendpipe BYTES -recvpipe BYTES
>
> If I really want to change the pipe size just to idiom.com, I would have
> to first create a specific route to idiom.com, then change that.
>
> route add idiom.com default
> route -n change idiom.com -sendpipe BYTES -recvpipe BYTES
>
> -Matt
> Matthew Dillon
> <dil...@backplane.com>
>
>
>
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
>
> ------------------------------
>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
