diff options
author | Gerrit Renker <gerrit@erg.abdn.ac.uk> | 2006-12-03 14:53:07 -0200 |
---|---|---|
committer | Arnaldo Carvalho de Melo <acme@mandriva.com> | 2006-12-03 14:53:07 -0200 |
commit | 44158306d756c88272c8faf243ca68897498e219 (patch) | |
tree | b5406da158950a099336a67c507a0dd55c04fa25 /arch/ia64 | |
parent | 006042d7e1a0aae35c9dd9eb8ec71fa379679adb (diff) | |
download | linux-44158306d756c88272c8faf243ca68897498e219.tar.bz2 |
[DCCP] ccid3: Deprecate TFRC_SMALLEST_P
This patch deprecates the existing use of an arbitrary value TFRC_SMALLEST_P
for low-threshold values of p. This avoids masking low-resolution errors.
Instead, the code now checks against real boundaries (implemented by preceding
patch) and provides warnings whenever a real value falls below the threshold.
If such messages are observed, it is a better solution to take this as an
indication that the lookup table needs to be re-engineered.
Changelog:
----------
This patch
* makes handling all TFRC resolution errors local to the TFRC library
* removes unnecessary test whether X_calc is 'infinity' due to p==0 -- this
condition is already caught by tfrc_calc_x()
* removes setting ccid3hctx_p = TFRC_SMALLEST_P in ccid3_hc_tx_packet_recv
since this is now done by the TFRC library
* updates BUG_ON test in ccid3_hc_tx_no_feedback_timer to take into account
that p now is either 0 (and then X_calc is irrelevant), or it is > 0; since
the handling of TFRC_SMALLEST_P is now taken care of in the tfrc library
Justification:
--------------
The TFRC code uses a lookup table which has a bounded resolution.
The lowest possible value of the loss event rate `p' which can be
resolved is currently 0.0001. Substituting this lower threshold for
p when p is less than 0.0001 results in a huge, exponentially-growing
error. The error can be computed by the following formula:
(f(0.0001) - f(p))/f(p) * 100 for p < 0.0001
Currently the solution is to use an (arbitrary) value
TFRC_SMALLEST_P = 40 * 1E-6 = 0.00004
and to consider all values below this value as `virtually zero'. Due to
the exponentially growing resolution error, this is not a good idea, since
it hides the fact that the table can not resolve practically occurring cases.
Already at p == TFRC_SMALLEST_P, the error is as high as 58.19%!
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Diffstat (limited to 'arch/ia64')
0 files changed, 0 insertions, 0 deletions