發現通路公司某些業務時，速度非常不穩定，并且整體慢于競争對手。分析認為SESU10母盤上核心TCP擁塞控制算法和Windows的Ack頻率控制的政策存在不相容情況。
目前至少确認 2.6.16核心版本存在此問題，打TCP優化更新檔或者更換Tlinux以後可以解決問題。
在體驗網環境下測試：大檔案下載下傳的情況下，百度的下載下傳速度平均在600KBPS，我們的下載下傳速度平均低于100Kbps；互娛Webgame情況下，TNT業務下載下傳速度大約是DDT的25%。
這裡是一個典型的下載下傳速度曲線：
我們的伺服器的曲線：（縱軸機關：包/s）
百度的伺服器下載下傳的曲線：
重制該問題的測試環境：
網絡： 公司體驗網，普通聯通4M ADSL
伺服器：Linux64位伺服器, 深圳機房。
伺服器程式： Apache，nws（自研webserver）
用戶端： Windows XP， Windows7，任意浏覽器或者旋風（單線程下載下傳）
測試工具：wireshark， httpwatch
測試連接配接：分别是自建CDN、百度下載下傳、深圳DC+Apache
通過用戶端抓包分析發現速度很慢的段有兩個問題：
伺服器端總是等到前面的資料包确認以後才發送第二個包
Windows總是等到200ms左右才發送ACK确認。
對于Windows端的行為， 為了防止ACK過多導緻網絡壓力，Ms TCP協定棧在每收到一個資料包時，啟動一個200ms定時器，直到收到其他資料包或者定時器過期時才發送ACK包。
通過設定系統資料庫選項 TcpAckFrequency 參數為1關閉 Ack delay以後，實驗發現下載下傳速度恢複正常，無法重制下載下傳速度慢的問題。
<code>To configure the max outstanding ACKs in Windows XP/2003/Vista/2008:</code>
<code>[HKEYLOCALMACHINE \SYSTEM \CurrentControlSet \Services \Tcpip \Parameters \Interfaces \{Adapter-id}]</code>
<code>TcpAckFrequency = 1 (Default=2, 1=Disables delayed ACK, 2-n = If n outstanding ACKs before timed interval, sent ACK)</code>
因為無法強制使用者通過修改系統資料庫避免問題，并且競争對手也沒有看到類似問題，是以隻能從linux端解決。
Linux這一端，首先懷疑和nagle算法有關系，在nws伺服器上設定TCP_NODELAY以後仍然可以重制，可以排除Nagle算法的影響。 （實際上nws每次發送大資料包或者直接使用sendfile，不太會收到nagle算法影響） 其次Apache，nws都可以重制這個問題，比較懷疑作業系統本身有缺陷。
因為每次linux僅發送一個資料包，是以懷疑擁塞視窗的問題，推測問題如下：
初始情況下，用戶端回複一個ACK時，擁塞視窗增大，每次發送多個資料包，是以剛開始可以有較快的傳輸速度；因為網絡延時抖動或丢包導緻伺服器協定棧判定資料包逾時，重置擁塞視窗為1，每次僅發送一個資料包，收到用戶端200ms回包，時仍然認為逾時，同時調整RTT；直到RTT增大到200ms不算逾時為止，擁塞視窗得以擴大，可以發送多個資料包，傳輸速度增快，如此循環。
通過測試增大初始擁塞視窗為10 （更換核心加載架平新技術組的TCP優化子產品實作），下載下傳速度恢複正常。
附旋風測試選項：
The TCPIP nagle algorithm can slow down network
Design issues - Sending small data segments over TCP with Winsock