This might be the duplex mismatch thing. The Win9x drivers commonly
autonegotiate a half-duplex link (even when full-duplex would be possible
at the other end) and behave well enough. It is the NT and 2K NIC drivers
that often try to be what they are not, autonegotiate full-duplex but
really only running half. They report a collision and do the back-off
dance whenever the switch starts sending the NIC bits while it is trying
to transmit, even though it told the switch that's a fine thing to do.
Locking the NIC, and probably the switch port, down to half-duplex
commonly makes them go faster.
On Thu, 9 May 2002, Patrick (at work) wrote:
> I have noticed that w9x clients typically do not have a performance issue.
> I have noticed the same behavior with NT and 2k clients. I notice (on a win
> client) the transfer progress bar increase very quickly then stops, hangs
> for a moment (15 seconds or so) then increases again. Any ideas?
>
>
>
> ----- Original Message -----
> From: "Paul M Foster" <paulf@quillandmouse.com>
> To: <slug@nks.net>
> Sent: Thursday, May 09, 2002 2:15 AM
> Subject: Re: [SLUG] Slow SAMBA or what?
>
>
> > On Wed, May 08, 2002 at 10:16:28PM -0400, Chuck Hast wrote:
> >
> > > I have a LINUX machine that I also use as a SAMBA box. I went to pull a
> > > file over to a windows 2k machine from the SAMBA machine, the file is a
> > > 74m directory, I am pulling it over a 100mb 100baseT connection 20
> minutes
> > > seems a bit LONG for that path, do I need to tweek something in my SAMBA
> > > box? (I can't see anything to tweek in the windows box but then was
> there
> > > every anything TO tweek?)
> > >
> >
> > Seems a little long, but...
> >
> > 1) You're dealing with TCP/IP, which puts overhead on top of the bytes
> > you want to move. With 1500 byte packets, your overhead might be as much
> > as 15-25%, I think. Plus, each packet must be "peeled" at each level of
> > the protocol.
> >
> > 2) Since this is not the only thing your machine is doing, it must
> > interrupt the transfer periodically to take care of other programs and
> > housekeeping chores. That's true on both ends of the connection, since
> > it's not synchronous.
> >
> > 3) You've also got disk latency, which is a bottleneck in a lot of
> > operations; disk access is the slowest thing on a PC.
> >
> > 4) There may also be a problem with other traffic on the network. If
> > other machines are also using the pipe, each must wait its turn to
> > transfer bits.
> >
> > Anyway, this may not/probably doesn't explain it, but it's something to
> > consider when looking at how long a file transfer takes.
> >
> > I don't think Samba is the problem, though. As far as I know, there's
> > no "throttle" parameter on Samba. This sounds more like a link
> > layer/transport layer/hardware layer problem.
> >
> > Paul
> >
>
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 18:06:06 EDT