RARE user and assistance email list

[mc36 <>]

excellent material, as usually, thanks! :)

On 3/10/22 13:02, Tim Chown wrote:
> Hi,
>
> We had a useful chat in today   s WB-PERF call on testing, and focus on use 
> cases.
>
> For info, there   s discussion of buffer size impact at the usually good 
> ESnet fasterdata site - 
> https://fasterdata.es.net/network-tuning/router-switch-buffer-size-issues/
>
> That links to a table of devices and buffer sizes - 
> https://people.ucsc.edu/~warner/buffer.html
> That lists the wedge at 16MB, as per the data sheet.
> I see an Edgecore device with 64MB, but that is a Broadcom Tomahawk 3 device 
> with 400G ports :)
>
> Tim
>
> > On 9 Mar 2022, at 06:46, Tomasz Szewczyk <> wrote:
> >
> > Hi Frederic,
> > In general - our observation was that Broadcom based boxes share same/similar 
> > buffer space. So in other words results are comparable.
> > Juniper MX as Service/Edge platform is a bit different story. It is prepared 
> > to provide HQoS so the buffer space is much larger.
> > Very interesting topic to myself is the question raised by Tim - how the box 
> > will operate in real network/with native traffic. Just remember - our tests 
> > generate artificial conditions.
> > So at the moment we can compare low level parameters of the box (good we can 
> > verify them) - but other conclusions need some extra assumptions or tests :-)
> > I hope to join the VC today.
> >
> > br
> > Tomek
> >
> > W dniu 08.03.2022 o 17:59, Fr  d  ric LOUI pisze:
> > > Hi Tomek,
> > >
> > > Many thanks for these tests.
> > > I have a question:
> > > How does these tests are handled with platform from vendor you had the chance 
> > > to have as DUT ? In other words, how does the WEDGE with RARE/freeRtr compare 
> > > to a Juniper/Cisco/Nokia/DELL/Cumulus/Broacom routers you had the chance to 
> > > test ?
> > >
> > > What is your conclusion WRT the RARE/freeRtr platform @ WEDGE: would you 
> > > recommend ? Or not ? For which use cases ?
> > >
> > > I also would be curious to have the same test with RARE/freeRtr with DPDK.
> > > (Granted the fact that the performance will depend on DPDK PMD maturity)
> > >
> > > Anyeway, great work !
> > > Frederic
> > >
> > > > Le 8 mars 2022    14:13, Tim Chown <> a   crit :
> > > >
> > > > Thanks for clarifying Tomek, that makes more sense, though it does raise the 
> > > > question of    native    tests.
> > > >
> > > > Tim
> > > >
> > > > > On 4 Mar 2022, at 11:24, Tomasz Szewczyk <> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > The setup is like this:
> > > > > <ViCfBtcuAvuVG0ov.png>
> > > > > However please consider "Egress buffer" as virtual entity. The measurement is 
> > > > > independent from buffering method (you can have VOQ as well). The diagram shows just 
> > > > > the general idea.
> > > > > The second assumption is equal speed of all interfaces - what makes 
> > > > > preparation and data interpretation much easier.
> > > > > The current run was made of course with 100G interfaces.
> > > > > So we do not see packet drops when burst is about 8000 packets. It means the 
> > > > > device handles properly the busty traffic for such conditions.
> > > > > Please note it is NOT "native" traffic - the whole setup is built in order to 
> > > > > estimate buffer size. In order to verify platform operation in native 
> > > > > environment/traffic some other tests should be used :-)
> > > > > br
> > > > > Tomek
> > > > >
> > > > >
> > > > > W dniu 04.03.2022 o 12:12, Tim Chown pisze:
> > > > > > Hi,
> > > > > >
> > > > > > Sorry, I didn   t see from the report that there are two ingress and one 
> > > > > > egress report, I   m not used to looking at reports like this.  Topology 
> > > > > > helps.
> > > > > >
> > > > > > So does this show that if these are 100G links, and you have 10G on two 
> > > > > > ingress ports, there   s drops rather than a clean 20G aggregate on the 
> > > > > > egress?  I   d not expect any drops in this scenario, but that may be naive :)
> > > > > >
> > > > > > Tim
> > > > > >
> > > > > >
> > > > > > > On 4 Mar 2022, at 11:07, Tomasz Szewczyk <>
> > > > > > >   wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > > You can se that in 6th step we noticed a number of dropped packets. This mean 
> > > > > > > burst size was 1+5x1000 for every ingress interface. So we can say that the 
> > > > > > > buffer size is ~8000 packets (IMIX size distribution)
> > > > > > > This is also independent from load (you can see similar effect for different 
> > > > > > > load values)
> > > > > > > br
> > > > > > > Tomek
> > > > > > >
> > > > > > > W dniu 04.03.2022 o 11:56, Tim Chown pisze:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > Thanks for the initial test results.  I   m not sure how to interpret them.  
> > > > > > > > I can see there are losses at certain points, but it   s unclear to me what 
> > > > > > > > the tests are testing :)
> > > > > > > >
> > > > > > > > Tim
> > > > > > > >
> > > > > > > >
> > > > > > > > > On 4 Mar 2022, at 09:51, Tomasz Szewczyk <>
> > > > > > > > >   wrote:
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > > I just finished first approach. Please take a look at attchached report. It 
> > > > > > > > > was made with Burst size step 1000. Unfortunately this is not included in 
> > > > > > > > > tables. First value for each load size is burst 1, next is 1000 and so on.
> > > > > > > > > br
> > > > > > > > > Tomek
> > > > > > > > >
> > > > > > > > > W dniu 04.03.2022 o 10:44, Xavier Jeannin pisze:
> > > > > > > > >
> > > > > > > > > > Hello
> > > > > > > > > >
> > > > > > > > > > Le 04/03/2022    10:35, Tim Chown a   crit :
> > > > > > > > > >
> > > > > > > > > > > The Internet2 people are about to play with 400G Edgecore!
> > > > > > > > > > >
> > > > > > > > > > > Something to consider?  Would Tomek be able to test it with RARE/FreeRtr? :)
> > > > > > > > > > FYI, Tomasz is right now restarted the 100G test of RARE/freeRtr switch in 
> > > > > > > > > > Pozna  . Csaba kindly helped him yesterday to solve an issue related to a 
> > > > > > > > > > laser
> > > > > > > > > > Regards
> > > > > > > > > > Xavier
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > Begin forwarded message:
> > > > > > > > > > > >
> > > > > > > > > > > > From: Thomas DeFanti
> > > > > > > > > > > > <>
> > > > > > > > > > > >
> > > > > > > > > > > > Subject: [PRP-List] Re: PRP/NRP Zoom from 10am to 11am Pacific on Thursday 
> > > > > > > > > > > > March 3
> > > > > > > > > > > > Date: 3 March 2022 at 18:47:54 GMT
> > > > > > > > > > > > To:
> > > > > > > > > > > > , Tom DeFanti <>, 
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Reply-To:
> > > > > > > > > > > <snip>
> > > > > > > > > > >
> > > > > > > > > > > >   Stordis says a 400G switch is coming.  Will have 400G edgecore very soon.
> > > > > > > > > > > Tim
> > > > > > > > > > --
> > > > > > > > > > Xavier JEANNIN
> > > > > > > > > > Network Dpt.
> > > > > > > > > > GN4-3 Network technology evolution (WP6 T1) task leader
> > > > > > > > > > T  l. : +33 1 5394 2042
> > > > > > > > > > Mob. : +33 6 3017 0963
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > www.renater.fr
> > > > > > > > > --
> > > > > > > > > Tomasz Szewczyk
> > > > > > > > > Pozna  skie Centrum Superkomputerowo Sieciowe :: Pion Technologii Sieciowych
> > > > > > > > > Poznan Supercomputing and Networking Center :: Network Technology Division
> > > > > > > > > tel: +48 61 858 2040
> > > > > > > --
> > > > > > > Tomasz Szewczyk
> > > > > > > Pozna  skie Centrum Superkomputerowo Sieciowe :: Pion Technologii Sieciowych
> > > > > > > Poznan Supercomputing and Networking Center :: Network Technology Division
> > > > > > > tel: +48 61 858 2040
> > > > > --
> > > > > Tomasz Szewczyk
> > > > > Pozna  skie Centrum Superkomputerowo Sieciowe :: Pion Technologii Sieciowych
> > > > > Poznan Supercomputing and Networking Center :: Network Technology Division
> > > > > tel: +48 61 858 2040
> >
> > --
> > Tomasz Szewczyk
> > Pozna  skie Centrum Superkomputerowo Sieciowe :: Pion Technologii Sieciowych
> > Poznan Supercomputing and Networking Center :: Network Technology Division
> > tel: +48 61 858 2040