Bug 177088 - Macintosh slow writing to FC1 - AFP, SMB, scp, or any TCP
Summary: Macintosh slow writing to FC1 - AFP, SMB, scp, or any TCP
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora Legacy
Classification: Retired
Component: kernel
Version: fc1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Fedora Legacy Bugs
QA Contact: Brian Brock
URL:
Whiteboard: DEFER
: 177087 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-01-06 03:49 UTC by Danny Yee
Modified: 2007-04-18 17:35 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-08-13 15:17:16 UTC
Embargoed:


Attachments (Terms of Use)

Description Danny Yee 2006-01-06 03:49:15 UTC
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:

Comment 1 Dave Jones 2006-01-06 03:52:10 UTC
*** Bug 177087 has been marked as a duplicate of this bug. ***

Comment 2 Danny Yee 2006-01-06 03:54:09 UTC
Sorry!

*** This bug has been marked as a duplicate of 177087 ***

Comment 3 Danny Yee 2006-01-06 03:55:52 UTC
aarrggh, crossed deduplication

Comment 4 Pekka Savola 2006-01-06 15:23:19 UTC
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.

Comment 5 Danny Yee 2006-01-12 01:12:05 UTC
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?



Comment 6 Danny Yee 2006-01-12 01:29:18 UTC
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.


Comment 7 Danny Yee 2006-01-19 06:17:03 UTC
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.


Comment 8 Pekka Savola 2006-01-20 11:28:05 UTC
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

Comment 9 Danny Yee 2006-01-23 01:08:37 UTC
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?

Comment 10 Jesse Keating 2006-08-13 15:17:16 UTC
Not really a security issue.


Note You need to log in before you can comment on or make changes to this bug.