Date: Thu, 05 Jun 2008 15:22:00 +0400 From: "Lev A. Serebryakov" <lev@serebryakov.spb.ru> To: Adrian Chadd <adrian@freebsd.org> Cc: net@freebsd.org Subject: Re: samba performance on 1Gig link: how to replace black magic with science? And why TCP windows scaling is not in play? Message-ID: <4847CC58.4060104@serebryakov.spb.ru> In-Reply-To: <d763ac660806042005q352abc88q911617ba4b67a7b0@mail.gmail.com> References: <1761236634.20080604234231@serebryakov.spb.ru> <d763ac660806042005q352abc88q911617ba4b67a7b0@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Adrian Chadd wrote: > Figure out why window scaling isn't working - look at the options > being negotiated (use tcpdump) and try to figure out which side isn't > offering or is rejecting window size scaling negotiation. FreeBSD suggest scaling 9, Windows -- scaling 0. After that FreeBSD uses scaling, but windows is 49152 (scaled! 0x0060 in header!) always from FreeBSD to Win due to SO_RCVBUF=49152. Without this option window is 130560, but speed is MUCH worse! > CIFS isn't the same profile as iperf/etc - its not just shovelling raw > data down the socket, there's a whole protocol involved in scheduling > what to transfer. Latency in handling commands screws your > performance.. But how this "magic values" in socket buffers can be explained? As far as I know, there are "big read/big write" commands in CIFS, which allows use more than 64K in one operation? -- // Lev Sserebryakov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4847CC58.4060104>