| > This is an update with regard to Wei's comments. I have re-synched | > | > git://eden-feed.erg.abdn.ac.uk/dccp_exp [subtree `dccp'] | > http://eden-feed.erg.abdn.ac.uk/cgi-bin/gitweb.cgi?p=dccp_exp.git;a=shortlog;h=dccp | > | > Also did some testing with a client that only supports CCID 2/3 talking to a client supporting | > CCID 2/3/4. They could still negotiate and settle for a common CCID. | Sorry the above includes the whole dccp test tree, over and above the feature negotiation. We have been waiting for Arnaldo and there was a phase where people sent comments about this patch set, so I had not prepared a second net-next-2.6 pull request for this patch set yet. If you want to revert this, I will prepare a net-next-2.6 clone with just the revised 37 patches from this set. Otherwise some parts (as below) need to be modified. | #if (HZ >= 500) | # define TFRC_T_DELTA USEC_PER_MSEC | #else | # define TFRC_T_DELTA (USEC_PER_SEC / (2 * HZ)) | #warning Coarse CONFIG_HZ resolution -- higher value recommended for TFRC. | #endif | | Don't warn about crap like this, instead convert the code over to hrtimers. | | This kernel being built, even with HZ=100, can do nanosecond timers on | my systems, but that's only if you would make proper use of them. | The present sk_timer implementation uses the algorithm from RFC 3448. I did not want to blindly port it to hrtimer since so far the following difficulties were in the way: * when using the algorithm from RFC 3448, 4.6 directly with hrtimers, a large burst of activity will result, especially on fast links; * I have doubts whether it will help: each time the precision is improved, more frantic high-frequency noise results in CCID-3: - at some time socket timestamps were suggested for better RTT measurement, it proved better to reduce the precision to taking timestamps within the DCCP module (smoother response and also includes slow receiver); - even with that, on Gigabit Ethernet zero-RTT samples still occur; - one of the above patches updates CCID-3 to track the sending rate X_recv with higher frequency. There seems to be not much benefit, when comparing the sender plots, the amount of high-frequency noise in X_recv has increased after increasing the frequency of updating; * some people have suggested to use a timerless algorithm instead which would just control the number of packets per time. This would require rewriting some of the infrastructure (with benefits), it would use hrtimers for measuring the time intervals. -- 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
