On Sat, Dec 09, 2006 at 04:57:12PM +1300, Ian McDonald wrote:
On 12/9/06, Gerrit Renker [EMAIL PROTECTED] wrote:
[CCID3]: BUG-FIX - conversion errors
- u16 w_init = min(4 * hctx-ccid3hctx_s,
-max(2 * hctx-ccid3hctx_s, 4380));
+
Hi David,
Please consider pulling from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.git
Best Regards,
- Arnaldo
-
To unsubscribe from this list: send the line unsubscribe dccp in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
This patch follows a suggestion by Ian McDonald and ensures that in
the current code the value of p can not exceed 100%. Such a value is
illegal and would consequently cause a bug condition in tfrc_calc_x().
The receiver case is also tested, and a warning message is added.
Signed-off-by: Gerrit
This performs two optimisations for the recomputation of the sending rate.
1) Currently the target sending rate X_calc is recalculated whenever
a) the nofeedback timer expires, or
b) a feedback packet is received.
In the (a) case, recomputing X_calc is redundant, since
*
This simplifies the calculation of a value p for a given fval when the
first loss interval is computed (RFC 3448, 6.3.1). It makes use of the
two new functions scaled_div/scaled_div32 to provide overflow protection.
Additionally, protection against divide-by-zero is extended - in this
case
Problem:
Most target types in the CCID3 code are u32, so subtle conversion errors
can occur if signed time calculations yield negative results: the original
values are lost in the conversion to unsigned, calculation errors go
undetected.
This patch therefore
* sets all critical time
This adds a (debug) warning message which is triggered whenever a packet is
discarded due to send failure.
It also adds a conditional, so that an interruption during dccp_wait_for_ccid
is not treated as a `BUG': the rationale is that interruptions are external,
whereas bug warnings are concerned
The function ccid3_hc_tx_insert_options only does a redundant no-op,
as the operation
DCCP_SKB_CB(skb)-dccpd_ccval = hctx-ccid3hctx_last_win_count;
is already performed _unconditionally_ in ccid3_hc_tx_send_packet.
Since there is further no current need for this function, it is removed
In both the sender and the receiver it is possible that the stored
RTT value is accessed before an actual RTT estimate has been computed.
This patch
* initialises the sender RTT to 0
- the sender always accesses the RTT in ccid3_hc_tx_packet_sent
- the RTT is further needed for the
CCID3 performance depends much on the accuracy of RTT samples. If RTT
samples grow too large, performance can be catastrophically poor.
To limit the amount of possible damage in such cases, the patch
* introduces an upper limit which identifies a maximum `sane' RTT value;
* uses a macro to
This removes the `dccphtx_ccval' field since it is nowhere used in the code and
in fact not necessary for the accounting.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
Signed-off-by: Ian McDonald [EMAIL PROTECTED]
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
This migrates all packet history operations into the routine
ccid3_hc_tx_packet_sent, thereby removing synchronization problems
that occur when, as before, the operations are spread over multiple
routines.
The following minor simplifications are also applied:
* several simplifications now
No code change at all.
To make the header file easier to read, the following ordering is established
among the declarations:
* hist_new
* hist_delete
* hist_entry_new
* hist_head
* hist_find_entry
* hist_add_entry
* hist_entry_delete
You guys are using different types for r_sample in two different
functions, and then passing that to CCID3_RTT_SANITY_CHECK, which
uses %ld for the format string, but the second case uses
'suseconds_t' instead of 'long' as the type:
net/dccp/ccids/ccid3.c: In function
14 matches
Mail list logo