AW: [support] performance test on MIPv6

Sebastien Decugis sdecugis at hongo.wide.ad.jp
Fri Aug 22 18:06:55 JST 2008


No problem, it's good to know that it works well now :)

Best regards,
Sebastien.

Trinks, Marcus (K-EFFI) a écrit :
> Hi Sebastian,
> thanks a lot for your detail description. 
>
> When I run my tests again this morning I 
> could not expirienced the behaviour again.
> There was only a very little decrease and 
> data througput.
>
> Seems that I was to tired and made some mistake
> yesterday. I am sorry...
>
> cheers
>
> Marcus
>
> -----Ursprüngliche Nachricht-----
> Von: support-bounces at l2tp.nautilus6.org [mailto:support-bounces at l2tp.nautilus6.org] Im Auftrag von Sebastien Decugis
> Gesendet: Freitag, 22. August 2008 05:01
> An: Support ML
> Betreff: Re: [support] performance test on MIPv6
>
> Hello,
>
> This is an interesting measure, and also quite surprising. I have run a 
> few performance tests last year with MIPv6 and IKEv2, and the loss of 
> bandwith was not so important as far as I remember.
>
> Could you please monitor the CPU usage of the components of your testbed 
> (MNN, MR, HA, CN) while doing this test? I am thinking of a bug in iperf 
> with recent kernels (> 2.6.21) for example.
> Could you also capture some of the generated traffic in both situation 
> (with and without MIPv6 running) to find out if fragmentation could be 
> responsible for this?
> Are you using IPsec to protect the payload between MR and HA?
> I think it is also possible to retrieve some XFRM statistics that might 
> be useful through the /proc interface, but I am not familiar with 
> this... Maybe other people in this list can give more information?
>
> Last point, the loss may be perfectly normal, depending on the 
> performances of your HA and MR. The network path is different in your 
> two tests, as follow:
> Without MIPv6:   CN -------------------------------> MNN
> With MIPv6: CN -------------> HA ====(tunnel)=====>MR-------------> MNN
>
> In the first case, the HA and MR have only to forward the packets (I 
> suppose you CN is attached outside the MNN network), but in the second 
> case they have to encapsulate and decapsulate it, which is a far more 
> computational job.
> Also depending on where your CN and MR are located, you might be 
> generating a lot of collisions in some ethernet subnets if for example 
> CN is in the same subnet as MR.
>
> I hope this information will help you to understand what causes the 
> performance drop...
>
> Also Romain, I believe there is a known performance issue with the 
> tunnelctl that is used currently, but I don't remember if it will impact 
> only handovers or all processing of packets...
>
> Best regards,
> Sebastien.
>
> Trinks, Marcus (K-EFFI) a écrit :
>   
>>  
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Trinks, Marcus (K-EFFI) 
>> Gesendet: Donnerstag, 21. August 2008 09:49
>> An: 'support at ml.nautilus6.org.'
>> Betreff: performance test on MIPv6
>>
>> Hello,
>> I have got a question related to the network performance and MIPv6 implementation.
>> Find a pdf of my testbed attached. 
>>
>> When I run iperf over my Ethernet Interface without running MIPv6, I reach a 
>> throughput of about 90 Mbit/s. When I now start MIPv6 conducting the same test
>> I reach a strongly fluctuating datarate between 0 Mbit/s and 2 Mbit/s. 
>>
>> Seems that MIPv6 influences the maximum throughput very strong. Can anybody of you
>> please explain me that phenomenon?
>>
>> best regards
>>
>> Marcus
>>   
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Support mailing list
>> Support at ml.nautilus6.org
>> http://ml.nautilus6.org/mailman/listinfo/support
>>   
>>     
> _______________________________________________
> Support mailing list
> Support at ml.nautilus6.org
> http://ml.nautilus6.org/mailman/listinfo/support
> _______________________________________________
> Support mailing list
> Support at ml.nautilus6.org
> http://ml.nautilus6.org/mailman/listinfo/support
>
>   


More information about the Support mailing list