samba - Jul 2003 - Marginal write performance & pauses in outgoing transfers - Possible bug

Hello everybody,

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)

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).

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 ;)

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.

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.

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.

Does anyone happen to know what could be causing this? I ran into a post
on the FreeBSD net mailing list posted a long time ago by someone who had
this same problem, but his difference between read and write performance
was much bigger, and that was an ancient version of Samba which had
certain wait flag turned on in the code. However, that was supposed to be
off by default in future versions.

Please advice!

Thanks in advance,

Nicolas Gieczewski
Nix Software Solutions
http://www.nixsoftware.com/

Hi,

We have been seeing similar symptoms on win98 clients with canon printer
monitors (LBP-810).

Having the monitor running seemed to cause the smb requests to go in
bursts with delays of about one second between groups. Removing it
solved the problem. Caused big problems myob premier and large datafiles
(130mb).


Probably unlikely but it drove me crazy for well over a week.

Joe



On Sat, 2003-07-26 at 23:36, Nicolas Gieczewski wrote:
> Hello everybody,
> 
> 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)
> 
> 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).
> 
> 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 ;)
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Does anyone happen to know what could be causing this? I ran into a post
> on the FreeBSD net mailing list posted a long time ago by someone who had
> this same problem, but his difference between read and write performance
> was much bigger, and that was an ancient version of Samba which had
> certain wait flag turned on in the code. However, that was supposed to be
> off by default in future versions.
> 
> Please advice!
> 
> Thanks in advance,
> 
> Nicolas Gieczewski
> Nix Software Solutions
> http://www.nixsoftware.com/
> 
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  http://lists.samba.org/mailman/listinfo/samba

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.


____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005

Test you transfer from samba location?
If not try use smbclient to connect w2k and test transfer.
Second test is Another clean W2k station test.

Possible this can be a problem with kernel oplock, oplocks and level2
combination this is aplied when file is reading from samba disk but when
writing to samba maybe not used with fast speed.

Bye.

----- Original Message ----- 
From: "Nicolas Gieczewski" <nicolas@nixsoftware.com>
To: <samba@lists.samba.org>
Sent: Saturday, July 26, 2003 3:36 PM
Subject: [Samba] Marginal write performance & pauses in outgoing
transfers -Possible bug

> Hello everybody,
>
> 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)
>
> 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).
>
> 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 ;)
>
> 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.
>
> 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.
>
> 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.
>
> Does anyone happen to know what could be causing this? I ran into a post
> on the FreeBSD net mailing list posted a long time ago by someone who had
> this same problem, but his difference between read and write performance
> was much bigger, and that was an ancient version of Samba which had
> certain wait flag turned on in the code. However, that was supposed to be
> off by default in future versions.
>
> Please advice!
>
> Thanks in advance,
>
> Nicolas Gieczewski
> Nix Software Solutions
> http://www.nixsoftware.com/
>
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  http://lists.samba.org/mailman/listinfo/samba