A detailed description of our status and dilemma is given below...
This week I've been on samba.org and searched the MARC mailing list
archives for discussions pertinent to our situation. My search for
"slow DOS client" produced over 100 hits dating back to the last
millennium, some of which were really about something else. Many of the
rest were descriptions of problems VERY similar to ours, including some
with the 3Com 3C905 card. This question appeared over and over again,
but following the list "threads" for a couple of hours revealed very
few
answers or ideas. Either nobody solved the problem, or nobody posted
the solution when they found it.
Exceptions were -
* A suggestion about matching full/half duplex settings.
* Corey McGuire's 11/02 MAXSENDSIZE suggestion, for which I
had high hopes.
* Someone mentioned that ftp file transfers from LANMAN to Samba were
faster on his system.
***********
The bigger picture and earlier activity -
My customer is migrating from Sun/Solaris/NFS to Linux at the receiving
end of an Ethernet Link, so at the sending end they need to drop Sun's
PC-NFS with its licensing and support issues. At present, the Sun
system and the combination of DOS, LANMAN, and PC-NFS is operating at an
acceptable speed (~1M bytes/sec) using "rcp" spawned from within the
DOS
application to copy files across the 100MBPS Ethernet link.
The embedded application (with custom) PCI hardware might be translated
to Linux someday, but for now it is necessarily DOS-based, using 32-bit
Watcom C and 64M of extended memory provided by DOS4GW and DOS/98
without Windows (yes, you can).
To eliminate PC-NFS, we decided to try Samba at the Linux end. I'm not
a network expert, but I've attempted each of the following at the DOS
end -
* Based on the words "recommended DOS client" on samba.org, I
downloaded
the MS floppy images for "MS Client 3.0 for DOS", but was unable to
get
it to recognize the driver/config (.INF) files on the install CD for the
3Com 3C905 NIC. Our D845EBG2L motherboard also has an Intel Ethernet
chip (Windows drivers say "Intel Pro/100 VE", possibly using the
82562ET), but my quick search of the install CD and Intel's web site
didn't locate DOS drivers for it.
* I then tried the same thing with LANMAN 2.2c from MS floppy images,
and got it to install with the NIC and TCP/IP drivers, but when booted
it recognizes the network and the Linux server (I can ping both ways),
but doesn't see the Samba service or the shared volume. The message is
something like "You have been logged on, but not validated by a server.
Therefore, you may not have permission to use network resources".
* A third party supplied us with boot files (apparently based on LANMAN
2.1), which I was able to install and adapt to our purpose. This boots
OK and recognizes Samba and the shared drive, but even with the NIC
forced to 100 MBPS it only copies files across at about 300K BITS per
second, almost two orders of magnitude too slow. Duty cycle on the
disk and Ethernet LED's is correspondingly low. The transfer tests were
done using "copy" from the DOS prompt, as I haven't located a
DOS/LANMAN
equivalent to "rcp" of PC-NFS. At least this tells us that the
Linux/Samba end is functioning, but something is artificially
restricting the data rate. I have NOT yet gone back to MS Client 3.0 or
LANMAN 2.2c to see if I could reconfigure them to work this well, and
this is the version I'm running at present.
* I am just starting to look at WatTCP (Watt-32) as a possibility, but
have no guarantee that it addresses the problem, and still would need
help with low-level drivers and configuration.
* In parallel, I looked for sources of DOS-based NFS drivers to
eliminate Samba and SMB, but didn't find anything which looked viable.
* I haven't tracked down whether we have "ftp" capability or how
it
works, so I'll start a search for that.
* We could also try making the DOS disk visible to the Linux system, and
see if initiating the transfers from that end helps.
**********
During my last session on the system, based on my samba.org list
search results, I tried the following -
* Copied the same test file from the Linux/Samba system to the DOS
system see if the speed was much higher, as described in the help lists
on samba.org. This direction only takes about a second for 2 Mbytes,
verifying this information.
* I looked at "\NET\TCPUTILS.INI" to see what the value of
MAXSENDSIZE,
and it was in fact set to 1024 as described on the web site. I then
looked at "/etc/samba/smb.conf" to see what the value of SO_RCVBUF
was,
and it was 8192 as described on the web site.
* Then I left MAXSENDSIZE at 1024 and changed SO_RCVBUF to 1024, since
it was declared that they must be the same for good performance. No
noticeable improvement (still about 40 seconds for 2 Mbytes).
* Next I tried setting MAXSENDSIZE and SO_RCV_BUF both to 2048,
supposedly the maximum acceptable value for the DOS end. No change.
* Then I ran the 3Com utility "3C905CFG.EXE" (after booting in another
configuration with more free memory). In addition to preserving the
100MBPS setting I previously forced, I also forced the 3Com board FLASH
to be set for "half duplex". No joy.
* Then I tried "full duplex", again with no change in speed.
The configuration was left at 2048 / 2048 / full duplex, which is my
guess at the "best" settings.
***********
There is simply no guarantee that any ONE parameter stands between us
and success - there may be many of them which have to be set correctly
for good performance. But testing all the combinations would be
prohibitive.
If there's someone out there who works with these old configurations
(embedded DOS?) on a regular basis, and has dealt with these issues, I
could use suggestions. Doing all this by trial and (mostly) error from
floppy disks has been very time-consuming, and we would be willing to
pay for experienced help, but it has to be someone who knows more than I
do about all this...
Thanks for reading (and caring?) about my troubles -
Cliff Tedder