Eatmeingreek
Gentard
join:2001-06-29
San Francisco, CA
| reply to Crypto
Re: OS X client, linux server, samba pain.
Delayed ACK and TCP_NODELAY (disable Nagle's algorithm) are no the same thing. They do interact badly, however:
»www.port80software.com/200ok/arc···317.aspx
That shouldn't have been the problem in this case, 'cause you had TCP_NODELAY set in your smb.conf
You might be on the right track with the Linux driver:
»www.scyld.com/rtl8139.html#8139too
--
"PowerPoint is a distraction. People use it when they don't know what to say." |
|
jfgrissom
join:2002-07-10
San Diego, CA
| reply to Crypto
This sudo sysctl -w net.inet.tcp.delayed_ack=0
is Awesome!
My DL times from Suse9.2
(I know OpenSuse10 is out, and it is FREE! I'm upgrading I swear!)
SMB server to my Mac went from (this is no exageration)
90-150KB/sec to 900KB-1MB/sec.
It does look like it bursts though... (Hi speeds for 10 seconds -- sleep for 2 seconds -- hi speed again but that could be my slow Wifi-G connection)
It Also provides much much faster responce time if you wan to cancel transfers.
This is good stuff... has anyone seen it break anything? |
|
deaDleSs balLoon
@spndigital.com
| reply to Crypto
btw, i have an another problem, maybe you can help me...
mac users, when browsing samba share, cannot see full information about file ownership and permissions,
they only see: you can read an write 
But they want to know who created file.
Any suggestions, what can i do for them to see that info? |
|
deaDleSs balLoon
@spndigital.com
| reply to Crypto
dont know if it's interesting for you guys, but i found that you can create file /etc/sysctl.conf (on mac of course) and put the following line in it:
net.inet.tcp.delayed_ack=0
It works fine! 
PS Thanks for your wonderful advise, now my freebsd file server can serve macs too |
|
MiloMindbend
join:2001-01-18
Jeannette, PA
| reply to z3r
said by z3r :
I guess sysctl twiddling must remain the solution. Irritating, but not serious.
Well, there is another option, if it's a big enough PITA for you (it wasn't a big enough itch for me to scratch, personally -- I only have limited interaction with SMB shares):
Download the smbfs.kext source, tweak the socket options, rebuild it, and replace the original .kext with it (I'd rename the old one, not delete it  . That's one of the neat things about Darwin -- the core OS _is_ open... |
|
z3r
@mpg.de
| reply to MiloMindbend
Thanks. I guess you must be write about the file being ignored. Certainly, appending
socket options = TCP_NODELAY
to /private/var/root/.nsmbrc (and also, for good measure, copying the resulting file to my $HOME and temporarily doing chmod go+r on both copies) doesn't change the behaviour. Estimate of time taken to transfer 152MB: 1 hour.
I guess sysctl twiddling must remain the solution. Irritating, but not serious. |
|
MiloMindbend
join:2001-01-18
Jeannette, PA | reply to z3r
Same sort of thing as in smb.conf, iirc: "options TCP_NODELAY"
I'd start by pulling the smbfs kext source from OpenDarwin, though, and see if it actually even reads the nsmbrc files -- it could very well not. |
|
z3r
@mpg.de
| reply to MiloMindbend
Hi.
Thanks for posting---I'm very glad to find a workaround for this problem, which was killing transfer speeds between a FreeBSD samba server with an Intel NIC and my OS 10.4 Powerbook client.
I'd like to try the nsmbrc solution you mention (and it seems plausible to put it in the root .nsmbrc) but documentation about .nsmbrc and its syntax is hard to find. All I find on my system and by Google is an "example file" with a few commented-out lines that seem irrelevant to this problem.
How would you, in principle, disable delayed acks in a nsmbrc config file?
cheers, --jez |
|
manifest
bitches
join:2004-08-14
Hartford, CT
| reply to Crypto
Re: Problem solved. Culprit: Bad Linux NIC/Driver
You know I should have realized this. Right around when I upgraded from 10.3 to 10.4 I also had to a motherboard replacement on my linux server. The NIC was also changed. I was using a realtek chipset and went to a 3com 3c905. Changing the nic must have done it for me as well. |
|
MiloMindbend
join:2001-01-18
Jeannette, PA
| reply to Crypto
Re: OS X client, linux server, samba pain.
said by Crypto  :It's certainly much, much faster with delayed acks set to 0 on the OS X box. What are the ramifications to just leaving the OS X box like that? Sorry, forgot to answer that one. If you leave it like that, nothing will break, but your other network traffic will be less than optimal, as TCP will send an ack for every packet instead of combining them and acking several packets at a time. So just evaluate your typical network usage (with the most emphasis on local, high-speed stuff) -- if it's mostly SMB to a server that doesn't deal well with delayed acks, I'd normally leave it disabled. If that's a small percentage of your overall usage, I'd leave it at it's default. Heck, you could always wrap it with an Automator script and assign a hotkey to it to switch on demand. |
|
MiloMindbend
join:2001-01-18
Jeannette, PA
| reply to Crypto
said by Crypto :You say that this should do the same thing as putting TCP_NODELAY on the Linux samba server? Thats odd, because I did that already and didnt seem to have any results. It effectively does the same thing _on the Mac_ that the smb.conf TCP_NODELAY does _on the Linux box_. But it was the Linux box that was pausing because the Mac wasn't sending an ack to every packet, so you have to disable the delayed acks on the Mac.
You're supposed to be able to set socketopts in ~/.nsmbrc (disabling delayed acks just for the smbfs kernel extension, rather than for the whole system), but I never got that to work (hmm, wonder if it has to be in /etc/nsmbrc instead, since mount_smbfs is suid root)...
Anyway, I run into it infrequently enough that I just twiddle the sysctl knob. It gets the job done. |
|
Crypto
Premium
join:2001-01-07
Saint Charles, MO
| reply to Crypto
Problem solved. Culprit: Bad Linux NIC/Driver
Wow, after googling on the sysctl command milo posted here, I saw at least one instance of someone saying "I set this command on my BSD box because I was having problems with a realtek ethernet card that for some reason wasnt handling delayed ACKs well"
Well, I have a Linksys card, which had a realtek in it. So I shut down the venerable linux server thats been going for 5 years, and swapped out the linksys card with a spare Intel E100 I had.
I remmed out all the samba performance options I had tried, and set delayed acks back to 1 on the OS X box, and pulled a giant file down from the samba share.
And it hauled ass.
Thats damned near the strangest network problem I have ever seen in my life, and I have no way to explain it other than to chalk it up to bad linux driver code.
Thanks everyone, for their help, and specially thanks to Milomindbender for putting me on the right track.
--
I may not agree with what you say, but I'll defend your right to encrypt it. |
|
Crypto
Premium
join:2001-01-07
Saint Charles, MO
| reply to MiloMindbend
Re: OS X client, linux server, samba pain.
said by MiloMindbend :Try this (on the OS X side): 'sudo sysctl -w net.inet.tcp.delayed_ack=0' DING DING DING DING DING!! And we have a winner! that sped it right up.
You say that this should do the same thing as putting TCP_NODELAY on the Linux samba server? Thats odd, because I did that already and didnt seem to have any results.
It's certainly much, much faster with delayed acks set to 0 on the OS X box. What are the ramifications to just leaving the OS X box like that?
--
I may not agree with what you say, but I'll defend your right to encrypt it. |
|
subcultured
Premium
join:2001-08-21
Jamaica Plain, MA
| reply to Crypto
said by Crypto :said by Daemon :I can tell you it's not a fatal flaw in the SMB implementation in OSX. I have a Fedora box connected to a 10.4 machine (used to be 10.3), and it just flies. Thats actually the most valuable data point I have gotten yet from this whole thing. That tells me that there might be something peculiar to the way this version of samba was compiled. Maybe it's time to compile it from scratch and see what happens. I was the admin for about a hundred macs in my last job and we had several Fedora boxen running samba flawlessly to the macs and windows clients alike. We also had one Debian fileserver (can't remember which version...) that did indeed give us some serious problems with netatalk but actually worked very well using SMB.
Obviously there is some other issue with your server. Check that your macs, when sharing to windows/linux clients via samba, perform up to standard just to rule out an odd firewall issue. Regardless, I'd suggest rolling your own samba. It can't hurt...
Good luck,
Ian
--
Verum Ipsum Factum |
|
MiloMindbend
join:2001-01-18
Jeannette, PA
1 edit |  reply to Crypto
Try this (on the OS X side):
'sudo sysctl -w net.inet.tcp.delayed_ack=0'
(set it back to 1 when you're done playing)
It disables the TCP stack's delayed acks (that's what the TCP_NODELAY sockopts in smb.conf does). I haven't found a good way to pass this to the smb/cifs kernel extension, so I just twiddle the sysctl knob when I encounter a slow SMB server (in my case it's the corporate Win2K servers at work that are abysmally slow unless I turn off the delayed acks). |
|
Crypto
Premium
join:2001-01-07
Saint Charles, MO
| reply to computx
Re: Please stop trying to push NFS. It sucks.
As I explained in detail before, I dont have matching UID/GID's on the mac and UNIX hosts. This means that I have to do NFS maps, something I hate, and something that I cannot support on this network. The idea is that this implementation needs to be so simple that it runs itself after I'm gone, and NFS isnt the way to do that, frankly.
On the NAS support front, it looks like the "optimize for macs" setting turns on an option I had never heard of called "sendfile", which is apparently not enabled by default on some samba implementations (and apprently not on the debian-based implementation shipped with this NAS device). When I get home tonight I hope to test this option and see what sort of results it gives.
--
I may not agree with what you say, but I'll defend your right to encrypt it. |
|
wmcbrine
Touched by His Noodly Appendage
join:2002-12-30
Laurel, MD
| reply to sporkme
said by sporkme :although I don't see why one can't have both NFS and CIFS on the same box - I'm running samba, nfs and netatalk, all exporting the same stuff I've done the same in the past, albeit only on a small LAN. I don't understand cbellers' reference to "implementing a NFS client on a crapload of win32 systems just to make the mac happy". Samba for Win32 clients, NFS and Netatalk for others; no problem that I'm aware of. |
|
computx
Is it Friday yet?
Premium
join:2000-09-02
Kirksville, MO
| reply to Crypto
said by Crypto :Please stop trying to push NFS. It sucks. Not really pushing nfs just thought I would mention an alternative as In my opinion samba sucks. (looks like it sucks for you too.)
Good luck with your samba installation.
--
To err is human...to really foul up requires the root password. |
|
Crypto
Premium
join:2001-01-07
Saint Charles, MO
| reply to sporkme
I tried netatalk, but its fairly ugly and has authentication issues of its own. Samba really is the preffered way to go for all clients because authentication ultimately needs to be done by the windows system anyway.
I've never had to use netstat in a performance diagnostic capacity before, can you point me towards a howto or drop me a few pointers?
--
I may not agree with what you say, but I'll defend your right to encrypt it. |
|
sporkme
drop the crantini and move it, sister
Premium,MVM
join:2000-07-01
Morristown, NJ
 ·Optimum Online
| reply to Crypto
said by Crypto :my write speed is almost as fast with samba as with ftp or scp, but the read speed is still abyssmal, under 1MB/sec. Have you run tcpdump to get an idea of what's different?
Are you dead-set against netatalk? You made it very clear you don't want NFS (although I don't see why one can't have both NFS and CIFS on the same box - I'm running samba, nfs and netatalk, all exporting the same stuff). |
|
