> Thanks for making it clear. This may be one of the reasons why I still > see 0.1% test failure at 2x standard deviation. The expected number > of packet per interface can be as low as 64. Another reason I find to > be the variations in hash value computed from packet. > > Should we simply do "random_uin32() % #slaves", instead of > hmap_random_node(), so that we can avoid your 2nd case?
it sounds like an improvement, yes. (if there's a handy array of slaves.) YAMAMOTO Takashi > > On Wed, May 7, 2014 at 8:07 PM, YAMAMOTO Takashi <yamam...@valinux.co.jp> > wrote: >>> On Wed, May 7, 2014 at 7:01 PM, YAMAMOTO Takashi <yamam...@valinux.co.jp> >>> wrote: >>>>> Sorry I was not clear in the commit message. It is the average of the >>>>> first interface. I will make it clear before pushing. >>>> >>>> thanks for clarification. >>>> i think the average is not so important. hash colision is. >>>> the worst case is, two interfaces in the same bucket, one in the other. >>>> in that case, packet distribution would be 1:1:2. >>> Would you please explain more? How did you arrive at this >>> distribution? Why is this the worst case? >> >> see hmap_random_node. >> >> given the number of items is 3, there are a few possible cases: >> - a bucket has all 3 items. >> - a bucket has 2 items, and another bucket has 1 item. >> - 3 buckets, each has 1 item. >> >> for the first and last cases distribution would be 1:1:1. >> >> for the 2nd case, each bucket would have the same chance to be selected. >> >> YAMAMOTO Takashi >> >>>> your value is safe enough for the distribution. >>>> >>>> YAMAMOTO Takashi >>>> >>>>> >>>>> On Wed, May 7, 2014 at 6:18 PM, YAMAMOTO Takashi <yamam...@valinux.co.jp> >>>>> wrote: >>>>>>> Raise the minimal per interface packet distribution from 7 to 24. >>>>>>> >>>>>>> With 256 packet distributing to 3 interfaces, the expected packets per >>>>>>> interface should be 256/3 = 85.3 >>>>>>> >>>>>>> Tested with 200 runs, the average number of packet per interface is >>>>>>> 85.9. close to the expected number, standard deviation within the 200 >>>>>>> run is 24.4. Tested with 2x standard deviation with 10K test runs, >>>>>>> got around 0.1% failure rate. 2.5x standard deviation passes 100K test >>>>>>> runs without failure. >>>>>>> >>>>>>> Using 2.5x for the unit test, 83.5 - 2.5 * 24.4, Round down to the >>>>>>> whole number of 24. >>>>>> >>>>>> the patch itself looks ok (thus acked-by) but i have a question on >>>>>> the commit message. >>>>>> why can the average number be larger than the expected number? >>>>>> the total number of packets for a run is expected to be exactly 256, >>>>>> isn't it? >>>>>> >>>>>> Acked-by: YAMAMOTO Takashi <yamam...@valinux.co.jp> >>>>>> Tested-by: YAMAMOTO Takashi <yamam...@valinux.co.jp> >>>>>> >>>>>> YAMAMOTO Takashi >>>>>> >>>>>>> >>>>>>> Signed-off-by: Andy Zhou <az...@nicira.com> >>>>>>> --- >>>>>>> tests/ofproto-dpif.at | 6 +++--- >>>>>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>>>>> >>>>>>> diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at >>>>>>> index c46e997..3723459 100644 >>>>>>> --- a/tests/ofproto-dpif.at >>>>>>> +++ b/tests/ofproto-dpif.at >>>>>>> @@ -191,9 +191,9 @@ AT_CHECK([ovs-appctl dpif/dump-flows br0 |grep tcp >>>>>>> > br0_flows.txt]) >>>>>>> AT_CHECK([ovs-appctl dpif/dump-flows br1 |grep tcp > br1_flows.txt]) >>>>>>> # Make sure there is resonable distribution to all three ports. >>>>>>> # We don't want to make this check precise, in case hash function >>>>>>> changes. >>>>>>> -AT_CHECK([test `grep in_port.4 br1_flows.txt |wc -l` -gt 7]) >>>>>>> -AT_CHECK([test `grep in_port.5 br1_flows.txt |wc -l` -gt 7]) >>>>>>> -AT_CHECK([test `grep in_port.6 br1_flows.txt |wc -l` -gt 7]) >>>>>>> +AT_CHECK([test `grep in_port.4 br1_flows.txt |wc -l` -gt 24]) >>>>>>> +AT_CHECK([test `grep in_port.5 br1_flows.txt |wc -l` -gt 24]) >>>>>>> +AT_CHECK([test `grep in_port.6 br1_flows.txt |wc -l` -gt 24]) >>>>>>> OVS_VSWITCHD_STOP() >>>>>>> AT_CLEANUP >>>>>>> >>>>>>> -- >>>>>>> 1.9.1 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> dev mailing list >>>>>>> dev@openvswitch.org >>>>>>> http://openvswitch.org/mailman/listinfo/dev >>>>> _______________________________________________ >>>>> dev mailing list >>>>> dev@openvswitch.org >>>>> http://openvswitch.org/mailman/listinfo/dev >>> _______________________________________________ >>> dev mailing list >>> dev@openvswitch.org >>> http://openvswitch.org/mailman/listinfo/dev > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
