1. 11 10月, 2007 9 次提交
  2. 19 7月, 2007 1 次提交
  3. 11 7月, 2007 1 次提交
  4. 09 5月, 2007 1 次提交
  5. 30 4月, 2007 1 次提交
  6. 29 4月, 2007 1 次提交
  7. 26 4月, 2007 8 次提交
  8. 10 4月, 2007 1 次提交
    • D
      [TCP]: slow_start_after_idle should influence cwnd validation too · 15d33c07
      David S. Miller 提交于
      For the cases that slow_start_after_idle are meant to deal
      with, it is almost a certainty that the congestion window
      tests will think the connection is application limited and
      we'll thus decrease the cwnd there too.  This defeats the
      whole point of setting slow_start_after_idle to zero.
      
      So test it there too.
      
      We do not cancel out the entire tcp_cwnd_validate() function
      so that if the sysctl is changed we still have the validation
      state maintained.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      15d33c07
  9. 03 4月, 2007 1 次提交
  10. 14 2月, 2007 1 次提交
    • I
      [TCP]: Prevent pseudo garbage in SYN's advertized window · 600ff0c2
      Ilpo Järvinen 提交于
      TCP may advertize up to 16-bits window in SYN packets (no window
      scaling allowed). At the same time, TCP may have rcv_wnd
      (32-bits) that does not fit to 16-bits without window scaling
      resulting in pseudo garbage into advertized window from the
      low-order bits of rcv_wnd. This can happen at least when
      mss <= (1<<wscale) (see tcp_select_initial_window). This patch
      fixes the handling of SYN advertized windows (compile tested
      only).
      
      In worst case (which is unlikely to occur though), the receiver
      advertized window could be just couple of bytes. I'm not sure
      that such situation would be handled very well at all by the
      receiver!? Fortunately, the situation normalizes after the
      first non-SYN ACK is received because it has the correct,
      scaled window.
      
      Alternatively, tcp_select_initial_window could be changed to
      prevent too large rcv_wnd in the first place.
      
      [ tcp_make_synack() has the same bug, and I've added a fix for
        that to this patch -DaveM ]
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      600ff0c2
  11. 11 2月, 2007 1 次提交
  12. 09 2月, 2007 1 次提交
  13. 26 1月, 2007 1 次提交
  14. 24 1月, 2007 1 次提交
  15. 03 12月, 2006 3 次提交
  16. 19 10月, 2006 1 次提交
    • J
      [TCP]: Bound TSO defer time · ae8064ac
      John Heffner 提交于
      This patch limits the amount of time you will defer sending a TSO segment
      to less than two clock ticks, or the time between two acks, whichever is
      longer.
      
      On slow links, deferring causes significant bursts.  See attached plots,
      which show RTT through a 1 Mbps link with a 100 ms RTT and ~100 ms queue
      for (a) non-TSO, (b) currnet TSO, and (c) patched TSO.  This burstiness
      causes significant jitter, tends to overflow queues early (bad for short
      queues), and makes delay-based congestion control more difficult.
      
      Deferring by a couple clock ticks I believe will have a relatively small
      impact on performance.
      Signed-off-by: NJohn Heffner <jheffner@psc.edu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ae8064ac
  17. 12 10月, 2006 1 次提交
  18. 29 9月, 2006 1 次提交
  19. 23 9月, 2006 2 次提交
  20. 23 8月, 2006 1 次提交
  21. 08 8月, 2006 1 次提交
  22. 01 7月, 2006 1 次提交