Re: [PATCH 8/8] [PATCH v2] [CCID3]: Interface CCID3 code with newer Loss Intervals Database
| When interfacing we must make sure that ccid3 tfrc_lh_slab is created | and then tfrc_li_cachep is not needed. I'm doing this while keeping | the structure of the patches, i.e. one introducing, the other removing. | But we need to create tfrc_lh_slab if we want the tree to be bisectable. | | I'm doing this and keeping your Signed-off-line, please holler if you | disagree for some reason. If you are just shifting and reordering then that is fine with me. But it seems you mean a different patch since in this one there is no slab initialisation. The loss history and the RX/TX packet history slabs are all created in tfrc.c using the three different __init routines of the dccp_tfrc_lib. - 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
CCID4 Tree Updated
This is to announce that the CCID4 tree at git://eden-feed.erg.abdn.ac.uk/dccp_exp [ccid4] has been updated with regard to the latest changes on the list. It compiles cleanly, also did some application-level testing (streaming). - 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
Re: [Announce]: Test results with latest CCID3 patch set
| I am new of this mailing list and I am really interested in the | measurements you are performing with DCCP. This was more of a regression test, as there had been recent changes in the test tree, to see that the kernel (not userspace) still performs in a predictable way. | Which tool are you using ? Are you using Iperf for such measurements ? The setup is the one from http://www.linux-foundation.org/en/Net:DCCP_Testing#Regression_testing and, yes, it uses iperf. | Have you ever heard about D-ITG ? | You can find more information here: | http://www.grid.unina.it/software/ITG | | I am one of the authors of such platform and I have also | performed some very preliminary tests with DCCP. | | I would be very glad to have your opinion on that and I'm very interested | in improving its features, also with specific regard to the support of | transport protocols. | It is a very nice tool with many features. I only ran simple tests with it (version 2.6), again only as basic sanity tests -- the throughput result was similar to the one tested with iperf. I think that the tool has more to offer and can help improve/extend DCCP testing. Here is my list of points, hoping that the others will add theirs, too: * would be good to have a standardised set of scripts, for comparison/benchmarking * the built-in VoIP module only works for UDP -- is it possible to port this to DCCP? * as per previous email, more complex traffic scenarios would be good, in particular - switching on/off background traffic at times to observe TCP/flow-friendliness - running multiple DCCP flows in parallel and at overlapping times 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
Re: [PATCH 8/8] [PATCH v2] [CCID3]: Interface CCID3 code with newer Loss Intervals Database
Em Tue, Dec 11, 2007 at 09:42:38AM +, Gerrit Renker escreveu: | When interfacing we must make sure that ccid3 tfrc_lh_slab is created | and then tfrc_li_cachep is not needed. I'm doing this while keeping | the structure of the patches, i.e. one introducing, the other removing. | But we need to create tfrc_lh_slab if we want the tree to be bisectable. | | I'm doing this and keeping your Signed-off-line, please holler if you | disagree for some reason. If you are just shifting and reordering then that is fine with me. But it seems you mean a different patch since in this one there is no slab initialisation. This time around I'm not doing any reordering, just trying to use your patches as is, but adding this patch as-is produces a kernel that will crash, no? The loss history and the RX/TX packet history slabs are all created in tfrc.c using the three different __init routines of the dccp_tfrc_lib. Yes, the init routines are called and in turn they create the slab caches, but up to the patch [PATCH 8/8] [PATCH v2] [CCID3]: Interface CCID3 code with newer Loss Intervals Database the new li slab is not being created, no? See what I'm talking? - Arnaldo - 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
Re: [Announce]: Test results with latest CCID3 patch set
Em Tue, Dec 11, 2007 at 02:21:28PM +, Gerrit Renker escreveu: | I am new of this mailing list and I am really interested in the | measurements you are performing with DCCP. This was more of a regression test, as there had been recent changes in the test tree, to see that the kernel (not userspace) still performs in a predictable way. | Which tool are you using ? Are you using Iperf for such measurements ? The setup is the one from http://www.linux-foundation.org/en/Net:DCCP_Testing#Regression_testing and, yes, it uses iperf. | Have you ever heard about D-ITG ? | You can find more information here: | http://www.grid.unina.it/software/ITG | | I am one of the authors of such platform and I have also | performed some very preliminary tests with DCCP. | | I would be very glad to have your opinion on that and I'm very interested | in improving its features, also with specific regard to the support of | transport protocols. | It is a very nice tool with many features. I only ran simple tests with it (version 2.6), again only as basic sanity tests -- the throughput result was similar to the one tested with iperf. I think that the tool has more to offer and can help improve/extend DCCP testing. Here is my list of points, hoping that the others will add theirs, too: * would be good to have a standardised set of scripts, for comparison/benchmarking * the built-in VoIP module only works for UDP -- is it possible to port this to DCCP? * as per previous email, more complex traffic scenarios would be good, in particular - switching on/off background traffic at times to observe TCP/flow-friendliness - running multiple DCCP flows in parallel and at overlapping times Does this tool records results in a database keyed by kernel version/buildid for us to use it as a regression tool? Something that would produce results around these lines: WARNING: test #23 counter #3 variance bigger than specified since the last kernel tested (git cset 55ed793afb4a8025d33a8e6a5f2f89d5ac4d8432)! - Arnaldo - 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
