Hi Muthukrishnan,

there is no golden standard behind this value. Setting it to 100ms or even 
lower value will result into low latency system but this also decreases 
throughput of system.

If you have few switches and little no big requirement on flows per second 
throughput then 100ms might suit better to your setup. On the other hand if 
there are hundreds of devices and throughput of thousands of flows per second 
required then 500ms or even higher will improve overall performance.

Also there is a complementary parameter - amount of messages in outbound queue 
without barrier inside. The more messages kept in queue the higher throughput 
you shall get. But there is memory cost and also by extending size of those 
queues (per device) there comes overload risk of md-sal notification queue.

True - this value might be configurable. But that would solve the situation 
only for static requirements.



From: openflowjava-dev-boun...@lists.opendaylight.org 
<openflowjava-dev-boun...@lists.opendaylight.org> on behalf of Muthukrishnan 
Thangasamy <muthukrishna...@tataelxsi.co.in>
Sent: Wednesday, February 15, 2017 08:13
To: openflowplugin-dev@lists.opendaylight.org
Cc: openflowjava-...@lists.opendaylight.org
Subject: [openflowjava-dev] Barrier Message Timeout - 500ms - Rational behind 
the value

Dear Team ,

I have been working in Lithium and Boron Stable Version .

Lets take Boron , In openflowplugin.cfg default timer for barrier message is 
500ms is there any

rational behind the same ? why not 100ms ?

If I push via SAL-FLOW RPC , total time taken for flow push = Time taken for 
flow push + barrier delay  = ~ 30 ms + 520 ms (barrier ).

If I change the value from 500ms to 100 ms I am getting drastic performance 
improvement in flow push processing . Can anyone tell why we have gone for 
500ms as default timer value ?

How we have arrived this golden value of 500ms ?


File : openflowplugin.cfg

"#Timeout interval in milliseconds between each barrier message.

#Default value is set to 500 milliseconds


openflowplugin-dev mailing list
  • [openflowplugin... Muthukrishnan Thangasamy
    • Re: [openf... Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES at Cisco)
      • Re: [o... Muthukrishnan Thangasamy
        • Re... Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES at Cisco)

Reply via email to