On Wed, Jul 27, 2016 at 3:13 PM, Luis Gomez <[email protected]> wrote:
> Hi all, > > I got the action point from last S3P call to start some discussion around > OpenFlow tests we can do for next ODL perf paper (Boron). > > I am not sure we will have time for all the below but ideally I was > thinking in 4 tests: > > 1) REST programming performance: > > - Goal: Measure OF programming rate using NB REST interface > - Methodology: Use test REST scripts (flows in datastore) to program 100K > flows on an OF network of different size: 16-32-64-128 switches, etc... > - Test variations: Use single flow/REST request and multiple flows/REST > (bulk) request. > - Collected data: controller programming time (from first to last flow) > from REST script, switch programming time (from first to last flow) polling > the OVS, flow confirmation delay (time after T1) polling the operational DS. > I am not sure this test will give correct openflowplugin performance, because in my understanding NB rest interface is bottleneck here. This test probably we can use to show the restconf interface performance test. > > 2) Java programming performance: > > - Goal: Measure OF programming rate using internal Java interface > - Methodology: Use bluk-o-matic application (flows in datastore or rpc) to > program 100K flows on an OF network of different size: 16-32-64-128 > switches, etc... > - Test variations: Use single flow/REST request and multiple flows/REST > (bulk) request. > - Collected data: controller programming time (from first to last flow) > from bulk-o-matic, switch programming time (from first to last flow) > polling the OVS, flow confirmation delay (time after T1) polling the > operational DS. > > 3) Network message processing latency: > > - Goal: Measure OF packet message processing time > - Methodology: Use some OF public tool (Cbench, MT-Cbench, SDN-blaster) to > generate OF packets and measure the delay (latency mode) of the received > controller flows on an OF network of different size: 16-32-64-128 switches, > etc... > - Test variations: Use controller drop-test application in DS and RPC mode. > - Collected data: packet processing rate (latency=1/rate) > > 4) Topology scalability: > > - Goal: Scale OF network and measure learning time. > - Methodology: Use some OF public tool (Mininet, Multinet) to generate > different sizes of large topologies: 1000, 2000, 3000 switches, etc... > - Collected data: Time for the controller to learn about the topology. > > In addition the same tests (or a subset) should run in a cluster > environment (3 node cluster). > > The main problem we have today for running and automating the above is > people resources, so far Jin and Sanjib offered to help but more help would > be appreciated. > > BR/Luis > > _______________________________________________ > openflowplugin-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev > -- Thanks Anil
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
