[AccessD] OT: Network speeds

jwcolby jwcolby at colbyconsulting.com
Sun Mar 18 11:37:15 CDT 2012


Jim,

I am reading through that thread as it seems somewhat helpful.

John W. Colby
Colby Consulting

Reality is what refuses to go away
when you do not believe in it

On 3/18/2012 12:21 PM, Jim Lawrence wrote:
> Hi John:
>
> I just dug this out of the link you sent. There are three posts being
> combined but I think thye make it clear the solution they found:
>
> " The problem seems to be that the one or both servers are auto negotiating
> proper GB speed.  The way large data is handled between the two platforms
> may have also changed somewhat and cards drivers are not setting proper
> spped. Focus on the network cards in each server.  Go to the Network card
> properties of the card and select the configure button. Select the Advanced
> TAB and scroll through the options and look for LINK SPEED and DUPLEX,
> select Auto-negotiate 1000BPS.  There may also be a choice auto-negotiate
> without the 1000BPS - this won't or may not work and that is the problem.
> Once we make this change we see the server transfer speed run properly.
>
> This fixed it for me but you said you already tried that.  Try going into
> the network adapter driver properties and DISABLE "TCP Connection Offload
> (IPv4)".  This is generally listed on the advanced tab of the network
> adapter.
>
> I have a fix that worked which worked perfectly. I have an HP ML 350 G6
> server that was newly installed today and experience the same problem. I
> noticed that the HP software was not installed as I would have expected on
> older servers/oses. I downloaded the latest PSP from the HP drivers and
> downloads, installed it as a proliant server should and voila - the NIC and
> network worked exactly as it should.
> Before:
> Win 2003 SBS server to Win 2008 Enterprise w SP2 32bit --
>   was about 2 minutes for a 22MB folder
> After:
> Now it is literally 1 second !!!
> No tweaking needed - just installed and configured the HP Proliant software
> to SPEC !!"
>
> How this solves your problem.
> Jim
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
> Sent: Sunday, March 18, 2012 5:22 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] OT: Network speeds
>
> Yep.  There is a switch at either end (behind the servers) and a switch in
> the middle.  But is the a
> switch the issue at all?  I am reading a ton of "Windows 2008 R2 to anything
> transfer speed sucks"
> stuff out on Google.
>
> For example:
>
> http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2general/
> thread/2e14aa58-cb9b-462c-8a9e-7b10be2de3cb/
>
> The servers at both end are Windows 2008 R2.  It looks like my work is cut
> out for me.
>
> John W. Colby
> Colby Consulting
>
> Reality is what refuses to go away
> when you do not believe in it
>
> On 3/17/2012 11:40 PM, Stuart McLachlan wrote:
>> There are all sorts of possibilities there. What sort of rates do you get:
>>
>> 1. Through Switch 1 alone between SQL Server (computer) Win 2008 x64 and
> Unraid file
>> server (computer)
>>
>> 2. Through Switches 1 and 2 between SQL Server (computer) Win 2008 x64 and
> Living room
>> public PC (computer)
>>
>> 3. Through Switches 1 and 2 between Unraid file server (computer) and
> Living room public
>> PC (computer)
>>
>> 4. Through Switches 2 and 3 between Living room public PC (computer) and
> VM Server (computer) Win 2008 X46
>>
>> 5. 4. Through Switches 2 and 3 between Living room public PC (computer)
> and  Dev
>> workstation laptop (computer)
>>
>> 6. Through Switches 1,2 and 3 between  Unraid file server (computer) and
> VM Server
>> (computer) Win 2008 X46
>>
>> 7. Through Switches 1,2 and 3 between  Unraid file server (computer) and
> Dev workstation
>> laptop (computer)
>>
>> 7. Through Switches 1,2 and 3 between  SQL Server (computer) Win 2008 x64
> and Dev
>> workstation laptop (computer)
>>
>> (I think that covers all the combinations!)
>>
>> An analysis of those results should tell you where the bottleneck is.
>>
>



More information about the AccessD mailing list