7.1-PRERELEASE : bad network performance (nfe0)

[Pyun YongHyeon]

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 at 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