VMware Cloud Community
kungpow
Enthusiast
Enthusiast

VMware ESXi 5.5 U2 - TcpAckFrequency

Looks like there is a bug in VMware ESXi.

Exchange 2013 SP1 on win2k12 r2 on a physical server: no slow upload issue with Outlook.

Exchange 2013 SP1 on win2k12 r2 on VMware ESXi 5.5 U2: has slow upload issue with Outlook.

-tried E100E & VMXNET3 network adapters, doesn't fix the issue.

-only way to fix the slow upload issue is to modify the registry key TcpAckFrequency on the PC

How do I fix this in ESXi without modifying TcpAckFrequency in the registry on the PC?

Thanks

45 Replies
bbernsee
Contributor
Contributor

There are a lot of questions I'd ask to get to the bottom of this one.

Start with the basic things:

- make sure you don't have a duplex mismatch or port errors

- does a continuous ping show issues?

- see if any NIC settings such as TCP offload, or Interrupt moderation are different

- then check your routing and ARP table at any routers in between the client and server

- is TCPNoDelay set on your stack?

- make sure you aren't running into NIC teaming issues

- do you have any load balancers or firewalls in between the client and server?

- get a network trace and look at the pattern of the segments being sent and ack'd (I'd use Opnet App Expert - but I'm lucky enough to have that tool, wireshark works great too)

- check your segment size and make sure you're not running across and smaller MTU segments - specifically if one is a VPN.  If so - you might need to turn down the MTU or put in a tcp adjust MSS at a network device

Good luck in addressing this... 

fkoller
Contributor
Contributor

Have the same Problem as reported. Have different VMWare Environments - 5.0.0, 5.1 U1, 5.1 U2 and 5.5 U2 and also different AD Sites! 5.0.0 and 5.1 U1 will work fine with Exchange 2013 Sp1. But not so 5.1 U2 and 5.5 U2!

Already checked the mentioned points but do not help to solve the Problem. We also tired a virtual machine without Firewall in between - has the same problem.

We have an active call with Microsoft. They told us to set the TcpAckFrequency Parameter on the Client Interfaces. This will help, Outlook will work fast again. But on the older VMWare Environment we do not have to set the TcpAskFrequency and it will work fine. To conclude, it seems to be a problem with newer VMWare Versions.

Reply
0 Kudos
kungpow
Enthusiast
Enthusiast

fkoller, did VMware say when they will have a fix for it or why it is happening in ESXi?

Thanks

Reply
0 Kudos
fkoller
Contributor
Contributor

I just want to clearfy my Statement. We have a call with Microsoft and not yet with VMWare. According to our Exchange 2013 infrastructure, which runs on severeal VMWare Hosts with different VMWare Editions We got the assumption, that the reason has to do with newer VMWare Editions. We are doing some further tests to underpin this Statement.

Will come back to you.

Reply
0 Kudos
fkoller
Contributor
Contributor

As we installed the Exchange Server 2012 on a VMWare host 5.1.0 Build 1065491, Exchange and Outlook will work fast again! So the problem on Exchange 2013 with Windows 2012 R2 has definitly to do with VMWare edition, you install from.

We will do another test to see what happens, when moving the virtual server to newer hosts.

Will let you know.

Reply
0 Kudos
fkoller
Contributor
Contributor

Moved the virtual Machine to VMWare Host 5.5 U2, still working fine. As soon as the VMWare tools would be upgraded to the 5.5 U2 version, the performance issue will come back again!

Have to open a call with VMWare to find a solution for 5.5 U2. Has anybody done this already to get a work around or a patch?

Reply
0 Kudos
kungpow
Enthusiast
Enthusiast

fkoller wrote:

Have the same Problem as reported. Have different VMWare Environments - 5.0.0, 5.1 U1, 5.1 U2 and 5.5 U2 and also different AD Sites! 5.0.0 and 5.1 U1 will work fine with Exchange 2013 Sp1. But not so 5.1 U2 and 5.5 U2!

I just confirmed this as well. I am running ESXi 5.5 U2 and I downgraded VMware Tools from 5.5 U2 to 5.1 U1 on the Exchange 2013 guest OS and the TcpAckFrequency issue went away. Now I don't have to edit the registry for the TcpAckFrequency key on each PC.

To download an older version of VMware Tools:

http://packages.vmware.com/tools/esx/index.html

