1. 04 12月, 2006 3 次提交
    • G
      [DCCP] ccid3: Fix bug in calculation of send rate · 5c3fbb6a
      Gerrit Renker 提交于
      The main object of this patch is the following bug:
       ==> In ccid3_hc_tx_packet_recv, the parameters p and X_recv were updated
           _after_ the send rate was calculated. This is clearly an error and is
           resolved by re-ordering statements.
      
      In addition,
        * r_sample is converted from u32 to long to check whether the time difference
          was negative (it would otherwise be converted to a large u32 value)
        * protection against RTT=0 (this is possible) is provided in a further patch
        * t_elapsed is also converted to long, to match the type of r_sample
        * adds a a more debugging information regarding current send rates
        * various trivial comment/documentation updates
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>
      5c3fbb6a
    • G
      [DCCP]: Fix BUG in retransmission delay calculation · 76d12777
      Gerrit Renker 提交于
      This bug resulted in ccid3_hc_tx_send_packet returning negative
      delay values, which in turn triggered silently dequeueing packets in
      dccp_write_xmit. As a result, only a few out of the submitted packets made
      it at all onto the network.  Occasionally, when dccp_wait_for_ccid was
      involved, this also triggered a bug warning since ccid3_hc_tx_send_packet
      returned a negative value (which in reality was a negative delay value).
      
      The cause for this bug lies in the comparison
      
       if (delay >= hctx->ccid3hctx_delta)
      	return delay / 1000L;
      
      The type of `delay' is `long', that of ccid3hctx_delta is `u32'. When comparing
      negative long values against u32 values, the test returned `true' whenever delay
      was smaller than 0 (meaning the packet was overdue to send).
      
      The fix is by casting, subtracting, and then testing the difference with
      regard to 0.
      
      This has been tested and shown to work.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>
      76d12777
    • G
      [DCCP]: Use higher RTO default for CCID3 · 8a508ac2
      Gerrit Renker 提交于
      The TFRC nofeedback timer normally expires after the maximum of 4
      RTTs and twice the current send interval (RFC 3448, 4.3). On LANs
      with a small RTT this can mean a high processing load and reduced
      performance, since then the nofeedback timer is triggered very
      frequently.
      
      This patch provides a configuration option to set the bound for the
      nofeedback timer, using as default 100 milliseconds.
      
      By setting the configuration option to 0, strict RFC 3448 behaviour
      can be enforced for the nofeedback timer.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>
      8a508ac2
  2. 03 12月, 2006 37 次提交