Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am comparing Wireshark traces of a 10MB file download file from:

  1. the FileZilla FTP server and
  2. IIS (using HTTP) on the same Windows 2003 server.

The FTP download performs faster and the trace shows the server behaving as expected, sending more data to the client with every ACK received:

Section of FTP TCPTrace Link to full-size image

The HTTP server trace shows a more bursty pattern. The timing of the send bursts are sometimes unrelated to any ACKs received from the client (circled in red):

Section of HTTP TCPTrace Link to full-size image

Anyone have a suggestion as to why IIS traffic is having like this?

Update: We have tried modifying the http.sys registry settings (setting MaxBytesPerSend to 256k and MaxBufferedSendBytes to 64k as recommended). Changing MaxBytesPerSend does seem to improve performance by increasing the amount of in-flight data , but we still see the same bursty pattern.

share|improve this question
    
Disabling the Windows QoS Packet Scheduler as suggested by Fitz corrected the behavior on Windows Server 2008. However, I'm still seeing the same behavior on Windows Server 2003 (even with the QoS packet scheduler not installed). Does anyone know if there are similar QoS related settings that we could try altering on Windows Server 2003? –  user55674 Jul 13 '11 at 15:46
    
One thing I would suggest you try is to set the MaxBytesPerSend (http) and TcpWindowSize (tcpip) registry entries to be the same value (e.g. 0xfffff, which is the limit for maxbytespersend). I have been fiddling with these settings to try and fix a similar issue, and found that even if maxbytespersend is set to the maximum value, if its not aligned with the tcpwindowsize value you still see problems (in my case it would start out fast, then drop back to below what it was with the default settings). –  user93373 Sep 1 '11 at 7:44

2 Answers 2

up vote 2 down vote accepted
+50

I suspect it might be to do with the internal QoS admission control that happens within Windows. IIS might be honouring the QoS, FileZilla might be talking straight to the network.

share|improve this answer
    
This was referenced in Jim Getty's tech-talk on bufferbloat as a reason why Windows is not as prone to bufferbloat as Linux (youtube.com/watch?v=qbIozKVz73g) . I tried to find some Microsoft documentation on this subject but came up short. Do you have any refrences you can point me to? –  rupello Jun 30 '11 at 13:04
    
I disabled the QoS packet scheduler on the network adapter and that did the trick - Thanks! –  rupello Jun 30 '11 at 20:01

Could be SACKing. If I'm reading it right, HTTP is kicking the crap out of FTP transfer-speed-wise.

The client ACKs don't look particularly well-spaced either. What's the client?

share|improve this answer
    
Be careful looking at the charts as the scales are NOT the same! By my calculation the FTP is doing around 30Mbps and the HTTP around 20Mbps. There are no retransmissions that I can see in the file & the client was a curl download over broadband –  rupello Jun 30 '11 at 13:21
    
I was counting sequence numbers, might've mis-accounted for the H scale. –  TristanK Jun 30 '11 at 22:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.