2

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.

2
  • 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, 2011 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, 2011 at 7:44

2 Answers 2

2
+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.

2
  • 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, 2011 at 13:04
  • I disabled the QoS packet scheduler on the network adapter and that did the trick - Thanks!
    – rupello
    Jun 30, 2011 at 20:01
0

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?

2
  • 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, 2011 at 13:21
  • I was counting sequence numbers, might've mis-accounted for the H scale.
    – TristanK
    Jun 30, 2011 at 22:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .