I wrote this up for TriLUG about 5 years ago... We tested various forms of file transfer including NFS and Samba and - if I remember correctly - we found Samba (version 3) to be about 1/3 the speed of NFS (version 2). The problem was that the Samba process waited for a commit before negotiating for the next data transfer whereas NFS filled a buffer and continuously pushed that buffer out.
Obviously if you're running from a buffer out of RAM you can run at network speeds (or as fast as your internal bus and cpu can go). Microsoft's implementation of SMB pumps the data to be moved into a buffer and works similarly, so it's almost as fast as using NFS (though it does some other weirdness that always makes it a bit slower than NFS...) NFS v3 had a toggle that also defaulted to waiting for a commit from the remote hard drive before sending more data - that moved files around just slightly faster than Samba (it crawled.) Hope that shines some light - Jon On Mon, 2005-06-20 at 11:00, John Broome wrote: > I have a RH 9 machine that is acting as a fileserver for a completly > windows network (98 & 2000), the users mentioned that the file > transfers seemed slow. > > Some testing showed that samba was moving data much slower than NFS. > Nfs was using pretty much the entire speed potential of the network, > where SMB was about half that, or less. > > No indication on the server that CPU, HDD, or memory is the problem. > > When tested off site with different hardware and a different OS > (Ubuntu 5.04), the same problem popped up. > > SMB dragging along, NFS cranking. > > Since this is a mostly windows network we can't really use NFS instead > of the samba. > > Has anyone else run into this? Some googling doesn't really turn up much. -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc
