an impossible situation - windows xp networking slowness

I seem to get the impossible ones. I've just bought an NF7/S-based
machine. This currently has the on-board nic, plus a £5 wonder nic I
bought as a spare, and I've been looking at network speeds. The
server is a Duron800/win98se, and no slouch as a file server (although
I see the same problems with another slower server); connections are
via a cheapish 100Mb switch (surecom ep808ax). I've timed various
copy operations from the server to the nf7 machine.

For large files, there's no problem. A 200Mbyte video file is read in
about 55 seconds (that's around 35Mbit/s) using either nic .

However, it's a different story copying a tree of smaller files (the
perl installation directory as it happens, about 45Mbytes of small to
middling files). Using the cheap nic card, this is read in about 80
seconds; around 10 to 20Mbit/s. But using the nf7 builtin nic, the
rate is disastrously low - it took around 3 minutes to copy less than
half the files, at which point I gave up - the data rate was around 1
to 2 Mbit/s.

The crazy part is that *dropping* the nf7 nic speed to 10Mb
*increases* the transfer speed - the 'perl transfer' took just 130sec
(at about 5Mbit/s, which is close to saturating a 10Mb link.).

I've played around a lot with tcp and udp client/server programs to
try to reproduce the problem at the lower level, but cannot reproduce
the slowdown at all.

I'm at a loss to tell whether this is hardware or software. I see no
reason xp should behave differently between the two nic's; yet the nf7
interface is fine for large files. Maybe xp doesn't like 98? - but
then why the speedup at 10Mb?

I'm at a loss now - having bought the machine over the net, it's a
non-trivial task to ship it back for further testing; and not clear
that that would even be productive.

Help, please!!!!!

--
Please use the corrected version of the address below for replies.
Replies to the header address will be junked, as will mail from
various domains listed at www.scottsonline.org.uk
regards. Mike Scott Harlow Essex England.(unet -a-t- scottsonline.org.uk)


Mike Scott

On Tue, 08 Jul 2003 14:53:02 +0100, Mike Scott
<(E-Mail Removed)> wrote:

>I seem to get the impossible ones. I've just bought an NF7/S-based
>machine. This currently has the on-board nic, plus a £5 wonder nic I
>bought as a spare, and I've been looking at network speeds. The
>server is a Duron800/win98se, and no slouch as a file server (although
>I see the same problems with another slower server); connections are
>via a cheapish 100Mb switch (surecom ep808ax). I've timed various
>copy operations from the server to the nf7 machine.
>
>For large files, there's no problem. A 200Mbyte video file is read in
>about 55 seconds (that's around 35Mbit/s) using either nic .
>
>However, it's a different story copying a tree of smaller files (the
>perl installation directory as it happens, about 45Mbytes of small to
>middling files). Using the cheap nic card, this is read in about 80
>seconds; around 10 to 20Mbit/s. But using the nf7 builtin nic, the
>rate is disastrously low - it took around 3 minutes to copy less than
>half the files, at which point I gave up - the data rate was around 1
>to 2 Mbit/s.
>
>The crazy part is that *dropping* the nf7 nic speed to 10Mb
>*increases* the transfer speed - the 'perl transfer' took just 130sec
>(at about 5Mbit/s, which is close to saturating a 10Mb link.).
....

For the record, and in case anyone else hits this:

The nic has a choice of optimize for throughput or for cpu usage. I
think when delivered it was set for least cpu usage; I seem to
remember early on changing it to "best throughput" -- it seemed a good
idea at the time: except someone seems to have labelled the options
the wrong way round! In desperation, I switched it to the optimise
for cpu setting - and the data rate rocketed a 100-fold. cpu usage
has sky-rocketed as well, and stands at around 20-25% when reading a
large number of files.

I had looked at tcpdump output, which showed some unexpected delays:
often after a SMBgetatr reply from the server, there would be a 200ms
delay before a tcp ack was sent, followed at once by another SMBgetatr
request to the server. I guess the delays all added up for small
files; but I don't know what's behind this effect.



keywords: nf7/s slow network file read nic low throughput

--
Please use the corrected version of the address below for replies.
Replies to the header address will be junked, as will mail from
various domains listed at www.scottsonline.org.uk
regards. Mike Scott Harlow Essex England.(unet -a-t- scottsonline.org.uk)

Hello,

You will find that all file transfers involving multple files will be slower
than if you were to transfer the same amount of data as one file. Try doing
a multiple (200+) file transfer directly from a CD to a remote machine -
faster to copy it to the local disk, tar/winzip all files into one file,
copy, then extract at other end.

If you really have a lot of files to move which addup to a lot of data, best
bet would be to group them - either using tar (unix) or perhaps winzip
(which will also reduce the size of data, unless we are talking binrary in
the first place!) before transfer.

I assume it is because when moving multiple files, each operation to get the
file, move the file, create the file on remote machine etc, are done for
every file.

Cheers,
Mike.



"Mike Scott" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Tue, 08 Jul 2003 14:53:02 +0100, Mike Scott
> <(E-Mail Removed)> wrote:
>
> >I seem to get the impossible ones. I've just bought an NF7/S-based
> >machine. This currently has the on-board nic, plus a £5 wonder nic I
> >bought as a spare, and I've been looking at network speeds. The
> >server is a Duron800/win98se, and no slouch as a file server (although
> >I see the same problems with another slower server); connections are
> >via a cheapish 100Mb switch (surecom ep808ax). I've timed various
> >copy operations from the server to the nf7 machine.
> >
> >For large files, there's no problem. A 200Mbyte video file is read in
> >about 55 seconds (that's around 35Mbit/s) using either nic .
> >
> >However, it's a different story copying a tree of smaller files (the
> >perl installation directory as it happens, about 45Mbytes of small to
> >middling files). Using the cheap nic card, this is read in about 80
> >seconds; around 10 to 20Mbit/s. But using the nf7 builtin nic, the
> >rate is disastrously low - it took around 3 minutes to copy less than
> >half the files, at which point I gave up - the data rate was around 1
> >to 2 Mbit/s.
> >
> >The crazy part is that *dropping* the nf7 nic speed to 10Mb
> >*increases* the transfer speed - the 'perl transfer' took just 130sec
> >(at about 5Mbit/s, which is close to saturating a 10Mb link.).
> ...
>
> For the record, and in case anyone else hits this:
>
> The nic has a choice of optimize for throughput or for cpu usage. I
> think when delivered it was set for least cpu usage; I seem to
> remember early on changing it to "best throughput" -- it seemed a good
> idea at the time: except someone seems to have labelled the options
> the wrong way round! In desperation, I switched it to the optimise
> for cpu setting - and the data rate rocketed a 100-fold. cpu usage
> has sky-rocketed as well, and stands at around 20-25% when reading a
> large number of files.
>
> I had looked at tcpdump output, which showed some unexpected delays:
> often after a SMBgetatr reply from the server, there would be a 200ms
> delay before a tcp ack was sent, followed at once by another SMBgetatr
> request to the server. I guess the delays all added up for small
> files; but I don't know what's behind this effect.
>
>
>
> keywords: nf7/s slow network file read nic low throughput
>
> --
> Please use the corrected version of the address below for replies.
> Replies to the header address will be junked, as will mail from
> various domains listed at www.scottsonline.org.uk
> regards. Mike Scott Harlow Essex England.(unet -a-t- scottsonline.org.uk)

On Thu, 10 Jul 2003 11:37:37 +0200, "Mike Dann"
<sod-off-(E-Mail Removed)> wrote:

>Hello,
>
>You will find that all file transfers involving multple files will be slower
>than if you were to transfer the same amount of data as one file.
....
Yes, but not normally by factors > 100.

This problem is definitely caused by selecting the 'max throughput'
driver option - I can turn it off and on at will by altering this
setting.

--
Please use the corrected version of the address below for replies.
Replies to the header address will be junked, as will mail from
various domains listed at www.scottsonline.org.uk
regards. Mike Scott Harlow Essex England.(unet -a-t- scottsonline.org.uk)

On Thu, 10 Jul 2003 15:34:36 GMT, BRG <(E-Mail Removed)> wrote:
....
>Could this be relevant?
>http://support.microsoft.com/default...b;en-us;315237

Not I think when connected to a switch rather than a hub. But it's
certainly an interesting article now bookmarked. Thanks.

--
Please use the corrected version of the address below for replies.
Replies to the header address will be junked, as will mail from
various domains listed at www.scottsonline.org.uk
regards. Mike Scott Harlow Essex England.(unet -a-t- scottsonline.org.uk)