New structure for the docs:

 - Same name for a doc everywhere (howto -> Samba-HOWTO-Collection, etc)
 - Shorter and more clearly structured Makefile
 - Make it possible to change the paths for the images
(This used to be commit 96f6c05f25acc8a9bb1977b8bd5cc97ce511b6b1)

1 files changed, 321 insertions, 0 deletions

diff --git a/docs/Samba-HOWTO-Collection/Speed.xml b/docs/Samba-HOWTO-Collection/Speed.xml
new file mode 100644
index 0000000000..44956f6812
--- /dev/null
+++ b/docs/Samba-HOWTO-Collection/Speed.xml
@@ -0,0 +1,321 @@
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+		"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+  <!ENTITY % global_entities SYSTEM '../entities/global.entities'>
+  %global_entities;
+]>
+<chapter id="speed">
+
+<chapterinfo>
+	<author>
+		<firstname>Paul</firstname><surname>Cochrane</surname>
+		<affiliation>
+			<orgname>Dundee Limb Fitting Centre</orgname>
+			<address><email>paulc@dth.scot.nhs.uk</email></address>
+		</affiliation>
+	</author>
+	&author.jelmer;
+	&author.jht;
+</chapterinfo>
+
+<title>Samba Performance Tuning</title>
+
+<sect1>
+<title>Comparisons</title>
+
+<para>
+The Samba server uses TCP to talk to the client. Thus if you are
+trying to see if it performs well, you should really compare it to
+programs that use the same protocol. The most readily available
+programs for file transfer that use TCP are ftp or another TCP-based
+SMB server.
+</para>
+
+<para>
+If you want to test against something like an NT or Windows for Workgroups server, then
+you will have to disable all but TCP on either the client or
+server. Otherwise, you may well be using a totally different protocol
+(such as NetBEUI) and comparisons may not be valid.
+</para>
+
+<para>
+Generally, you should find that Samba performs similarly to ftp at raw
+transfer speed. It should perform quite a bit faster than NFS,
+although this depends on your system.
+</para>
+
+<para>
+Several people have done comparisons between Samba and Novell, NFS or
+Windows NT. In some cases Samba performed the best, in others the worst. I
+suspect the biggest factor is not Samba versus some other system, but the
+hardware and drivers used on the various systems. Given similar
+hardware, Samba should certainly be competitive in speed with other
+systems.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Socket Options</title>
+
+<para>
+There are a number of socket options that can greatly affect the
+performance of a TCP-based server like Samba.
+</para>
+
+<para>
+The socket options that Samba uses are settable both on the command
+line with the <option>-O</option> option, or in the &smb.conf; file.
+</para>
+
+<para>
+The <smbconfoption><name>socket options</name></smbconfoption> section of the &smb.conf; manual page describes how
+to set these and gives recommendations.
+</para>
+
+<para>
+Getting the socket options correct can make a big difference to your
+performance, but getting them wrong can degrade it by just as
+much. The correct settings are very dependent on your local network.
+</para>
+
+<para>
+The socket option TCP_NODELAY is the one that seems to make the biggest single difference
+for most networks. Many people report that adding
+<?latex \linebreak ?><smbconfoption><name>socket options</name><value>TCP_NODELAY</value></smbconfoption>
+doubles the read performance of a Samba drive. The best explanation I have seen for
+this is that the Microsoft TCP/IP stack is slow in sending TCP ACKs.
+</para>
+
+<para>
+There have been reports that setting <parameter>socket options = SO_RCVBUF=8192</parameter> in smb.conf
+can seriously degrade Samba performance on the loopback adaptor (IP Address 127.0.0.1). It is strongly
+recommended that before specifying any settings for <parameter>socket options</parameter> the effect
+first be quantitatively measured on the server being configured.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Read Size</title>
+
+<para>
+The option <smbconfoption><name>read size</name></smbconfoption> affects the overlap of disk
+reads/writes with network reads/writes. If the amount of data being
+transferred in several of the SMB commands (currently SMBwrite, SMBwriteX and
+SMBreadbraw) is larger than this value, then the server begins writing
+the data before it has received the whole packet from the network, or
+in the case of SMBreadbraw, it begins writing to the network before
+all the data has been read from disk.
+</para>
+
+<para>
+This overlapping works best when the speeds of disk and network access
+are similar, having little effect when the speed of one is much
+greater than the other.
+</para>
+
+<para>
+The default value is 16384, but little experimentation has been
+done as yet to determine the optimal value, and it is likely that the best
+value will vary greatly between systems anyway. A value over 65536 is
+pointless and will cause you to allocate memory unnecessarily.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Max Xmit</title>
+
+<para>
+	At startup the client and server negotiate a <parameter>maximum transmit</parameter> size,
+which limits the size of nearly all SMB commands. You can set the
+maximum size that Samba will negotiate using the <smbconfoption><name>max xmit</name></smbconfoption> option
+in &smb.conf;. Note that this is the maximum size of SMB requests that 
+Samba will accept, but not the maximum size that the client will accept.
+The client maximum receive size is sent to Samba by the client and Samba
+honors this limit.
+</para>
+
+<para>
+It defaults to 65536 bytes (the maximum), but it is possible that some
+clients may perform better with a smaller transmit unit. Trying values
+of less than 2048 is likely to cause severe problems.
+In most cases the default is the best option.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Log Level</title>
+
+<para>
+If you set the log level (also known as <smbconfoption><name>debug level</name></smbconfoption>) higher than 2
+then you may suffer a large drop in performance. This is because the
+server flushes the log file after each operation, which can be quite
+expensive. 
+</para>
+</sect1>
+
+<sect1>
+<title>Read Raw</title>
+
+<para>
+The <smbconfoption><name>read raw</name></smbconfoption> operation is designed to be an optimized, low-latency
+file read operation. A server may choose to not support it,
+however, and Samba makes support for <smbconfoption><name>read raw</name></smbconfoption> optional, with it
+being enabled by default.
+</para>
+
+<para>
+In some cases clients do not handle <smbconfoption><name>read raw</name></smbconfoption> very well and actually
+get lower performance using it than they get using the conventional
+read operations. 
+</para>
+
+<para>
+So you might like to try <smbconfoption><name>read raw</name><value>no</value></smbconfoption> and see what happens on your
+network. It might lower, raise or not effect your performance. Only
+testing can really tell.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Write Raw</title>
+
+<para>
+The <smbconfoption><name>write raw</name></smbconfoption> operation is designed to be an optimized, low-latency
+file write operation. A server may choose to not support it, however, and Samba makes support for
+<smbconfoption><name>write raw</name></smbconfoption> optional, with it being enabled by default.
+</para>
+
+<para>
+Some machines may find <smbconfoption><name>write raw</name></smbconfoption> slower than normal write, in which
+case you may wish to change this option.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Slow Logins</title>
+
+<para>
+Slow logins are almost always due to the password checking time. Using
+the lowest practical <smbconfoption><name>password level</name></smbconfoption> will improve things. 
+</para>
+
+</sect1>
+
+<sect1>
+<title>Client Tuning</title>
+
+<para>
+Often a speed problem can be traced to the client. The client (for
+example Windows for Workgroups) can often be tuned for better TCP
+performance. Check the sections on the various clients in 
+<link linkend="Other-Clients">Samba and Other CIFS Clients</link>.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Samba Performance Problem Due to Changing Linux Kernel</title>
+
+<para>
+A user wrote the following to the mailing list:
+</para>
+
+<para>
+I am running Gentoo on my server and Samba 2.2.8a. Recently
+I changed kernel version from <filename>linux-2.4.19-gentoo-r10</filename> to
+<filename>linux-2.4.20-wolk4.0s</filename>. And now I have a performance issue with Samba. 
+Many of you will probably say,  <quote>Move to vanilla sources!</quote>
+Well, I tried that and it didn't work. I have a 100mb LAN and two computers (Linux and
+Windows 2000). The Linux server shares directories with DivX files, the client
+(Windows 2000) plays them via LAN. Before when I was running the 2.4.19 kernel
+everything was fine, but now movies freeze and stop. I tried moving
+files between the server and Windows and it is terribly slow.
+</para>
+
+<para>
+The answer he was given is:
+</para>
+
+<para>
+Grab the mii-tool and check the duplex settings on the NIC.
+My guess is that it is a link layer issue, not an application
+layer problem. Also run ifconfig and verify that the framing
+error, collisions, and so on, look normal for ethernet.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Corrupt tdb Files</title>
+
+<para>
+Our Samba PDC server has been hosting three TB of data to our 500+ users
+[Windows NT/XP]  for the last three years using Samba without a problem.
+Today all shares went very slow. Also the main smbd kept
+spawning new processes so we had 1600+ running smbd's (normally we avg. 250).
+It crashed the SUN E3500 cluster twice. After a lot of searching, I
+decided to <command>rm /var/locks/*.tdb</command>. Happy again.
+</para>
+
+<para>
+<emphasis>Question:</emphasis> Is there any method of keeping the *.tdb files in top condition or
+how can I detect early corruption?
+</para>
+
+<para>
+<emphasis>Answer:</emphasis> Yes, run <command>tdbbackup</command> each time after stopping nmbd and before starting nmbd.
+</para>
+
+<para>
+<emphasis>Question:</emphasis> What I also would like to mention is that the service latency seems
+a lot lower than before the locks cleanup. Any ideas on keeping it top notch?
+</para>
+
+<para>
+<emphasis>Answer:</emphasis> Yes. Same answer as for previous question!
+</para>
+
+</sect1>
+
+<sect1>
+<title>Samba Performance is Very Slow</title>
+
+<para>
+A site reported experiencing very baffling symptoms with MYOB Premier opening and
+accessing it's data-files. Some  operations on the file would take between 40 and
+45 seconds.
+</para>
+
+<para>
+It turned out that the printer monitor program running on the windows
+clients was causing the problems. From the logs, we saw activity coming
+through with pauses of about 1 second.
+</para>
+
+<para>
+Stopping the monitor software resulted in the networks access at normal
+(quick) speed. Restarting the program caused the speed to slow down
+again. The printer was a cannon lbp810 and the relevant task was
+something like CAPON (not sure on spelling). The monitor software
+displayed a printing now dialog on the client during printing.
+</para>
+
+<para>
+We discovered this by starting with a clean install of windows and
+trying the app at every step of the installation of other software
+process (had to do this many times).
+</para>
+
+<para>
+Moral of the story, check everything (other software included)!
+</para>
+
+</sect1>
+
+</chapter>