Re: [BUG] DCCP performance stops on CCID3 at times

[Gerrit Renker <gerrit@erg.abdn.ac.uk>]

Quoting Ian McDonald:
|  I'm still working on it but anybody else can feel free to help!
It is great to see that this is picked up. It is one of the items which I had put onto the ToDo list as well,
the thread starting this began on 
		http://www.mail-archive.com/dccp%40vger.kernel.org/msg00446.html


|  And now I get these subcases:
|  Nov  2 21:22:21 localhost kernel: [26564.665163] ccid3_hc_rx_calc_first_li: p = 0, fval = 7046
|  This is due to the computed x_recv being very, very low I believe. So it sets it to ~0
|  
|  Nov  2 21:22:21 localhost kernel: [26564.665381] dccp_li_hist_calc_i_mean: w_tot = 0
|  Nov  3 02:27:46 localhost kernel: [44880.646467] ccid3_hc_rx_calc_first_li: server, skÜ04b16c, Could not find a win_count interval > 0. Defaulting to 1
|  Nov  3 02:27:46 localhost kernel: [44880.646538] tmp2 = 0 ccid3_hc_rx_calc_first_li: x_recv = 0, rtt =1
I wonder whether this is due to the RTT, due to the following statement in ccid3_hc_rx_calc_first_li:
	if (rtt = 0)
		rtt = 1;
Maybe it would be good to print out when the RTT estimate is zero (with regard to the other email, I am still
puzzled about the Receiver-RTT measurement). The same statement re-appears in tfrc_calc_x (to avoid division-by-zero), 
without warning. 
I think that a warning message could bring in some light: maybe it is the case here that the RTT measurement is just
at rock bottom, always returns 0,  and thus always stays at 1. 


It would be great if you could come up with something, you know this code best. I have put it into my `TBD' folder
and may just pester with emails later ;-) 

There is another thread which I think may be of relevance, incidentally again at the rx_packet_recv function:

	http://www.mail-archive.com/dccp%40vger.kernel.org/msg00118.html

I put this also into the ToDo list, but I am still stuck with other work. Maybe we could kill all those ToDos in 
one swoop?

-- Gerrit