Slow file-upload to share, 2003 server.

Investigating a problem of slow upload of files to a server share.

When downloading files to a client, or when using the server console to copy
files to or from another server, the LAN throughput is ~7MB/s which seems
about typical for a 100Mb/s link.

However, when uploading a file from a client to a server share, the
throughput is half that at best, and seems to suffer a further drop in speed
after perhaps 30sec or so of copying, to as low as 1-2MB/s. From then on the
speed fluctuates from 0.5MB/s to 3MB/s, and the total copy takes about 4-6
times as long as it should.

The client copies the same files to another (Debian) server at full speed,
so I think we can rule-out a client problem.

There are no processor-intensive tasks running, and during the copy the
utilization of both CPU and LAN are moderate. A disk-to-disk copy on the
server is >10x the LAN speed, which suggests it's not a disk throughput
problem.

I've tried:
Updating LAN driver.
A different LAN card, RTL8139.
Changing various LAN card parameters, including forcing 100 Duplex.
Changed the relative priority of services/applications.
No joy.

Seems to me it cannot be a LAN interface or IP problem anyway, as the server
can download AND upload files from/to its own console at full speed. It looks
more like a problem with the server process itself.

Any suggestions?

Seem to have solved it. There is evidently a problem with the onboard NIC or
its driver, and the problem only goes away if this is fully deactivated.
Using a second NIC with the onboard still active -as I first tried- the
problem still manifests, hence confusing result.

"Anteaus" wrote:

> Investigating a problem of slow upload of files to a server share.
>
> When downloading files to a client, or when using the server console to copy
> files to or from another server, the LAN throughput is ~7MB/s which seems
> about typical for a 100Mb/s link.
>
> However, when uploading a file from a client to a server share, the
> throughput is half that at best, and seems to suffer a further drop in speed
> after perhaps 30sec or so of copying, to as low as 1-2MB/s. From then on the
> speed fluctuates from 0.5MB/s to 3MB/s, and the total copy takes about 4-6
> times as long as it should.
>
> The client copies the same files to another (Debian) server at full speed,
> so I think we can rule-out a client problem.
>
> There are no processor-intensive tasks running, and during the copy the
> utilization of both CPU and LAN are moderate. A disk-to-disk copy on the
> server is >10x the LAN speed, which suggests it's not a disk throughput
> problem.
>
> I've tried:
> Updating LAN driver.
> A different LAN card, RTL8139.
> Changing various LAN card parameters, including forcing 100 Duplex.
> Changed the relative priority of services/applications.
> No joy.
>
> Seems to me it cannot be a LAN interface or IP problem anyway, as the server
> can download AND upload files from/to its own console at full speed. It looks
> more like a problem with the server process itself.
>
> Any suggestions?
>

"Anteaus" <(E-Mail Removed)> wrote in message
news:78AE0745-C902-4EC4-AA79-(E-Mail Removed)...
> Seem to have solved it. There is evidently a problem with the onboard NIC
> or
> its driver, and the problem only goes away if this is fully deactivated.
> Using a second NIC with the onboard still active -as I first tried- the
> problem still manifests, hence confusing result.
>
> "Anteaus" wrote:
>
>> Investigating a problem of slow upload of files to a server share.
>>
>> When downloading files to a client, or when using the server console to
>> copy
>> files to or from another server, the LAN throughput is ~7MB/s which seems
>> about typical for a 100Mb/s link.
>>
>> However, when uploading a file from a client to a server share, the
>> throughput is half that at best, and seems to suffer a further drop in
>> speed
>> after perhaps 30sec or so of copying, to as low as 1-2MB/s. From then on
>> the
>> speed fluctuates from 0.5MB/s to 3MB/s, and the total copy takes about
>> 4-6
>> times as long as it should.
>>
>> The client copies the same files to another (Debian) server at full
>> speed,
>> so I think we can rule-out a client problem.
>>
>> There are no processor-intensive tasks running, and during the copy the
>> utilization of both CPU and LAN are moderate. A disk-to-disk copy on the
>> server is >10x the LAN speed, which suggests it's not a disk throughput
>> problem.
>>
>> I've tried:
>> Updating LAN driver.
>> A different LAN card, RTL8139.
>> Changing various LAN card parameters, including forcing 100 Duplex.
>> Changed the relative priority of services/applications.
>> No joy.
>>
>> Seems to me it cannot be a LAN interface or IP problem anyway, as the
>> server
>> can download AND upload files from/to its own console at full speed. It
>> looks
>> more like a problem with the server process itself.
>>
>> Any suggestions?
>>


This may possibly be due to the TCP Chimney feature that is enabled by
default on 2003 SP2 and 2008. It relies on offloading TCP functions to the
NIC, however if the NIC doesn't support it, you will see various issues, one
of which you've described. Read the following for more info and see if it
applies.

TCP Chimney and RSS Features May Cause Slow File Transfers or Cause
Connectivity Problems
http://msmvps.com/blogs/acefekay/arc...-problems.aspx

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Please reply back to the newsgroup or forum for collaboration benefit among
responding engineers, and to help others benefit from your resolution.

Ace Fekay, MCT, MCTS 2008, MCTS Exchange, MCSE, MCSA 2003 & 2000, MCSA
Messaging
Microsoft Certified Trainer

