Well, this is embarassing. I can reproduce this completely running
4.4-stable (Nov 17th kernel) on two machines.
With newreno turned on, a TCP NFS mount only gets 80K/sec. With newreno
turned off on the transmit side, a TCP NFS mount gets 7MB/sec. The
state of the delayed-ack sysctl is irrelevant. This is without running
any nfsiod's (which would mask the degredation of the synchronous
messaging).
I am tracking it down now.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:> (I wrote)
:> Hmm. I'll play with it a bit tomorrow. Er, later today. One thing
:> I noticed recently with NFS/TCP is that I have to run 'nfsiod -n 4'
:> on the client to get reasonable TCP performance. I don't think I
:> had to do that before. It sure sounds similar... like a delayed-ack
:> problem or improper transmit side backoff.
:>
:> It would be nice if someone able to reproduce the problem can test
:> the TCP connection with newreno turned off (net.inet.tcp.newreno)
:> and delayed acks turned off (net.inet.tcp.delayed_ack). If that
:> fixes the proble it narrows down our search considerably.
:
:Hello, I am the submitter of PR 32141 mentioned above,
:
:I did check it with a 4.3 Release server and 4.2 Release client using
:'mount_nfs -3 -T ...':
:setting net.inet.tcp.newreno=0 gives fast performance (about 8 Mbyte/s, same
:for udp mount), setting net.inet.tcp.newreno=1 gives 80kbyte/s.
:Setting net.inet.tcp.delayed_ack=0 has no influence (I checked all 4
:combinations).
:There is 'nfsiod -n 4' running at clientside (default setting if enabling
:nfs via sysinstall). We did not play around with nfsiod settings so far.
:
:Hope that helps
:
: Alexander
:
:------------------------------------------------------------------
:Alexander Haderer Charite
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
