A lot of syntax updates, consistency when using certain tags and converting ASCII -> XML

(This used to be commit 85434d3144656e6fe587637276d6a2667df1857f)

1 files changed, 16 insertions, 16 deletions

diff --git a/docs/docbook/projdoc/Speed.xml b/docs/docbook/projdoc/Speed.xml
index 9dd76e887d..448ce61663 100644
--- a/docs/docbook/projdoc/Speed.xml
+++ b/docs/docbook/projdoc/Speed.xml
@@ -58,11 +58,11 @@ performance of a TCP based server like Samba.
 
 <para>
 The socket options that Samba uses are settable both on the command
-line with the -O option, or in the smb.conf file.
+line with the <option>-O</option> option, or in the &smb.conf; file.
 </para>
 
 <para>
-The <command>socket options</command> section of the &smb.conf; manual page describes how
+The <parameter>socket options</parameter> section of the &smb.conf; manual page describes how
 to set these and gives recommendations.
 </para>
 
@@ -75,7 +75,7 @@ much. The correct settings are very dependent on your local network.
 <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 <command>socket options = TCP_NODELAY</command> doubles the read 
+adding <parameter>socket options = TCP_NODELAY</parameter> 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>
@@ -86,7 +86,7 @@ that the Microsoft TCP/IP stack is slow in sending tcp ACKs.
 <title>Read size</title>
 
 <para>
-The option <command>read size</command> affects the overlap of disk
+The option <parameter>read size</parameter> 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
@@ -114,9 +114,9 @@ pointless and will cause you to allocate memory unnecessarily.
 <title>Max xmit</title>
 
 <para>
-At startup the client and server negotiate a <command>maximum transmit</command> size,
+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 <command>max xmit = </command> option
+maximum size that Samba will negotiate using the <parameter>max xmit = </parameter> 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
@@ -139,7 +139,7 @@ In most cases the default is the best option.
 <title>Log level</title>
 
 <para>
-If you set the log level (also known as <command>debug level</command>) higher than 2
+If you set the log level (also known as <parameter>debug level</parameter>) 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 very
 expensive. 
@@ -150,20 +150,20 @@ expensive.
 <title>Read raw</title>
 
 <para>
-The <command>read raw</command> operation is designed to be an optimised, low-latency
+The <parameter>read raw</parameter> operation is designed to be an optimised, low-latency
 file read operation. A server may choose to not support it,
-however. and Samba makes support for <command>read raw</command> optional, with it
+however. and Samba makes support for <parameter>read raw</parameter> optional, with it
 being enabled by default.
 </para>
 
 <para>
-In some cases clients don't handle <command>read raw</command> very well and actually
+In some cases clients don't handle <parameter>read raw</parameter> 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 <command>read raw = no</command> and see what happens on your
+So you might like to try <parameter>read raw = no</parameter> and see what happens on your
 network. It might lower, raise or not affect your performance. Only
 testing can really tell.
 </para>
@@ -174,14 +174,14 @@ testing can really tell.
 <title>Write raw</title>
 
 <para>
-The <command>write raw</command> operation is designed to be an optimised, low-latency
+The <parameter>write raw</parameter> operation is designed to be an optimised, low-latency
 file write operation. A server may choose to not support it,
-however. and Samba makes support for <command>write raw</command> optional, with it
+however. and Samba makes support for <parameter>write raw</parameter> optional, with it
 being enabled by default.
 </para>
 
 <para>
-Some machines may find <command>write raw</command> slower than normal write, in which
+Some machines may find <parameter>write raw</parameter> slower than normal write, in which
 case you may wish to change this option.
 </para>
 
@@ -192,7 +192,7 @@ case you may wish to change this option.
 
 <para>
 Slow logins are almost always due to the password checking time. Using
-the lowest practical <command>password level</command> will improve things. 
+the lowest practical <parameter>password level</parameter> will improve things. 
 </para>
 
 </sect1>
@@ -202,7 +202,7 @@ the lowest practical <command>password level</command> will improve things.
 
 <para>
 LDAP can be vastly improved by using the
-<ulink url="smb.conf.5.html#LDAPTRUSTIDS">ldap trust ids</ulink> parameter.
+<ulink url="smb.conf.5.html#LDAPTRUSTIDS"><parameter>ldap trust ids</parameter></ulink> parameter.
 </para>
 
 </sect1>