observations on nt smb support = no

[Sven Rudolph]

We use Samba 2.0.6 as server, the clients are about 10 NCD WinCenter
(NT 3.51 multiuser, WinCenter 3.0.34 based on Citrix WinFrame 1.6)
machines with about 70 concurrent users each and several WinCenter (as
above) and NT Terminal Server (NT 4.0 multiuser with
MetaFrame/WinCenter (X11 addon)) machines.

The 2.0.6 smb.conf manpage says:

       nt smb support (G)

              This  boolean  parameter controls whether smbd will
              negotiate NT specific SMB support with  Windows  NT
              clients.  Although  this  is  a developer debugging
              option and should be left alone,  benchmarking  has
              discovered that Windows NT clients give faster per-
              formance with this option  set  to  "no".  This  is
              still  being investigated. If this option is set to
              "no" then Samba offers exactly the same  SMB  calls
              that  versions  prior  to  Samba2.0  offered.  This
              information may be of use if any users  are  having
              problems with NT SMB support.

              Default:      nt support = yes

Setting nt smb support =n causes visible changes.

With =yes one smbd is startet for each client machine, whereas with
=no one process runs for each user (and if she logs in from
multiple client machines she gets in addition another process for each
additional machine).

In the multiuser NT case this means that =yes causes all file service
connections for all users to be multiplexed via one daemon. Unless I'm
wrong this implies one TCP connection. This might constitute a
bottleneck and explain performance differences. OTOH I didn't do real
performance tests yet.


=yes caused log file = /var/log/samba/%U to fail. The user's log
entries were shuffled around all logfiles. I didn't find a pattern.
This might be a samba bug, but I heard of a potentially related
observation: When printing from a WinCenter machine to another one
acting as print server the jobs often arrive at the print server with
the wrong user identity.

	Sven