lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 29 Sep 2007 14:37:50 -0400 (EDT)
From:	Justin Piszcz <jpiszcz@...idpixels.com>
To:	linux-kernel@...r.kernel.org, linux-net@...r.kernel.org
cc:	samba@...ts.samba.org, submit@...s.debian.org
Subject: 2.6.22/realtek bug in hardware, any kernel work-around?

Package: samba
Version: 3.0.26a-1
>
> Kernel: 2.6.22
>
> samba 3.0.26a-1 performance < 900 KiB/s, but FTP = 30-90 MiB/s
>
> Let me start out by saing this is an oddball problem:
>
> SAMBA:
> LINUX -> WINDOWS = < 900 KiB/s (varies between 100 - 900 KiB/s)
> WINDOWS -> LINUX = 30-90 MiB/s (always)
>
> FTP:
> Either direction, 30-90 MiB/s (always)
>
> I do not see any nasty errors in the logs even with verbose = 5.
>
> Any ideas here? I am not using any special options.
>
> # cat /etc/samba/smb.conf
>
> [global]
>        log level = 5
>        workgroup = WORKGROUP
>        server string = %h - Pentium IV 3.4GHZ
>        security = user
>        encrypt passwords = true
>
> [user]
>  comment         = user
>  path            = /home/user
>  writable        = yes
>  valid users     = user
>  create mask     = 644
>
> --
>
> Here, FTP for pulling files from Linux.
>
> ftp> mget *
> 200 TYPE is now 8-bit binary
> 200 PORT command successful
> 150-Connecting to port 1255
> 150 715924.0 kbytes to download
> 226-File successfully transferred
> 226 13.687 seconds (measured here), 51.08 Mbytes per second
> ftp: 733106176 bytes received in 13.69Seconds 53562.23Kbytes/sec.
> 200 PORT command successful
> 150-Connecting to port 1256
> 150 716272.0 kbytes to download
> 226-File successfully transferred
> 226 13.032 seconds (measured here), 53.67 Mbytes per second
> ftp: 733462528 bytes received in 13.05Seconds 56216.95Kbytes/sec.
> 200 PORT command successful
> 150-Connecting to port 1257
> 150 713200.0 kbytes to download
> 226-File successfully transferred
> 226 12.869 seconds (measured here), 54.12 Mbytes per second
> ftp: 730316800 bytes received in 12.88Seconds 56723.63Kbytes/sec.
>
> Here, FTP for pushing files to Linux.
>
> ftp> mput 1 2 3
> 200 PORT command successful
> 150 Connecting to port 1263
> 226-File successfully transferred
> 226 12.802 seconds (measured here), 54.61 Mbytes per second
> ftp: 733106176 bytes sent in 12.80Seconds 57287.35Kbytes/sec.
> 200 PORT command successful
> 150 Connecting to port 1264
> 226-File successfully transferred
> 226 12.949 seconds (measured here), 54.02 Mbytes per second
> ftp: 733462528 bytes sent in 12.95Seconds 56624.92Kbytes/sec.
> 200 PORT command successful
> 150 Connecting to port 1265
> 226-File successfully transferred
> 226 15.400 seconds (measured here), 45.23 Mbytes per second
> ftp: 730316800 bytes sent in 15.38Seconds 47500.28Kbytes/sec.
>
> But (all I can offer is packet dumps/traces or bandwidth measurements):
>
> Incoming:                               Outgoing:
> Curr: 0.00 MByte/s                      Curr: 0.07 MByte/s
> Avg: 0.00 MByte/s                       Avg: 0.07 MByte/s
> Min: 0.00 MByte/s                       Min: 0.07 MByte/s
> Max: 0.00 MByte/s                       Max: 0.07 MByte/s
> Ttl: 1898.08 MByte                      Ttl: 2954.92 MByte
>
> LOCAL <-> REMOTE                                          TXBPS   RXBPS 
> TOTALBPS
> (IP)              PORT  PROTO  (IP)              PORT       TX      RX 
> TOTAL
> linuxbox <-> p4w.internal.lan          546k/s 4.74k/s 551k/s
> 192.168.0.1     445    TCP  192.168.0.2    1259    6.88m    106k  6.99m
>
> Why do I get such poor performance when trying to retrieve a file off the 
> Linux box?  This is a very strange problem.
>
> Linux:
>
> $ netstat -i
> Kernel Interface table
> Iface   MTU Met   RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR 
> Flg
> eth0   1500 0  14049682      0      0      0 11354070      0      0      0 
> BMRU
> lo    16436 0     45335      0      0      0    45335      0      0      0 
> LRU
>
> Windows:
>
> netstat -s
>
> IPv4 Statistics
>
>  Packets Received                   = 5053597
>  Received Header Errors             = 0
>  Received Address Errors            = 19
>  Datagrams Forwarded                = 0
>  Unknown Protocols Received         = 0
>  Received Packets Discarded         = 2
>  Received Packets Delivered         = 5053595
>  Output Requests                    = 3655144
>  Routing Discards                   = 0
>  Discarded Output Packets           = 0
>  Output Packet No Route             = 0
>  Reassembly Required                = 0
>  Reassembly Successful              = 0
>  Reassembly Failures                = 0
>  Datagrams Successfully Fragmented  = 0
>  Datagrams Failing Fragmentation    = 3
>  Fragments Created                  = 0
>
> ICMPv4 Statistics
>
>                            Received    Sent
>  Messages                  47          24
>  Errors                    0           0
>  Destination Unreachable   25          2
>  Time Exceeded             0           0
>  Parameter Problems        0           0
>  Source Quenches           0           0
>  Redirects                 0           0
>  Echos                     0           22
>  Echo Replies              22          0
>  Timestamps                0           0
>  Timestamp Replies         0           0
>  Address Masks             0           0
>  Address Mask Replies      0           0
>
> TCP Statistics for IPv4
>
>  Active Opens                        = 204
>  Passive Opens                       = 14
>  Failed Connection Attempts          = 16
>  Reset Connections                   = 59
>  Current Connections                 = 3
>  Segments Received                   = 5051709
>  Segments Sent                       = 3654327
>  Segments Retransmitted              = 76
>
> UDP Statistics for IPv4
>
>  Datagrams Received    = 1826
>  No Ports              = 58
>  Receive Errors        = 3
>  Datagrams Sent        = 716
>
>
> Justin.
>
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/listinfo/samba
>

Looks like it is hardware related after all:

http://forums.gentoo.org/viewtopic-p-2820556.html
http://ubuntuforums.org/showthread.php?t=531505
http://www.fedoraforum.org/forum/showthread.php?p=452451

One poster wrote "I got similar problems:"

http://forums.gentoo.org/viewtopic-t-570392.html
http://forums.gentoo.org/viewtopic-t-389449-postdays-0-postorder-asc-start-25.html?sid=4251f92bbc6db32fd200c4ea0ea9c9be

I found out that poor smb performance is related to a broken udp-perfomance of the 8169 NIC in outgoing udp.
But, only in Gb Mode of the 8169 NIC, with 100Mbps it is ok.

http://forums.gentoo.org/viewtopic-t-570392.html

I have:
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)

That must be the issue, time to buy an Intel PCI-e NIC if I want better 
performance with samba in Linux.

I do have another one of these motherboards (ABIT AW9D-MAX) running XP and 
it does not seem to suffer from this problem, I guess the [proprietary? 
Realtek driver does not suffer from this bug]?

Justin.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