mail voor linux mailinglist - Performance measurements with the
Hi,
Quoted 5 lines
Ian McDonald wrote:
One note - when using CCID3 have you turned off ackvecs via the sysctl as that is really for CCID2... It's probably something we should do in the code actually.
Thanks for the tip, after disabling ackvecs CCID3 started working again, packet loss remains a problem though.
Quoted 2 lines
Packet loss has been implemented and is working for me. What is your test environment? I am using netem on a router between two boxes.
Im testing the implementation with a click router
(http://pdos.csail.mit.edu/click/) between two linux 2.6.17.1 systems. The click box introduces uniform packet loss according some configured percentage.
I'm using a simple client-server application (self-written) that dumps the tfrc_rx_info and the tfrc_tx_info structures and the tfrcrx_p/tfrctx_p fields remain zero for the entire test.
I did some quick reading in the source, and as far as I understand 'ccid3_hx_rx_packet_recv' gets called when a packet arrives at the receiver. It calls 'dccp_rx_hist_add_packet' to add the packet in a packet list sorted by its sequence number in descending order. The return value of 'dccp_rx_hist_add_packet' is stored in the 'ins' value, which is only non-zero when packet reordering is detected. After the next switch statement packet loss is detected and a new loss event rate is calculated, but to get that far the code has to get over the switch statement, which is only possible if 'ins' is not zero.
As such i think the code cannot detect packetloss, maybe at best packet loss caused by reordering.
Does anyone agree, or did I miss something ?
best regards,
Johannes
Re: mail voor linux mailinglist - Performance measurements with the latest version of the DCCP (CCID
Quoted 14 lines
I'm using a simple client-server application (self-written) that dumps the
tfrc_rx_infoand thetfrc_tx_infostructures and the tfrcrx_p/tfrctx_p fields remain zero for the entire test.I did some quick reading in the source, and as far as I understand '
ccid3_hx_rx_packet_recv' gets called when a packet arrives at the receiver. It calls 'dccp_rx_hist_add_packet' to add the packet in a packet list sorted by its sequence number in descending order. The return value of 'dccp_rx_hist_add_packet' is stored in the 'ins' value, which is only non-zero when packet reordering is detected. After the next switch statement packet loss is detected and a new loss event rate is calculated, but to get that far the code has to get over the switch statement, which is only possible if 'ins' is not zero.
Quoted 2 lines
As such i think the code cannot detect packetloss, maybe at best packet loss caused by reordering.
What do you mean packet loss caused by reordering? This is not TCP so we don't keep sending ACKs of latest sequence number in order to get a retransmit... Can you explain what you mean?
Quoted 3 lines
Does anyone agree, or did I miss something ?
I think you missed something.
As I read the code the only thing we are guilty of possibly is that we don't declare this as "unloss" when the packet arrives out of order. We check whether they are in the same loss event and we throw packets away out of history when we have more than 4 in the history so we can't change it from loss back to no loss. I'm not sure without further reading whether we should be storing more history - it would help but I can't find it quickly reading whether it is a requirement.
Ian
Signature · 7 lines
Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand