This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Need help interpreting extra ACK package from Win 8 to SQL Server

0

Hi!

I've got a slightly duplicate of this post on http://social.technet.microsoft.com/Forums/windows/en-US/558553e7-d602-4584-a5dc-97f813890edc/extra-ack-packet-delaying-each-query-with-500-ms-on-windows-8, but I'm hoping some of you guys have some valuable input on this problem.

Thing is, my box with Win8 apparently sends an extra ACK package when I run SQL queries, and it seems like that package is creating a ~500 ms delay. Here's a short snippet of logs from my box and a Win 7 Box. (mine has multiboot and doesn't have the problem when booted with Win7)

Other box:

"20","0.286775000","10.29.84.125","172.18.166.116","TDS","116","SQL batch"
"21","0.311569000","172.18.166.116","10.29.84.125","TDS","480","Response"
-- 22 is ack for 21, no delay
"22","0.312462000","10.29.84.125","172.18.166.116","TDS","116","SQL batch"
"23","0.337217000","172.18.166.116","10.29.84.125","TDS","480","Response"

My box:

"19","2.949616000","10.29.84.127","172.18.166.116","TDS","116","SQL batch"
"20","2.974706000","172.18.166.116","10.29.84.127","TDS","480","Response"
"21","2.974793000","10.29.84.127","172.18.166.116","TCP","54","50457 > sslp [ACK] Seq=775 Ack=1955 Win=65792 Len=0"
-- 21 is ack for 20
-- 22 is not ack for 20, although ack bit is set
-- 500 ms delay before each new SQL batch 
"22","3.494747000","10.29.84.127","172.18.166.116","TDS","116","SQL batch"
"23","3.520266000","172.18.166.116","10.29.84.127","TDS","480","Response"
"24","3.520363000","10.29.84.127","172.18.166.116","TCP","54","50457 > sslp [ACK] Seq=837 Ack=2381 Win=65280 Len=0"

Hope someone has seen this before and know exactly what setting I can change or command I can run. ;)

[edit] Reason ACK packet is on SSLP instead of MS-SQL-S is that SQL Server in question runs on port 1750 instead of 1433. Same behavior on other servers though, so never mind it.

Lars-Erik

asked 22 Aug '13, 04:29

Lars-Erik's gravatar image

Lars-Erik
11●1●1●4
accept rate: 100%

edited 22 Aug '13, 05:18

2 Answers:

0

Purp identified.

It was Trend Micro Worry Free (!) Business Security.

Upgraded it, and problem gone.

Lars-Erik

answered 28 Aug '13, 02:52

Lars-Erik's gravatar image

Lars-Erik
11●1●1●4
accept rate: 100%

0

Hm, the packet that is sent out is just 62 bytes in length. So this may be the Nagle algorithm that is slowing you down here. This blog suggests to turn it off

"To disable TCP packet batching, we set TcpNoDelay to 1, so all packets will be send no matter what size they have (normally TCP sends out batched packages)."

answered 22 Aug '13, 04:58

mrEEde's gravatar image

mrEEde
3.9k●15●22●70
accept rate: 20%

Thanks, I've tried setting both TcpNoDelay and TcpAckFrequency to 1 and AckFreq to 2, neither has any effect what-so-ever.

Although I'm not entirely sure I put it in the right key. I used HKLM\SYSTEM\ControlSet001\Microsoft\Services\tcpip\Parameters\Interfaces\[the one that has my ip in a setting].

I'll try nodelay once more with a restart just to be sure I've tried properly.

[edit] Tried TcpNoDelay = 1 on all adapters for good measure, restart, no effect. :(

Lars-Erik

(22 Aug '13, 05:06) Lars-Erik