| Ok, back to the old thread. I found out that commit after which dccp over
| loopback (no limiting) has huge delays (as reported previously) is
| 52515e77a7a69867c479db4c9efb6be832b82179. This is for CCID3 only no matter if
| client and server programs are run by root or not. dmesg shows:
| CCID: Registered CCID 3 (TCP-Friendly Rate Control)
| dccp_sample_rtt: unusable RTT sample -172, using min
| ccid3_hc_tx_packet_recv: client(cfb52740): ACK with bogus ACK-125773746264929
|
| Please feel free to ask for more info. Now I should have more time to test and
| make experiments.
Thanks. I need to first make a clarification with regard to earlier email: the
reported error ("err=1 after tx_packet_sent") has nothing to do with errno=EPERM.
That was my mistake, the `1' is generated by the device output routine,
which generates NET_XMIT_DROP when the Qdisc decides not to send the
packet (linux/netdevice.h).
Now to the bugs: the original error message was "crash on loopback", the
above is a different condition, so one after the other.
Firstly, irrespective of whether loopback is a representative environment or not,
if a crash happens on loopback then it must be fixed. Since your email I have heard
(privately) from at least one person who also encountered a crash on loopback. I do
occasional tests on loopback, but use two or three computers to do the
real testing. So far I have been unable to reproduce the bug and hence
any further information would be great.
I looked up your previous email on
http://www.mail-archive.com/dccp@xxxxxxxxxxxxxxx/msg03129.html
and tried to guess what is happening with regard to "huge delays". If
the problem you are referring to is the same (i.e. CCID-3 switches to a
mode of sending 1 packet in 64 seconds), then the above error messages
are the consequence, but not the cause.
Hence can you please clarify whether CCID-3 is getting into the mode of
sending once per 64 seconds?
Now lastly, ranting about loopback: this link is not very
representative, it has an extremely small RTT, a large MTU and actually
is a kind of virtual interface. Hence it is possible to run into
problems due to the nature of the link, but not the CCID-3 module.
In particular, the following problems are likely:
* due to the small RTT, the nofeedback timer triggers very often,
quickly reducing the sending rate towards 1 in 64 seconds
* this is because the nofeedback timer is triggered every 4*RTT,
a loopback RTT is < 50 usec, so that would be ~200 usec
* to avoid this, there is a kernel configuration option of CCID-3
to set an upper bound for this.
Please let us know if that diagnosis matches the case.
Gerrit
--
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
