Hi there
I have encountered a frustrating problem when running samba 2.0.5a. The
setup has samba 2.0.5a running under Linux 2.2.13 (Slackware 7). This is
set up to provide access to users' home directories using the
"homes" share.
A DOS box running MSClient 3.0 is set up to mount a user's home directory as
f: drive using the "net use" command from the command line. The PC is
doing
realtime data acquisition so apart from RT Linux (which would require a
rewrite of the existing codebase for which there is no time at present) DOS
is the only real choice we have. Data acquired by the DOS-based program is
written to the share so another PC can carry out analysis on the data.
The two boxes are networked using two Netgear FA310TX 100MB cards and are
directly connected using a crossed cable. The Linux end is driven by the
tuplip driver while DOS is using the supplied NDIS2 driver under MSClient
3.0. The Linux end of the link reports no errors on transmission or
reception over an extended (>3 day) period.
The software has been configured and allows the sharing to occur. The
problem is the write speed from DOS to the samba-provided share - I am
seeing 64KB/s (kbytes/sec) maximum, even though the link is 100MB.
Rudementary tests with large ping packets conservatively indicate a link
speed of 20-60Mbits/sec, and the DOS box can *read* from the samba share at
a rate of at least 50Mbits/sec. However, as mentioned this drops to the
order of 0.7Mbits/sec when writing from DOS. This happens regardless of
whether the link is operated at 10Mbps or 100Mbps, in full or half duplex.
I have tried many different configuration settings on both the samba and DOS
ends. These include the suggestions made in the various samba faqs and
documentation; none of these seeem to give any major difference. (It should
be noted that MSClient has a very abbreviated set of configurable options
compared to even wfw 3.11 as far as I can tell.)
My question is this: should a DOS client be able to write faster than this,
or is this a case of the DOS software being heavily optimized for reading
at the expense of write speed? If it is possible to go faster than this,
do you have any other suggestions as to what I can try?
Please CC me any replies as I am not currently subscribed to this list.
Thanks
jonathan
--
* Jonathan Woithe jwoithe@physics.adelaide.edu.au *
* http://www.physics.adelaide.edu.au/~jwoithe/home.html *
***-----------------------------------------------------------------------***
** "Time is an illusion; lunchtime doubly so"
**
* "...you wouldn't recognize a subtle plan if it painted itself purple
*
* and danced naked on a harpsicord singing 'subtle plans are here
again'" *
