Hi Eddie,
Sorry for the delay in responding.
| What follows is a first cut at a solution. Any thoughts from others??
|
| If t_ipi is used to schedule transmissions, then the following equation
should
| be applied each time the application is scheduled:
|
| t_ipi := max(t_ipi, t_now
Hi
In linux-2.6.20 and linux-2.6.21-pre1, the kernel oops shown below is
repeatably triggered by paraslash's [1] dccp sender (which is based
on Ian McDonald's dccp-cs-0.01.tar.bz2).
git-bisect pointed out
bf58a381e8106fe73247c753e3da58fcb5eabd2e
[DCCP]: Only deliver to the CCID
Hi Andre,
thank you for providing a detailed report.
The mentioned patch avoids sending received information to both rx/tx halves
of a CCID. There are two possibilities:
(a) The patch itself has a bug
The patch has been tested extensively over months (but using mainly
CCID3, as CCID2 g
On 16:42, Gerrit Renker wrote:
> I would much rather hunt down this bug than revert this patch, since
> reverting it
> means that almost twice the work is done per each packet and truly
> bidirectional
> connections are not currently supported.
Agreed. Let's try to find the bug.
> With initial
On 1/23/07, Gerrit Renker <[EMAIL PROTECTED]> wrote:
I have performed experiments which confirm that
1) when t_ipi < t_gran, the transmit rate is effectively out of control
2) when t_ipi > t_gran, the actual transmit rate is about a factor of 3
higher than s/t_ipi would permit.
http://www
5 matches
Mail list logo
