Re: Bad performance of 7.0 nfs client with Solaris nfs server

* Kris Kennaway <kris@xxxxxxxxxxx> [080220 13:42] wrote:
Chuck Swiger wrote:
On Feb 20, 2008, at 1:01 PM, Alfred Perlstein wrote:
Take a look at the level of packet fragmentation you are encountering;
yes, this is expected and things will work but there is extra latency
added when the IP stack has to reassemble packets before the data can
be delivered. Try setting the NFS rsize/wsize to 1024 or perhaps 1400
and see whether that improves performance.

Or, if your switch and NICs support it, see whether you can get Gb
Ethernet jumbo frames working so that you don't have to fragment for
2K or 4K data packets....

TCP mounts do not have this problem. You can safely use
32k or higher sizes with TCP without fragmentation.

Oh, sure. But there is a bit more overhead with TCP transport than
UDP-- for local (switched) networks, UDP generally seems to be a
win...TCP seems to be a better choice over a VPN or some similar kind of
WAN.

Actually this is no longer true. At modern LAN speeds (e.g. gige) you
can transmit packets fast enough that two things happen:

1) UDP socket buffer overruns are common, leading to packet loss.

2) the 16-bit sequence numbers wrap *much* faster than the IP fragment
lifetime (30 seconds).

These combine to cause data corruption when fragmented packets are
dropped and then reassembled with a later transmission of the same
sequence number.

TCP mounts should be used whenever possible thesedays (I flipped the
default mode in 8.0 the other day).

Additionally with smaller read/write sizes you must generate more
RPCs, for instance using a tcp read size of 32k will allow the
client to generate a single NFS_READ request for that 32k, however
a UDP mount at 1.2k will need to generate appoximately 26 requests
and the server will have to service that many requests as well.



--
- Alfred Perlstein
_______________________________________________
freebsd-performance@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: UPD better than TCP in streaming video/audio ?
    ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
    (microsoft.public.win32.programmer.networks)
  • Re: Simulating smaller MTU? ie sending small packets.
    ... This is due to the fact that TCP ... If you want smaller packets, ... >> set there as the MSS is announced by the receiver during the ... Yes, per connection. ...
    (comp.lang.perl.misc)
  • Re: NTP and Firewall help needed.
    ... >port 123 for udp and tcp. ... Also the idea of combining rules for packets arriving at the local machine ... ACCEPT any and all traffic coming from the localhost interface ...
    (comp.os.linux.setup)
  • Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues
    ... I'll be able to run some more basic tests tomorrow to see some results, but want to wrap my head around what's actually logically meant to be happening based on adjustments, etc. [I suspect this'll do nothing for the UDP issue, but at least I might be able to pipe some TCP traffic] ... Little packets with ip lengths of 28-29 bytes seem to do the most damage. ... UDP floods are much better handled - an ipfw block rule for the packet type and the machine responds as if there were no flood at all (until total bandwidth saturation or PPS limits of the hardware, which in this case was around 950Mbps). ...
    (freebsd-performance)
  • Re: UDP vs TCP
    ... TCP for instance will break up a large packet into smaller ... into the packets and then the receiving app would have to read ... Network Layer -> ethernet ... DOMAIN over port 53 ...
    (microsoft.public.vb.enterprise)