Hello Dragan, Thanks a lot for your reply. Alright, it was not a bug in Samba after all. You were right, I was wrong, excuse me for blaming Samba and being an idiot :) But please read on, because I'm still lost here.
As I expected, this was not an issue with my physical network setup or topology. These machines are on the same desk with no routers in the middle, and my hub might be old and suck but, as I had said, I can achieve equal incoming/outgoing transfer rates with other protocols such as FTP. By the way, by "there are no collissions" I meant "no more collissions than normal", just to remark that it wasn't a duplex or network problem. This is what I did: I installed Windows XP in a virtual machine (VMware) running inside the Windows 2000 box that was receiving from Samba at 100 KB/s, with bridged networking. I transferred from Samba to the virtual XP machine, and... consistent transfer, with no pauses and very close to 10 mbps. It's still the same physical computer and network card receiving the traffic, but it's another OS picking it up. So, my network was fine and there's something wrong with my Windows 2000 installation, which means I'm most likely going to be stuck with one of those sticky Windows-like problems. This is a log generated by tcpdump for the transfer of a 6 MB file from Samba to Windows 2000. It includes the initial process of me hitting Ctrl+C on the selected file and pasting it in a different directory on the Win2k box. Win2k took about 3 seconds just to copy the link to the clipboard before turning the hourglass back into the normal pointer (I know these terms sound lame but hey, it's Windows). http://nss.sytes.net/slow.smb.tcpdump.01.log Note how there are certain whole seconds where there's no traffic at all, and some others where just three or four packets go through. Browsing a directory on a Samba share from the Win2k box is really sloppy too: sometimes (at random), it takes Windows a couple of seconds to retrieve information on a file when selecting it, such as size and whatever it shows in the status bar for the currently selected file. Watching the hub's activity LED indicates the presence of the evil traffic pauses between packets. The main reason why I didn't want to send over my smb.conf is that I had tried so many combinations that I didn't know which to pick, but here's what I had been always using: http://nss.sytes.net/smb.conf Thanks again for the interest, and please let me know if you find something that looks wrong. I hope so, because I'm not looking forward to reinstalling Win2k. I've had this same installation running for three years with no other problems. *sniffles* Cheers, Nicolas Gieczewski Nix Software Solutions http://www.nixsoftware.com/ ----- Original Message ----- From: "Dragan Krnic" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, July 27, 2003 12:53 Subject: Re: Marginal write performance & pauses in outgoing transfers - Possible bug First off, Nicolas, forget about a possible bug in samba, that can explain your problem. It isn't there. What is there, is some kind of network misconfiguration, but you should give the list more details. What kind of medium are you using? How are server and clients connected? Do you have a hub or a switch? Which? Are there any routers in between? How's your name service configured? Lots and lots of simple details that just might pin point what your problem is. | I have a FreeBSD 4.8-STABLE server running Samba | 2.2.8a and a workstation running Windows 2000 SP4. | Whereas FTP transfers between these boxes average | 700 KB/s (10 mbps LAN) in both directions, Samba | transfers are exhibiting this odd behavior: | | Windows 2000 --> Samba = 700 KB/s (perfect) | Samba --> Windows 2000 = 100 KB/s (terrible, | inconsistent, with LONG pauses) This isn't a rare condition. My users have exactly the same problem accessing some MS Win2K servers across routers. The only thing that worked was to transfer their data to another server whose route didn't pass through a specific router (1 of 12). They offloaded data to the Win2K server at 3-4 MB/s but couldn't get more than 3-400 KB/s back from it, often as low as 30 KB/s. | Trust me, I have tried *everything* I've run into as | far as tuning goes, so please don't ask if I've | tuned up my stuff or request my configuration | file :) If this were a configuration-related issue, | performance should be the same no matter in which | direction data is transferred. Nevertheless, I have | really tried everything that exists. Furthermore, I | remember I didn't have this problem with certain | older version of Samba before I upgraded my ports | (unfortunately I don't remember which version it | was, but I don't really want to downgrade). I can't trust nothing. Your samba upgrade may have coincided with another change in your working environment of which you might as well be unaware. Take ethereal and look what is really happening. | The problem lies in the fact that outgoing transfers | are not consistent and undergo VERY long, random | pauses. My hub's activity LED shows that, during a | transfer from Samba to Win2k, no packets are | transferred about 70% of the time. Yep, only during | about 30% of the total time a transfer takes is there | actual network activity--the remaining 70% of the | time is wasted on random (both length-and interval- | wise) pauses. When transferring the other way | around, though (Win2k --> Samba), it's just as fast | as FTP (because I *do* have my stuff properly | tuned!), so fast in fact that it makes my hub's | excessive bandwidth alert LED go on ;) Ah, OK. One precious detail - you are connecting through a hub. It looks like you should throw away that hub and get a decent switch, which are real cheap nowadays. Not only will it be faster (your 10 Mbps is a special option in most of them, they normally work with 100 if not 1000 Mbps), but also a lot of problems in connection with collisions are gone. Your fine- tuning shouldn't hurt, but too much of a good thing doesn't necessarily need to be good. Some fine-tuning detail may be your problem. | All my network cards are propery configured, both | media- and duplex- wise. There are no collissions. I | don't even know why I'm saying this, because the | rates I can achieve with FTP both ways alone proves | that Samba is the culprit. ... or your smb.conf. I don't trust your smb.conf as much as you do. If you don't wanna show it, then keep on sulking, but no one will help you. On the other hand, you can't not have a little collisions, if you have a hub. It's in the nature of the medium, unless there's only 1 client and 1 server, but even then... | Because most of the time a transfer takes to | complete is wasted on those random pauses, anything | I could tune concerning buffer sizes and the like is | almost useless because it only takes effect while | data is actually being transferred, not during the | pauses. I have fiddled with buffer sizes and, by | looking at the hub's activity light, I could | (visually and easily) see how more or less data was | transferred in between the pauses depending on the | buffer sizes I chose. However, the pauses stayed | consistent throughout all my tests. By using larger | buffer sizes, all I could do was push more data | through in between the pauses, but my tuning never | affected the length or interval of the pauses | themselves. Buffer sizes are not the only thing I | fiddled with, and anyway, this was the same | configuration file I had been using with that older | version of Samba that didn't have this problem, and | nothing changed in between. It is credible that samba server doesn't shift gears down to 1 Mbps. Of course, the speed loss comes from long pauses between transfers. Who causes them? Most frequently some sort of name-resolution mechanism is misconfigured, or some optional "advanced" settings are not understood the same way by both parties. Take a spare client, install it, patch it and don't optimize it. Do you still have the problem? | And again, the pretty good rate (for a 10 mbps LAN) | I can achieve in the Win2k --> Samba scenario proves | that there's nothing wrong with my configuration. Doesn't prove anything. We're at square one. I don't know what's your problem. You don't know what's your problem. We have widely varying views on the quality of your installation. Still, chances that a bug in samba is to blame are rather faint. Try to exhaust all other possibilities before you blame samba. Take time. -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba