Re: 10GE Click performance

Its pretty easy to run the tests. I have my own emulab cluster :) good tip on git bisect, I will give it a go tomorrow.
Roman

Eddie Kohler <[email protected]> wrote:

>Hi Roman,
>
>There weren't many changes in FromDevice in the 1.8-2.0 time frame. git log 
>will show you what they were. The major change, if I remember right, was using 
>a new method of stealing packets from Linux for patchless purposes.
>
>How easy is it for you to run these tests? Have you ever used `git bisect`?
>
>Eddie
>
>
>On 01/18/2012 08:34 PM, rchertov wrote:
>> Some more interesting tidbits of data.  If I run release 1.8, I get the
>> speed I need.  However, after release 2.0, the problem starts to
>> manifest itself.
>>
>> Roman
>>
>> On 01.18.2012 15:05, rchertov wrote:
>>> Ok, I got some numbers finally.
>>> I have two dual socket quad core Intel(R) Xeon(R) CPU E5450  @
>>> 3.00GHz
>>> boxes with Myricom 10GE cards
>>> using SR transceivers running patched linux 2.6.24.7.  The myricom
>>> driver is the one included in the 2.6.24.7 kernel.
>>>
>>> Topology:
>>> Src ->  Dst;
>>>
>>> Source config:
>>> src1 :: RatedSource(LENGTH 2112, RATE 400000, LIMIT 24000000)
>>>       ->  UDPIPEncap(SRC 10.1.1.4, SPORT 6667, DST 10.1.1.2, DPORT
>>> 6667)
>>>       ->  EtherEncap(0x0800, 00:60:DD:47:94:2A, 00:15:17:7C:E4:A1)
>>>       ->  ctr :: AverageCounter
>>>       ->  ToDevice(eth2, BURST 16);
>>>
>>> Destination config:
>>>   FromDevice(eth2, PROMISC true, BURST 512) ->  ctr :: AverageCounter
>>> ->
>>> Discard;
>>>
>>>
>>> Source 2.0.1 Destination 2.0.1 (its actually from yesterday's git
>>> pull)
>>> Src rate: 204364 count 24000000
>>> Dst rate: 204364 count 23977282
>>>
>>> Source 1.7.0rc1 Destination 2.0.1
>>> Src rate: 400000 count 24000000
>>> Dst rate: 264502 count 15869088
>>>
>>> Source 1.7.0rc1 Destination 1.7.0rc1
>>> Src rate: 400000 count 24000000
>>> Dst rate: 400000 count 23999893
>>>
>>> Source 2.0.1 Destination 1.7.0rc1
>>> Src rate: 400000 count 24000000
>>> Dst rate: 400000 count 23999750
>>>
>>> So based on the runs, it appears the issue is with packet reception
>>> in
>>> the current version of Click compared to 1.7.0rc1.  It is also not
>>> clear
>>> to me as to why the sending rate is reduced when both machines run
>>> 2.0.1
>>> click.
>>>
>>> Roman
>>>
>>> On 01.18.2012 08:02, Eddie Kohler wrote:
>>>> Well, shoot. This performance degradation is unfortunate.
>>>>
>>>> There are two questions:
>>>> 1. Why is performance low (~300Kpps or less)?
>>>> 2. Why has performance gotten worse (300->200)?
>>>>
>>>> Let's attack #2 first.
>>>>
>>>> Has a non-Device configuration, such as InfiniteSource->Idle, slowed
>>>> down?
>>>>
>>>> Eddie
>>>>
>>> _______________________________________________
>>> click mailing list
>>> [email protected]
>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>
>> _______________________________________________
>> click mailing list
>> [email protected]
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click