The macosxhints Forums
Page 3 of 4 12 3 4
Show 100 post(s) from this thread on one page

The macosxhints Forums (http://hintsforums.macworld.com/index.php)
-   Networking (http://hintsforums.macworld.com/forumdisplay.php?f=14)
-   -   SMB Server and slow transfer speeds... (http://hintsforums.macworld.com/showthread.php?t=15075)

sandtrip2 09-18-2003 11:27 AM
Sorry one more then - I'd also like to see you try :
IPTOS_LOWDELAY TCP_NODELAY as the options. Right now you have TCP_NODELAY IPTOS_THROUGHPUT

In addtion when you comment the lines out make sure you put the hash before the line itself and not before or after it. Better yet remove the lines totally and keep a couple copies of the config fil.

The constant ping output is also going to be very interesting.

jcroson 09-18-2003 12:12 PM
No noticeable difference...
 
root@mybox:~# testparm | grep 'socket options'
socket options = TCP_NODELAY IPTOS_NODELAY

5-6 minutes for a 18.1mb download.


[STATION10:~/Desktop] administrator% ping mybox > test.txt

[STATION10:~/Desktop] administrator% cat test.txt | more
PING mybox (no.not.today.dude): 56 data bytes
64 bytes from no.not.today.dude: icmp_seq=0 ttl=64 time=0.325 ms
64 bytes from no.not.today.dude: icmp_seq=1 ttl=64 time=0.277 ms
64 bytes from no.not.today.dude: icmp_seq=2 ttl=64 time=0.285 ms

----------------- SNIP FOR SANITY??? -------------------------------------

64 bytes from no.not.today.dude: icmp_seq=168 ttl=64 time=0.249 ms
64 bytes from no.not.today.dude: icmp_seq=169 ttl=64 time=0.244 ms
64 bytes from no.not.today.dude: icmp_seq=170 ttl=64 time=0.248 ms
--- mybox ping statistics ---
375 packets transmitted, 375 packets received, 0% packet loss
round-trip min/avg/max = 0.198/0.269/0.427 ms


Perfect...

JC

sandtrip2 09-18-2003 12:33 PM
> socket options = TCP_NODELAY IPTOS_NODELAY

No - TCP_NODELAY IPTOS_LOWDELAY

LOWDELAY not NODELAY

Then let's try it.

sandtrip2 09-18-2003 12:37 PM
An additional idea, in my case raising the log level from 0 to 3 will cut the untuned get speed from 645.3 to 622.2KB/s, or roughly 5 percent.

so i have my log level at 1

here's my usual tweaks to smb.conf.

[global]
log level = 1 # Default is 0
socket options = TCP_NODELAY IPTOS_LOWDELAY
read raw = yes # Default
write raw = yes # Default
oplocks = yes # Default
max xmit = 65535 # Default
dead time = 15 # Default is 0
getwd cache = yes
lpq cache = 30
[localseg]
veto oplock files = /var/lock/smb.lock
[remoteseg]
oplocks = no

jcroson 09-18-2003 12:41 PM
OK.
 
root@mybox:~# testparm | grep 'socket options'
socket options = IPTOS_LOWDELAY TCP_NODELAY

root@mybox:~# /etc/rc.d/init.d/smb reload
Reloading smb.conf file: [ OK ]

That reduced the transfer time of the 18.1mb file to 2 minutes!

JC

jcroson 09-18-2003 12:53 PM
Quote:
Originally posted by sandtrip2
max xmit = 65535 # Default
dead time = 15 # Default is 0
Just to be noteworthy, not picky, the manpage reads:

max xmit (G)
This option controls the maximum packet size that will be nego-
tiated by Samba. The default in Samba 2.2.6 is now 16644
(changed from 65535 in earlier releases) which matches Windows
2000. This allows better performance with Windows NT clients.
The maximum is 65535. In some cases you may find you get better
performance with a smaller value. A value below 2048 is likely
to cause problems.

Default: max xmit = 16644

Example: max xmit = 8192

The next parameter "dead time" is actually used as "deadtime" per the man page, although it could just be depreciated.

Can I simply reload the conf and not have to send a SIGHUP to realize the new values?

Thanks for your input.

JC

sandtrip2 09-18-2003 01:20 PM
I've found in real world testing the option that is directly related with the MTU and window size is max xmit. This option sets the largest block of data Samba will try to write at any one time.

Because the percentage of each block required for overhead falls as the blocks get larger, max xmit is conventionally set as large as possible. It defaults to the protocol's upper limit, which is 64 kilobytes. The smallest value that doesn't cause significant slowdowns is 2048. If it is set low enough, it will limit the largest packet size that Samba will be able to negotiate. The new value of 16644 may work better but as with any tweak your milage may varry.

I believe deadtime vs dead time is depricated like you said.

You sould be able to reload the conf.

Glad that we got to the bottom of the issue! I was worried it was going to be more complex but I'm glad we got it hammered out.

jcroson 09-18-2003 01:29 PM
I will still...
 
Continue to play with it. Even though the tweaks worked to improve the transfer time, it by no means meets the performance level of the Win2k machines.

I appreciate all your input. I'll keep this tread posted if I have an epiphany.

JC

sandtrip2 09-18-2003 01:35 PM
i'll continue to hack it with you if you'd like.

can you set the options I posted in the previous post? try it with the new limit and the old limit.

how are you timing the transfers from the win2k box? is it possible to install cygwin and then time a cp?

jcroson 09-18-2003 01:48 PM
No reason to.
 
It's painfully clear that the Win2k boxes WAY outperform the Mac box. I'd be willing to bet that the transfer speed is 10 times faster.

JC

hayne 09-18-2003 01:58 PM
Perl script to help in diagnosis
 
Here is a Perl script which might help in diagnosing the problem. You use it like the 'cp' command, specifying a source and destination file. It does the copy and prints out timing info.

To use it with the file you had tried earlier, try running it like this:

testfilecopy /Volumes/company/Technology/ffbgalmac.zip /dev/null

where I specified /dev/null as the destination so nothing would be written on the local disk. This factors out any possible issues with slowness of the local disk.

Code:
#!/usr/bin/perl -w

# This script is intended for use in testing the speed of file copying
# (e.g. when experiencing slow copying of files from a networked drive)

# The source and destination files are given as command-line arguments
# in the same order as the 'cp' command
# Note that it is often useful to give /dev/null as the destination
# in order to factor out issues with the local file system

$file_to_copy = $ARGV[0];
$destination = $ARGV[1];

$buffsize = 64 * 1024; # experiment with different buffer sizes

# We use the Time::HiRes module in order to get sub-second timing
# This module is probably not installed by default but you can
# get it via http://cpan.org/
# Otherwise, comment out the following line

use Time::HiRes qw(time);

sub print_message($)
{
    my ($message) = @_;
    my $elapsed = time() - $start;
    printf("%.2f seconds: %s\n", $elapsed, $message);
}

$start = time();
open(SRC, "<$file_to_copy")
                || die "can't open file $file_to_copy for reading: $!";
open(DEST, ">$destination")
                || die "can't open file $destination for writing: $!";

print_message("files are open");
$total_nread = 0;
while ($nread = read(SRC, $buffer, $buffsize))
{
    $total_nread += $nread;
    print_message("read $total_nread bytes");
    print DEST $buffer;
}

close(DEST);
close(SRC);
print_message("files are closed");

$total_time = time() - $start;
$transfer_rate = ($total_nread / 1024) / $total_time;
printf("Transfer rate: %.1f KB/s\n", $transfer_rate);

jcroson 09-18-2003 02:07 PM
Cool
 
137.00 seconds: read 19692336 bytes
137.00 seconds: files are closed
Transfer rate: 140.4 KB/s

hayne 09-18-2003 02:22 PM
binmode
 
By the way, if you have Perl installed on your Windows machines, you could run the above 'testfilecopy' script there to get comparable numbers.

But you would have to add two additional lines to the script to make it work on Windows. You need to add 'binmode' commands for both the SRC & DEST filehandles in order to avoid problems with Windows end-of-line handling. So add the following lines after the lines that 'open' the files:

Code:
binmode(SRC);
binmode(DEST);
These lines are innocuous on UNIX (e.g. OS X) and so you could add them into the script everywhere if you like.

m_bawdon 09-24-2003 04:46 PM
more of the same from a newbie
 
i am having what i think is a similar problem to this, but i am a relative newbie to mac's, most of the stuff here i am unfamiliar with but this is my situation

12" powerbook OsX 10.2.6 10/100 ethernet, connected as in the Mac OSX hacks book "one wire network", with a CAT-6 cable into my XP pc also with 10/100 ethernet

copying a large file from pc to mac by just dragging it from the pc's shared folder is not too bad, not particularly quick though, but copying a file from mac to pc is incredibly slow

if, as it sounds you have managed to sort this, i would really appreciate if you could help, bearing in mind i am no expert

jcroson 09-24-2003 05:08 PM
How are you sharing?
 
Are you using the Windows File sharing option in OS-X, and are you using XP-Pro?

JC

m_bawdon 09-24-2003 07:38 PM
yes i've turned on the windows sharing on OSX and i'm using XP Pro

jcroson 09-25-2003 10:06 AM
From what machine?
 
Are you working on the Mac, trasferring files TO and FROM the PC? If so, I doubt that I can help you, since you cannot "tweak" windows file sharing too much that I'm aware of, unless you use third party tools like http://www.tweakinternals.com/. Make sure ALL your updates to XP have been done...M$ bugs...:rolleyes:

If you are working on the PC, and trasferring files TO and FROM the Mac, you will have to dig into the Mac's Samba configuration files, and tweak them. Use some of the info from previous posts in this thread, and go to http://www.samba.org/ for more detailed information about the smb.conf file and it's configuration parameters.

I also found a good article at http://www.opensource.apple.com/proj...l/osxsmb.html.

That should give you a good start.

JC

hayne 10-07-2003 11:43 AM
other thread
 
For the benefit of anyone who comes upon this thread in future, I note that there is another thread which discusses a similar problem only with AFP shares instead of SMB shares.
http://forums.macosxhints.com/showth...=&postid=84058

And I have posted an improved version of my Perl script in that thread.

stw1530 04-15-2005 11:57 AM
same sluggishness, solutions may be over my head
 
Hello,
I have a similar sluggish problem:
I and 6 other designers are on OSX.3.8, and connect to a fileserver running windows 2000 server. I have a pc and a mac in front of me. the pc with xp pro connects with no problem, but when I try and connect from the mac, it is painfully slow. It takes forever just to display the contents of a folder (especially if there are a lot of items in that folder), let alone uploading or downloading files. At one point while I was waiting for a folder to display, I got on the pc and surfed 4 folders deeper than the one that was trying to render, copied a file, pasted it on a web server and tested it before the other folder even displayed. Unfortunately(or fortunately for me) I'm the only designer who has the option of using the pc. I ended up posting a file on my mac's web server, and my coworker across campus downloaded a 100MB file in the blink of an eye. Why is the speed that fast over the internet and not to the next building over? Is it a mac issue or should I have the sys admin of the fileserver look into it on his end. Everything that has been said so far in this thread is way over my head. Is there a pseudo-layman's version of a fix?

hayne 04-15-2005 05:39 PM
Quote:
Originally Posted by stw1530
Is it a mac issue or should I have the sys admin of the fileserver look into it on his end. Everything that has been said so far in this thread is way over my head. Is there a pseudo-layman's version of a fix?
Networking problems are always hard. There are so many variables - the machines at each end, the software each is running, the software used for doing the file transfer, the cabling, the routers etc that intermediate between the machines, ...
There is usually no quick fix.
You need someone who can look at the whole picture.

One thing you could do is try to get a better diagnosis of the problem by changing some of the variables. E.g. see what the transfer speed is if you use a command-line tool instead of Finder, see what happens if you mount the disk inside of Virtual PC on the Mac, see what happens if you use an FTP client to download files from the server, ...


All times are GMT -5. The time now is 07:42 PM.
Page 3 of 4 12 3 4
Show 100 post(s) from this thread on one page

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
Site design © IDG Consumer & SMB; individuals retain copyright of their postings
but consent to the possible use of their material in other areas of IDG Consumer & SMB.