Date: Mon, 29 Sep 2008 13:31:34 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: "Arno J. Klaassen" <arno@heho.snv.jussieu.fr> Cc: stable@freebsd.org, net@freebsd.org Subject: Re: 7.1-PRERELEASE : bad network performance (nfe0) Message-ID: <20080929043134.GD54819@cdnetworks.co.kr> In-Reply-To: <wptzc1gu9v.fsf@heho.snv.jussieu.fr> References: <wptzc1gu9v.fsf@heho.snv.jussieu.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 27, 2008 at 11:21:00PM +0200, Arno J. Klaassen wrote:
>
>
> Hello,
>
> I've serious network performance problems on a HP Turion X2
> based brand new notebook; I only used a 7-1Beta CD and
> 7-STABLE on this thing.
>
> Scp-ing ports.tgz from a rock-stable 7-STABLE server to it gives :
>
> # scp -p ports.tgz login@mv:/tmp/
> ports.tgz 100% 98MB 88.7KB/s 18:49
>
> (doing the same thing by copy from an nfs-mounted disk even
> takes mores than an hour ...)
>
>
> Doing a top(1) aside, just shows the box 100% idle :
>
> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND
> 12 root 171 ki31 0K 16K CPU0 0 38:55 100.00% idle: cpu0
> 11 root 171 ki31 0K 16K RUN 1 38:55 100.00% idle: cpu1
> 13 root -32 - 0K 16K WAIT 0 0:02 0.00% swi4: clock sio
> 29 root -68 - 0K 16K - 0 0:00 0.00% nfe0 taskq
> 34 root -64 - 0K 16K WAIT 1 0:00 0.00% irq23: atapci1
> 1853 root 8 0 7060K 1920K wait 0 0:00 0.00% sh
> 878 nono 44 0 8112K 2288K CPU1 1 0:00 0.00% top
> 884 root 8 - 0K 16K - 1 0:00 0.00% nfsiod 0
> 4 root -8 - 0K 16K - 1 0:00 0.00% g_down
> 16 root -16 - 0K 16K - 1 0:00 0.00% yarrow
> 46 root 20 - 0K 16K syncer 0 0:00 0.00% syncer
> 3 root -8 - 0K 16K - 0 0:00 0.00% g_up
> 30 root -68 - 0K 16K - 0 0:00 0.00% fw0_taskq
>
>
> I tested :
>
> Update Bios
> ULE /4BSD
> PREEMPTION on/off
> PREEMPTION + IPI_PREEMPTION
> hw.nfe.msi[x]_disable=1
^^^^^^^^^^^^^^^^^^^^^^^
This has no effect as MCP65 lacks MSI/MSI-X capability.
>
> All don't seem to matter to the problem.
>
> I put two tcpdumps (server and client during another scp(1) ) on
> http://bare.snv.jussieu.fr/temp/tcpdump-s1518.server
> http://bare.snv.jussieu.fr/temp/tcpdump-s1518.client
>
> I'm far from an expert on TCP/IP, but wireshark "expert info" shows
> lots of sequences like :
>
> TCP Previous segment lost
> TCP Duplicate ACK 1
> TCP Window update
> TCP Duplicate ACK 2
> TCP Duplicate ACK 3
> TCP Duplicate ACK 4
> TCP Duplicate ACK 5
> TCP Fast retransmission (suspected)
> TCP ...
> TCP Out-of-Order segment
> TCP ...
>
>
> As usual, feel free to contact me for further info/tests.
>
AFAIK it seems that you're the first one that reports poor
performance issue of MCP65. MCP65 has no checksum offload/TSO
capability so nfe(4) never try to take advantage of the hardware
capability. So you should have no checksum offload/TSO related
issue here.
Also note, checking network performance with scp(1) wouldn't
show real numbers as scp(1) may involve other system activities.
Use one of network benchmark programs in ports(e.g.
benchmarks/netperf) to measure network performance.
Other possible cause of issue could be link speed/duplex mismatch
or excessive MAC control frames(e.g. pause frames). Does nfe(4)
agree on resolved speed/duplex with link partner?
If they all agree on resolved speed/duplex, would you check number
of pause frames sent/received from link partner? Even though MCP65
supports hardware MAC statistics for pause frames nfe(4) has no
support code yet so you may have to resort to managed switch that
can show Tx/Rx statistics of each port.
--
Regards,
Pyun YongHyeon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080929043134.GD54819>