From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: TCP transfers from Macs running OS X (or at least 10.3.5 and 10.3.9) to a server running Fedora Core 1 with kernel 2.4.22-1.2199.4.legacy.nptlsmp are slow. That is, file writes (via AFP, SMB, or scp) run at around 50kB/s. Reads are the usual 3MB/s. There are no problems with Windows or Linux clients writing files to the server, and the same Macs write fine to machines running Fedora Core 3 or Fedora Core 4. Version-Release number of selected component (if applicable): 2.4.22-1.2199.4.legacy.nptlsmp How reproducible: Always Steps to Reproduce: 1. try any kind of file write to the Fedora Core 1 server 2. watch throughput Actual Results: Throughput of around 50kB/s. Expected Results: Throughput on the order of 1.5MB/s to 7MB/s. Additional info:
*** Bug 177087 has been marked as a duplicate of this bug. ***
Sorry! *** This bug has been marked as a duplicate of 177087 ***
aarrggh, crossed deduplication
I doubt Fedora Legacy is going to do anything about this, but I'll put it in the DEFER pile in case it'd be investigated during the next kernel update. You might need to run 'tcpdump -vvv -s0' on the TCP packets to figure out whether there's anything wrong with them on the wire (compared to FC3 for example), or whether it's just a kernel bug.
My Macs write fine to Fedora Core 3 machines, using scp, afp, or smb. And all three protocols fail writing to the Fedora Core 1 machine, so it definitely looks like a TCP/IP problem. It even affects afp over IP from MacOS 9... Is there anything obviously wrong with the following output? This is from tcpdump -vvv -s0 -- verily is the Mac client, corpus the FC1 server. 12:09:43.770160 verily.anatomy.usyd.edu.au.58602 > corpus.physiol.usyd.edu.au.ssh: . [tcp sum ok] 1661709111:1661710559(1448) ack 3896295592 win 65535 <nop,nop,timestamp 2235871481 171142927> (DF) [tos 0x8] (ttl 63, id 55090, len 1500) 12:09:43.770182 corpus.physiol.usyd.edu.au.ssh > verily.anatomy.usyd.edu.au.58602: . [tcp sum ok] 1:1(0) ack 4344 win 60816 <nop,nop,timestamp 171143077 2235871481> (DF) [tos 0x8] (ttl 64, id 61384, len 52) 12:09:43.770736 verily.anatomy.usyd.edu.au.58602 > corpus.physiol.usyd.edu.au.ssh: . [tcp sum ok] 4344:5792(1448) ack 1 win 65535 <nop,nop,timestamp 2235871482 171143077> (DF) [tos 0x8] (ttl 63, id 55091, len 1500) 12:09:43.770757 corpus.physiol.usyd.edu.au.ssh > verily.anatomy.usyd.edu.au.58602: . [tcp sum ok] 1:1(0) ack 5792 win 63712 <nop,nop,timestamp 171143077 2235871482> (DF) [tos 0x8] (ttl 64, id 61385, len 52) 12:09:43.771388 verily.anatomy.usyd.edu.au.58602 > corpus.physiol.usyd.edu.au.ssh: . [tcp sum ok] 7240:8688(1448) ack 1 win 65535 <nop,nop,timestamp 2235871482 171143077> (DF) [tos 0x8] (ttl 63, id 55093, len 1500) 12:09:43.771403 corpus.physiol.usyd.edu.au.ssh > verily.anatomy.usyd.edu.au.58602: . [tcp sum ok] 1:1(0) ack 5792 win 63712 <nop,nop,timestamp 171143077 2235871482> (DF) [tos 0x8] (ttl 64, id 61386, len 52) This is from an scp that's giving me 22KB/s throughtput... Here's a trace from an scp to an FC3 machine (nonsense), which gives me 4.4MB/s throughput. 12:13:51.178459 IP (tos 0x8, ttl 64, id 44133, offset 0, flags [DF], proto 6, length: 1500) verily.anatomy.usyd.edu.au.58619 > nonsense.ssh: . [tcp sum ok] 1448:2896(1448) ack 1 win 65535 <nop,nop,timestamp 2235871976 4134478797> 12:13:51.178476 IP (tos 0x8, ttl 64, id 43499, offset 0, flags [DF], proto 6, length: 52) nonsense.ssh > verily.anatomy.usyd.edu.au.58619: . [tcp sum ok] 1:1(0) ack 2896 win 32768 <nop,nop,timestamp 4134478797 2235871976> 12:13:51.178488 IP (tos 0x8, ttl 64, id 44134, offset 0, flags [DF], proto 6, length: 1500) verily.anatomy.usyd.edu.au.58619 > nonsense.ssh: . [tcp sum ok] 2896:4344(1448) ack 1 win 65535 <nop,nop,timestamp 2235871976 4134478797> 12:13:51.178502 IP (tos 0x8, ttl 64, id 44135, offset 0, flags [DF], proto 6, length: 1500) verily.anatomy.usyd.edu.au.58619 > nonsense.ssh: . [tcp sum ok] 4344:5792(1448) ack 1 win 65535 <nop,nop,timestamp 2235871976 4134478797> 12:13:51.178514 IP (tos 0x8, ttl 64, id 43501, offset 0, flags [DF], proto 6, length: 52) nonsense.ssh > verily.anatomy.usyd.edu.au.58619: . [tcp sum ok] 1:1(0) ack 5792 win 32768 <nop,nop,timestamp 4134478798 2235871976> 12:13:51.177372 IP (tos 0x8, ttl 64, id 44136, offset 0, flags [DF], proto 6, length: 1500) verily.anatomy.usyd.edu.au.58619 > nonsense.ssh: . [tcp sum ok] 5792:7240(1448) ack 1 win 65535 <nop,nop,timestamp 2235871976 4134478797> Are there any TCP/IP parameters I could try tweaking on the FC1 machine?
One more bit of information - it seems to be a TCP problem rather than an IP one, since I can do a flood ping from the Mac to the FC1 machine and get nearly a thousand 1500 byte pings a second through. I'm hunting through my old TCP/IP texts, but it's been ten years since I studied any of this stuff, so any pointers would be appreciated.
I found a workaround that confirms my belief it's a TCP problem. I enabled a DDP only netatalk share on the FC1 server, and the Mac writes fine to that, using Appleshare over Appletalk DDP instead of over IP. That's not a solution for OSX 10.4 machines (10.4 doesn't support DDP), but hopefully by the time that becomes critical I'll have managed the move to FC4.
I took a quick look at those traces, conclusions: - there don't appear to be TCP options level issues that I could see though you could try disabling TCP timestamps if that'd be causing issues (echo 1 > /proc/sys/net/ipv4/tcp_timestamps). You might also want to test other TCP features - in the non-working case, it takes around 0.5 milliseconds more to send each TCP segment (look at the spacing of timestamps as the left) - corpus sends "ack 5792" two times, implying that the packet sent at 12:09:43.771388 by verily might have been corrupted or gotten lost. Any further debugs you might do can probably be done without '-vvv' option, as there's less (useless) information that way. You may also want to verify that Apple sets TCP_NODELAY socket option in the applications you're testing, see: http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci754347,00.html
Changing the timestamps setting didn't help, but thanks for looking at this. I've also confirmed that Appleshare over IP is slow even when Macs are booted into OS 9 - which is really strange, since the OS X and Mac System 9 TCP/IP implementations should be completely different. I'm just bemused now. I don't think it can be an ethernet problem, as there's a switch in the way and the Macs and my FC1 server interoperate fine with other servers or Windows/Linux clients. It can't be some Appleshare weirdness, as it affects scp and smb as well. Did the dog bark in the night?
Not really a security issue.