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 -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba