doing a network/OS/samba benchmark *new benchmark done scroll down*

[kylef]

I'm willing to bet that what you're seeing is protocol overhead of some sort. SMB is something of a voodoo art, and many rumors abound that Microsoft itself wishes to ditch the protocol entirely on its next OS, citing the difficulty of maintaining backwards compatibility. I'm sure that some of it also has to do with the fact that Samba servers are now seen as a "threat."

That said, there are two things that I would check:

1. I'm sure you've already made sure your setup is correct, but we were trying to diagnose some Samba speed problems at school with some departmental machines which appeared to be setup correctly. The culprit? The slow machine's subnet mask was 8 bits longer than the faster machines' subnet masks, forcing IP packets to go through the default gateway rather than be sent directly over ethernet. The system administrator thought the longer subnet mask was better even though all the machines were connected to a huge switched 802.3u ethernet anyway... (This is actually what I would consider an IP setup error and would reflect poor performance with FTP as well).

2. Another HUGE speed culprit with Samba is its reverse domain name lookups of the incoming requester's IP address. These reverse lookups seem to be done MUCH more frequently than should be required. I have managed to get significant speed improvements if I manually place an entry for the remote machine's domain name in the Samba server's /etc/hosts file. That way, the reverse lookups never go out over the wire and are satisfied locally (and therefore much more quickly). I've been looking for an option in smb.conf to turn OFF reverse name lookups, but can't seem to find one...

edit: I forgot to say "YMMV" with my suggestions

 

[manly]

No offense, but that sounds like typical MS FUD. They've been using/extending SMB since the PC DOS days, and now it's too difficult to maintain?

The only reason to totally deprecate it and cook up something new is because Samba is a better performing SMB server (unfortunately they have to play catch-up with undocumented Windows implementations all the time). All of us really doubt that SMB overhead is 80% of the wire throughput. I think on the first page n0c or Nothinman (too lazy to check) stated that SMB should be fairly close to FTP.

As far as name resolution, check out the name resolve order parameter. The dns proxy parameter appears to be relevant as well. I'm not sure name resolution would impact sustained file transfer rate though.

 

[Nothinman]

Just to show that SMB alone doesn't suck that bad, first FTP becauses ncftp shows the file sizes and that's necessary for referance.

ncftp /mnt/tmp > mput *
The Osbournes - Episode 1.WMV: 34.72 MB 8.42 MB/s
The Osbournes - Episode 2.WMV: 34.62 MB 8.28 MB/s
The Osbournes - Episode 3.WMV: 34.38 MB 8.17 MB/s
The Osbournes - Episode 4.WMV: 53.89 MB 8.42 MB/s
The Osbournes - Episode 5.WMV: 54.35 MB 4.96 MB/s
The Osbournes - Episode 6.AVI: 94.33 MB 958.47 kB/s

smb: \mnt\tmp\> mput *
putting file The Osbournes - Episode 6.avi as \mnt\tmp\The Osbournes - Episode 6.avi (7796.6 kb/s) (average 2725.3 kb/s)
putting file The Osbournes - Episode 5.WMV as \mnt\tmp\The Osbournes - Episode 5.WMV (7859.3 kb/s) (average 2956.0 kb/s)
putting file The Osbournes - Episode 4.WMV as \mnt\tmp\The Osbournes - Episode 4.WMV (6021.5 kb/s) (average 3124.4 kb/s)
putting file The Osbournes - Episode 3.WMV as \mnt\tmp\The Osbournes - Episode 3.WMV (367.5 kb/s) (average 2118.5 kb/s)
putting file The Osbournes - Episode 2.WMV as \mnt\tmp\The Osbournes - Episode 2.WMV (7275.8 kb/s) (average 2212.5 kb/s)
putting file The Osbournes - Episode 1.WMV as \mnt\tmp\The Osbournes - Episode 1.WMV (7501.7 kb/s) (average 2304.6 kb/s)

As you see the OS decided to flush the cache to disk cause it had no more cache memory available, which is the linux-2.4.18's fault not SMB's, but overall the speed is decent and CPU usage isn't terrible smbd spiked at ~30% and proftpd at ~40% on my Alpha 600au. SMB is slightly slower, but not nearly 80% and I think some of the difference could be the varying algorithms used to calculate transfer speed used by smbclient and ncftp. Basically both get ~8M/s.

Also this was done using ext2 on the destination disk, another filesystem may have more or less overhead associated with it, for instance ext3 was slower over all but spread the syncing out instead of one big spike like ext2. Oh and the ATA interface in the Alpha sucks bad (well that or the Maxtor disk hooked up to it), it can only do ~3MB/s sustained.

 

