Ian,
I have found the bug and I am certain that the fix (sent in a minute)
resolves it entirely - making PATCH 4/5 unnecessary.
I am actually on Xmas leave and it takes me about an hour to get to work
and back, but since I caused this bug, I think it is worthwhile.
Detailed BUG Analysis
---------------------
1) When is which function called:
* update_send_time is called by
--update_x
--in nofeedback_timer, state NO_FBACK
--in tx_packet_recv, also state NO_FBACK
* update_x is called by
--nofeedback_timer, state FBACK
--tx_packet_recv, state FBACK
2) When is t_nom < t_now a problem
The scheduled send time t_nom is only of relevance in
ccid3_hc_tx_send_packet, where it is tested against t_now. In between
calls to ccid3_hc_tx_send_packet, it does not matter whether t_nom < t_now.
The real bug - and I thank you for pointing this out - is that when
delay = t_nom - tnow
is less than 0. In this case the packet is late, and t_nom is out of sync.
This is fixed by the patch and below I argue that no other changes are
required.
3) Why I am certain that the patch fixes the bug entirely
I applied this patch and used your patch which complains when t_nom < t_now
in update_send_time. I only got this condition in tx_packet_recv. Here,
however,
we are between calls to send_packet, and it is not necessary to set
t_nom=t_now,
since this will be done at the exact instant of sending the packet.
The same applies to calls to the nofeedback timer.
4) Further changes and comments by Eddie/Mark/Colin/Gorry
People have argued that evaluating the send time should not be necessary
in nofeedback_timer(). I think this is sound and eventually it would be
good to converge the send_packet interface towards this suggestion.
Since there are many other issues with CCID 3 at the moment, I would like
to postpone this until we have at least full 3448/4342 conformance; as an
icing on the CCake :-)
The idea is using `jiffies' instead of the expensive dccp_timestamp
(Andrea pointed out making this cheaper using clock=tsc, which also increases
accuracy). We could store the send time delta in the skb and just decrement
it -- until it is actually sent, the skb is blank and we could exploit
that to decrement a jiffie value.
Once again, many thanks for being so alert.
Gerrit
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