For urgent issues, please contact Microsoft PSS directly. Please check
http://support.microsoft.com for regional support phone numbers.

I tried "Netsh int ip set chimney DISABLED" but it didn't seem to have any
effect on the problem. In any case the firewall is on so the chimney function
shouldn't be active.

Nevertheless this sounds very much like the sort of area where the trouble
might be.

Thanks.

"Ace Fekay [MCT]" wrote:

> "Anteaus" <(E-Mail Removed)> wrote in message
> news:78AE0745-C902-4EC4-AA79-(E-Mail Removed)...
> > Seem to have solved it. There is evidently a problem with the onboard NIC
> > or
> > its driver, and the problem only goes away if this is fully deactivated.
> > Using a second NIC with the onboard still active -as I first tried- the
> > problem still manifests, hence confusing result.
> >
> > "Anteaus" wrote:
> >
> >> Investigating a problem of slow upload of files to a server share.
> >>
> >> When downloading files to a client, or when using the server console to
> >> copy
> >> files to or from another server, the LAN throughput is ~7MB/s which seems
> >> about typical for a 100Mb/s link.
> >>
> >> However, when uploading a file from a client to a server share, the
> >> throughput is half that at best, and seems to suffer a further drop in
> >> speed
> >> after perhaps 30sec or so of copying, to as low as 1-2MB/s. From then on
> >> the
> >> speed fluctuates from 0.5MB/s to 3MB/s, and the total copy takes about
> >> 4-6
> >> times as long as it should.
> >>
> >> The client copies the same files to another (Debian) server at full
> >> speed,
> >> so I think we can rule-out a client problem.
> >>
> >> There are no processor-intensive tasks running, and during the copy the
> >> utilization of both CPU and LAN are moderate. A disk-to-disk copy on the
> >> server is >10x the LAN speed, which suggests it's not a disk throughput
> >> problem.
> >>
> >> I've tried:
> >> Updating LAN driver.
> >> A different LAN card, RTL8139.
> >> Changing various LAN card parameters, including forcing 100 Duplex.
> >> Changed the relative priority of services/applications.
> >> No joy.
> >>
> >> Seems to me it cannot be a LAN interface or IP problem anyway, as the
> >> server
> >> can download AND upload files from/to its own console at full speed. It
> >> looks
> >> more like a problem with the server process itself.
> >>
> >> Any suggestions?
> >>
>
>
> This may possibly be due to the TCP Chimney feature that is enabled by
> default on 2003 SP2 and 2008. It relies on offloading TCP functions to the
> NIC, however if the NIC doesn't support it, you will see various issues, one
> of which you've described. Read the following for more info and see if it
> applies.
>
> TCP Chimney and RSS Features May Cause Slow File Transfers or Cause
> Connectivity Problems
> http://msmvps.com/blogs/acefekay/arc...-problems.aspx
>
> --
> Ace
>
> This posting is provided "AS-IS" with no warranties or guarantees and
> confers no rights.
>
> Please reply back to the newsgroup or forum for collaboration benefit among
> responding engineers, and to help others benefit from your resolution.
>
> Ace Fekay, MCT, MCTS 2008, MCTS Exchange, MCSE, MCSA 2003 & 2000, MCSA
> Messaging
> Microsoft Certified Trainer
>
> For urgent issues, please contact Microsoft PSS directly. Please check
> http://support.microsoft.com for regional support phone numbers.
>
>
>

"Anteaus" <(E-Mail Removed)> wrote in message
news:FD701B8B-FC89-4F9E-B0CB-(E-Mail Removed)...
>
> I tried "Netsh int ip set chimney DISABLED" but it didn't seem to have any
> effect on the problem. In any case the firewall is on so the chimney
> function
> shouldn't be active.
>
> Nevertheless this sounds very much like the sort of area where the trouble
> might be.
>
> Thanks.


I wouldn't think the firewall wouldn't have anything to do with a
'slowdown.' Check the reg entries compared to the ones in the blog.

Ace

According to the blog, the chimney feature isn't used if the firewall is on,
which it is. Hence in principle it shouldn't cause trouble in this
configuration.

Anyway, after the various changes it's now much faster, though for some
reason not quite as fast as the Debian server. Think I'll accept that it's
now OK to deploy.

Thanks for help.

"Ace Fekay [MCT]" wrote:

> I wouldn't think the firewall wouldn't have anything to do with a
> 'slowdown.' Check the reg entries compared to the ones in the blog.

"Anteaus" <(E-Mail Removed)> wrote in message
news:0F765179-9596-4DC0-A785-(E-Mail Removed)...
> According to the blog, the chimney feature isn't used if the firewall is
> on,
> which it is. Hence in principle it shouldn't cause trouble in this
> configuration.
>
> Anyway, after the various changes it's now much faster, though for some
> reason not quite as fast as the Debian server. Think I'll accept that it's
> now OK to deploy.
>
> Thanks for help.
>
> "Ace Fekay [MCT]" wrote:
>
>> I wouldn't think the firewall wouldn't have anything to do with a
>> 'slowdown.' Check the reg entries compared to the ones in the blog.
>


True about the firewall and Chimney. I misquoted my own blog! :-)

I'm not sure how fast a Debian machine is, since I've never used one, but
good to hear the changes have beneficial effect.

Ace