Reply
0 Kudos
tedsteenvoorden
Contributor
Contributor

Experiencing the same problem. Exchange 2013 on VMware and Outlook responses very slow. Setting the TcpAckFrequency did not solve the problems, but our clients are running on ESXi 5.1 U2 (VDI).

Did you open a VMware case and had any response?

Reply
0 Kudos
fkoller
Contributor
Contributor

We opened a case with HP Support Center on Tuesday, 14 of October (We have a VMWare Bundle bought by HP).

The technician already confirmed some problems with VMWare Tools Version 11. But he was not shure, if our symptoms would have the same source. He wanted to scan the knowledge base and come backup with more information. No further reaction up today.

Reply
0 Kudos
tedsteenvoorden
Contributor
Contributor

I'll open also a VMware case and post any results in this thread.

Are your Windows 7 clients physical machines or are they virtual?

Reply
0 Kudos
kungpow
Enthusiast
Enthusiast

tedsteenvoorden wrote:

Are your Windows 7 clients physical machines or are they virtual?

I tested the TcpAckFrequency registry key on both physical and virtual windows 7/8.1 machines and the TcpAckFrequency key fixes the issue.

A better way to fix the issue instead of adding the TcpAckFrequency registry key on each pc is to downgrade the VMware Tools on the Exchange 2013 server. I tested the issue after the downgrade on virtual machines XP, 7, and 8.1 and it fixes the problem as well.

Reply
0 Kudos
BradleyJohn
Contributor
Contributor

Hi folks,

We look to be experiencing a similar issue with 5.1 U2. Do you know if anyone has contacted VMWare support about this or have received or seen an official VMWare KB article about this issue?

I didn't find one when I searched.

Thank you,

Brad

Reply
0 Kudos
Rudy_van_Os
Contributor
Contributor

Did you check the installation of the vShield Drivers:

pastedImage_2.png

If this option is installed, please try to remove, reboot and test again. Do not forget to delete TcpAckFrequency on client-side and reboot.

For us this was the solution for the same issue.

Reply
0 Kudos
mikejroberts
Enthusiast
Enthusiast

Any word on whether or not this is resolved in the latest tools version?

Reply
0 Kudos
mikejroberts
Enthusiast
Enthusiast

I opened my own case to inquire about this issue before I deploy it to my environment.  As is typical, I didn't get much from support.  Here is what they said:

Thank you for contacting VMware technical support? My name is xxxx, and I will be working on your case.

It appears as though you would like some help making sure to avoid any known issues before your upgrade to ESXi 5.5 Update 2. As far as that communities thread is concerned, there is no known issue regarding TcpAckFrequency and VMware Tools 5.5 Update 2.


As you can see, just posting to the community may not speed up a resolution.  You are likely going to have to open a case.  I appreciate your posting since I have already been burned by a couple other bugs - you may have saved me a lot of pain.

Thanks!

Reply
0 Kudos
JBHorne
Contributor
Contributor

Following -- same issue on our end.

EDIT: By the way, this issue does not affect Windows 8/8.1 clients. Only if the client is running Windows 7 does the issue occur (both with Outlook 2010 and 2013).

I've compiled several other threads on TechNet forums for the same issue:

And a few Microsoft KB articles relating to the TcpAckFrequency setting – but none related directly to Outlook/Exchange:

Reply
0 Kudos
LaurenceO
Contributor
Contributor

Hi Guys,

I have the same problem... We are running ESXi 5.1.0 build 799733 with W2k12, exchange 2013. Clients running w2k12 in virtual with outlook 2013 (online mode).

Have added the TCP Ack reg hack which has helped but still getting "not responding" in outlook.

Any Idea's?

Laurence

Reply
0 Kudos
BradleyJohn
Contributor
Contributor

Hi,

I forgot to update everyone: our issue was resolved by disabling Nagle’s Algorithm on our F5 BigIP Load Balancer.

All the best.

Reply
0 Kudos
nettech1
Expert
Expert

Windows 8 clients are affected, but not as bad as Windows 7 clients are.  If you check your Outlook average response time from a Windows 8 system without TcpAckFrequency, you are going to see number over 50, but once the TcpAckFrequency change is applied your average response drops to 10-15 which is where it should be on the LAN.

Windows 7 has a delay ack time out set to 200ms

Windows 8 is most likely 50ms

Reply
0 Kudos