[kylef]

No offense, but that sounds like typical MS FUD. They've been using/extending SMB since the PC DOS days, and now it's too difficult to maintain?

Well, err... Yes. I have a friend who used to work on the Windows team (XP) on some of the systems coding, and he claimed that some of the coding boiled down to thousands of "special cases" for dealing with specific versions of Windows, Service Packs, etc. Basically, the programmers can't stand it. They must deal with functionality, remember, that Samba does not need to provide, such as NetBEUI (which is just one of many backwards compatibility issues). Microsoft would obviously rather have their own distributed filesystem, which has the additional benefit for them of making people upgrade

I too suspect that Microsoft feels pressure from Samba, and that this pressure is one of the factors in their consideration of whether or not to continue support of such a legacy protocol.

I'm sure that some of it also has to do with the fact that Samba servers are now seen as a "threat."

I love Samba and what it enables me to do. But in my experience it is much more susceptible to strange configuration problems that lead to performance bottlenecks than straight FTP, NFS, or AFS.

 

[n0cmonkey]

BTW, SMB does seem slow on Mac OS X, although I didnt do any real benchmarks or anything.

 

[Mucman]

I finally installed pure-ftp on the machine... I started doing a file download from the machine and was getting 3.2MB/s. The CPU on the machine got pegged (~90%) by the
pure-ftpd program, and CPU interupt processing was at 48%... do you think it's the hardware then?

 

[Mucman]

After some time away from the mayhem I decided to do another test... no more inferior machines involved this time

The server is a PIII 950 768M RAM FreeBSD pure-ftpd
The client is a PIII 450 128M RAM Win98 running smartftp

Here is a screenshot of both my tests : smartftp screenie

The first section of the speed graph shows the win98 machine uploading to my FreeBSD box. I am getting around 3.5-4MB/s. After the 500M file uploaded I tried downloading it
back to the win98 machine... As you can see if peeks at almost 10MB/s! So I am guessing that my cabling job is around the FastEthernet spec then

So this raises some new questions... why is uploading slower? Why the peaks when downloading? Is the limitation now on the win98 TCP stack?

 

[Nothinman]

May I ask why you used an unregistered program to take the screen shot or convert it to jpg? Hell make it a bmp with ms paint and use gimp or imagemagick to make it a jpg or png, that watermark is annoying =)

Also something, anything really, other than Win98 would be good. Win98 probably is the worst guinea pig for networking benchmarks.

So this raises some new questions... why is uploading slower? Why the peaks when downloading? Is the limitation now on the win98 TCP stack?

My initial guesses on uploading would be:

1) Win98's drive cache doesn't read ahead very well and can't keep data to the ftp client steadily
2) Win98 is setup for modem use out of the box, it could be fragmenting the frames for no reason.

My initial guesses on downloading would be:

1) Win98s drive cache sucks and flushes to disk too often, forcing the FTP client to block, of course with only 128M what do you want
2) The FreeBSD drive cache isn't doing read ahead well and can't keep data to the ftp server steadily, although this isn't likely =)

 

[Mucman]

May I ask why you used an unregistered program to take the screen shot or convert it to jpg? Hell make it a bmp with ms paint and use gimp or imagemagick to make it a jpg or png, that watermark is annoying =)

Hehe, sorry but I wasn't doing this on my computer and I don't like installing stuff on other peoples machines . Next time I will tranfer the image to my machine and gimp it up for ya

Also something, anything really, other than Win98 would be good. Win98 probably is the worst guinea pig for networking benchmarks.

Yeah I know... I don't have win2k or XP, and my bro won't appreciate FreeBSD on there...

My initial guesses on uploading would be:

1) Win98's drive cache doesn't read ahead very well and can't keep data to the ftp client steadily
2) Win98 is setup for modem use out of the box, it could be fragmenting the frames for no reason.

#2 is not it since I have done all the registry tweaks and stuff from speedguide.net... #1 is probably it then, how could I test to see if it is the case?
I think I might play with RAMDrives so I can eliminate slow I/O with the HD.

My initial guesses on downloading would be:

1) Win98s drive cache sucks and flushes to disk too often, forcing the FTP client to block, of course with only 128M what do you want
2) The FreeBSD drive cache isn't doing read ahead well and can't keep data to the ftp server steadily, although this isn't likely =)

#1 was my first though too... I am going to load up that machine with RAM and see how it performs. I think that is what is where the peaks occur... the RAM cache is full and it starts to commit the data to the HD, when it's done it goes fast again until it's full. How could you even suggest #2?