Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Mar 2001 22:20:01 +0100 (MET)
From:      Helge Oldach <Helge.Oldach@de.origin-it.com>
To:        conrad@th.physik.uni-bonn.de (Jan Conrad)
Cc:        bright@wintelcom.net, dillon@earth.backplane.com, gordont@bluemtn.net, rdm@cfcl.com, freebsd-stable@FreeBSD.ORG
Subject:   Re: NFS performance
Message-ID:  <200103212120.WAA03934@galaxy.de.cp.philips.com>
In-Reply-To: <Pine.BSF.4.33.0103212133210.559-100000@merlin.th.physik.uni-bonn.de> from Jan Conrad at "Mar 21, 2001  9:45:26 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
Jan Conrad:
>> >client:
>> >Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs Coll
>> >fxp0  1500  <Link#1>    00:02:b3:1f:f8:c5  1901001     0   771611     0 208240
>> >server:
>> >Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs Coll
>> >fxp0  1500  <Link#1>    00:90:27:1c:f3:79  7157753     0  4648694     0 2661459
>>
>> Gimme a break. Out of 4648694 output packets you see as many as 2661459
>> collisions? That's more than 50%, i.e. for about every second packet
>> that you are sending you get a collision! You very clearly have a
>> collision problem.
>>
>> I bet that the switch is at full-duplex while you're at half. Try
>> changing the mediaopt setting of your NIC.

>- if I leave it at half-duplex the net makes 9Mb/s
>  ping -f <Machine on the same switch) I get 0% to 1% packet loss

Excellent.

>- if I switch the fxp0 interface to full duplex
>  and boot the machine and disconnect the net for some seconds
>  the net slows down to 200kb/s

Ooops!

>I would conclude that the switch is on 100baseTX, half-duplex, indeed.

Yep, most certainly it is. And it's even too stupid to see that you are
different. But OK.

>again, running on half-duplex, transfering 100Mb from a client to this
>machine (merlin)
>on client:
>mount -t nfs -o intr,nfsv3,-r=32768,-w=32768 merlin:/freebsd/misc /mnt
>dd if=/dev/zero of=/mnt/zero bs=16k count=64x100
>104857600 bytes transferred in 12.765062 secs (8214422 bytes/sec)

Decent.

>            input         (fxp0)           output
>   packets  errs      bytes    packets  errs      bytes colls
>        11     0        668         11     0        412     0
>         6     0       1670          5     0       1556     0
>         8     0        180          7     0          0     0
>        11     0    5155696          8     0      62530     0
>       254     0    7015588         23     0      98848    32
>      6115     0    7926312        540     0     118592  1189
>      5304     0    9183810        548     0     136772  1030
>      5768     0    8091074        586     0     120418  1139
>      6527     0    9191418        674     0     138720  1337
>      5915     0    8728739        612     0     129630  1176
>      6492     0    9032044        678     0     133856  1243
>      6195     0    8112222        634     0     122300  1237
>      6509     0    9251329        674     0     137258  1287
>      5886     0    8317303        605     0     125380  1138
>      6490     0    8904250        665     0     132046  1334
>      5978     0    8857169        617     0     139924  1149
>      6444     0     853656        676     0      23624  1259
>      4720     0        313        564     0          0   903
>         1     0       1349          1     0       1390     0
>         2     0        171          0     0         90     0

Well, the volume is on the input side here. The figures say that for
any output packet your NIC needs on average about two attempts to get
it to the wire. This is almost OK as this is the response channel, and
in relation to the overall load of the link (input plus output) the
collision rate is not outrageous. Say, some 13%, but for a saturated
half-duplex port this is what one would expect. Bear in mind that the
numbers you gave us before (top of mail) give a different picture: input
and output were not *that* much different, yielding in a much higher
overall collision rate.

Anyhow. This clearly shows that the slowliness has nothing to do with
the network which is just perfect.

But you certainly would want to talk to the switch admin to change the
port to full-duplex. This is a definitive barrier here and changing that
will give you noticeable extra performance. Frankly, forcing a switch
that can do full-duplex to half-duplex is plain nonsense as it doesn't
really exploit the hardware capabilities. If you've got surplus money,
better spend it elsewhere than buying unused capabilities.

>Has anybody ever seen something like that ?

In networking, you'll see all sorts of strange counters, dubious claims,
obscure side-effects, and marvellous breakages. Basically you learn to
trust your own eyes and fingers only. :-)

Helge

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103212120.WAA03934>