New message count for Openflow Java in ODL master (Boron)
|
Chinmay Kumar Mohanta <chinmay.kumar.mohanta@...>
Hi Michal,
Thanks for your reply. Yes, I will do the changes as you have indicated.
Regards, Chinmay
From: Michal Polkoráb [mailto:michal.polkorab@...]
Sent: Tuesday, May 17, 2016 3:14 PM To: Chinmay Kumar Mohanta; Chinmay.Mohanta Cc: openflowjava-dev@...; Shuva Jyoti Kar; Ashutosh Bisht; Muthukumaran K Subject: Re: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)
Hi Chinmay,
in that case please go ahead with your changes. You can also remove the two positive counters mentioned before to further improve the performance (we will still have the send messages counters from openflowplugin). Please push one separate commit - where you remove these counters, so that we can track it easily in case the counters are needed in the future.
Regards, Michal From: Chinmay Kumar Mohanta <chinmay.kumar.mohanta@...>
Hi Michal,
From our ongoing effort to debug some of the performance related issues we find that it greatly simplifies the debugging process if error cases (for example like message drop) are reported explicitly rather than implicitly (as a derivation). Explicit error reporting provides *** sensible & precise contextual*** information which will expedite the process of finding the root cause of the issue.
In line with this principle we are still strongly considering to implement this new counter.
Pleases comment?
Thanks and Regards, Chinmay Mohanta
From: Michal Polkoráb [mailto:michal.polkorab@...]
Hi Chinmay,
your point makes sense. However, we should thoroughly consider removing these counters. These were introduced in the past to check if / where there are messages being lost between openflowplugin & openflowjava + to verify the backpressure mechanism. If we similar issue appears again, these counters might be handy.
Michal From: Chinmay.Mohanta <mohanta.chinmay@...>
Hi Michal,
Thanks for your reply.
Indeed the formula indicated by you gives the expected value !! So it obviates the implementation of a new counter.
However following new thoughts emerge.
Do we really need the counts DS_ENTERED_OFJAVA and DS_ENCODE_SUCCESS ?
Maintaining these two counts (for every message) is costly in terms of performance (due to need for synchronization).
I think we should have counts only for the error scenarios resulting least influence on the performance.
BTW, my goal is to simplify the debugging process to find out whenever/wherever there is a message drop due to resource contention. Message drop count will provide an essential input to rationalize the provisioning of resources.
Thanks and Regards, Chinmay @ ericsson
On Wed, May 11, 2016 at 5:22 PM, Michal Polkoráb <michal.polkorab@...> wrote: Hello Chinmay,
is it really needed to add such counter ? One can get this number by DS_ENTERED_OFJAVA - (DS_ENCODE_SUCCESS + DS_ENCODE_FAIL) if only OutboundQueue is used. This counter looses its meaning when OutboundQueueManager is used as the manager enqueues all messages and the message count is controlled byt rpcQuota in openflowplugin.
Regards, Michal
From: Chinmay.Mohanta <mohanta.chinmay@...>
Hi all,
To supplement present testing and diagnosing scenarios using message counts, I am proposing following new count.
Count name : DS_DROPPED_PACKET_QFULL Purpose : To count messages dropped because the queue present in ChannelOutboundQueue is full. This count will be helpful to mark the threshold downstream message processing capability of Openflow Java. Downsizing/upsizing resources surrounding this counter will decrease/increase downstream message processing capability.
Implementation implications:
This new count will be implemented using existing counter module StatisticsCounters.
Please share your comments (if any ).
Thanks and Regards, Chinmay @ ericsson MichalPolkoráb Software Engineer
MichalPolkoráb Software Engineer
MichalPolkoráb Software Engineer
|
|
Michal Polkoráb <michal.polkorab@...>
Hi Chinmay,
in that case please go ahead with your changes. You can also remove the two positive counters mentioned before to further improve the performance (we will still have the send messages counters from openflowplugin). Please push one separate commit - where
you remove these counters, so that we can track it easily in case the counters are needed in the future.
Regards, Michal From: Chinmay Kumar Mohanta <chinmay.kumar.mohanta@...>
Sent: 17 May 2016 08:10 To: Michal Polkoráb; Chinmay.Mohanta Cc: openflowjava-dev@...; Shuva Jyoti Kar; Ashutosh Bisht; Muthukumaran K Subject: RE: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron) Hi Michal,
From our ongoing effort to debug some of the performance related issues we find that it greatly simplifies the debugging process if error cases (for example like message drop) are reported explicitly rather than implicitly (as a derivation). Explicit error reporting provides *** sensible & precise contextual*** information which will expedite the process of finding the root cause of the issue.
In line with this principle we are still strongly considering to implement this new counter.
Pleases comment?
Thanks and Regards, Chinmay Mohanta
From: Michal Polkoráb [mailto:michal.polkorab@...]
Hi Chinmay,
your point makes sense. However, we should thoroughly consider removing these counters. These were introduced in the past to check if / where there are messages being lost between openflowplugin & openflowjava + to verify the backpressure mechanism. If we similar issue appears again, these counters might be handy.
Michal From: Chinmay.Mohanta <mohanta.chinmay@...>
Hi Michal,
Thanks for your reply.
Indeed the formula indicated by you gives the expected value !! So it obviates the implementation of a new counter.
However following new thoughts emerge.
Do we really need the counts DS_ENTERED_OFJAVA and DS_ENCODE_SUCCESS ?
Maintaining these two counts (for every message) is costly in terms of performance (due to need for synchronization).
I think we should have counts only for the error scenarios resulting least influence on the performance.
BTW, my goal is to simplify the debugging process to find out whenever/wherever there is a message drop due to resource contention. Message drop count will provide an essential input to rationalize the provisioning of resources.
Thanks and Regards, Chinmay @ ericsson
On Wed, May 11, 2016 at 5:22 PM, Michal Polkoráb <michal.polkorab@...> wrote: Hello Chinmay,
is it really needed to add such counter ? One can get this number by DS_ENTERED_OFJAVA - (DS_ENCODE_SUCCESS + DS_ENCODE_FAIL) if only OutboundQueue is used. This counter looses its meaning when OutboundQueueManager is used as the manager enqueues all messages and the message count is controlled byt rpcQuota in openflowplugin.
Regards, Michal
From: Chinmay.Mohanta <mohanta.chinmay@...>
Hi all,
To supplement present testing and diagnosing scenarios using message counts, I am proposing following new count.
Count name : DS_DROPPED_PACKET_QFULL Purpose : To count messages dropped because the queue present in ChannelOutboundQueue is full. This count will be helpful to mark the threshold downstream message processing capability of Openflow Java. Downsizing/upsizing resources surrounding this counter will decrease/increase downstream message processing capability.
Implementation implications:
This new count will be implemented using existing counter module StatisticsCounters.
Please share your comments (if any ).
Thanks and Regards, Chinmay @ ericsson MichalPolkoráb Software Engineer
MichalPolkoráb Software Engineer
MichalPolkoráb Software Engineer
|
|
Chinmay Kumar Mohanta <chinmay.kumar.mohanta@...>
Hi Michal,
From our ongoing effort to debug some of the performance related issues we find that it greatly simplifies the debugging process if error cases (for example like message drop) are reported explicitly rather than implicitly (as a derivation). Explicit error reporting provides *** sensible & precise contextual*** information which will expedite the process of finding the root cause of the issue.
In line with this principle we are still strongly considering to implement this new counter.
Pleases comment?
Thanks and Regards, Chinmay Mohanta
From: Michal Polkoráb [mailto:michal.polkorab@...]
Sent: Friday, May 13, 2016 3:37 PM To: Chinmay.Mohanta Cc: openflowjava-dev@...; Shuva Jyoti Kar; Chinmay Kumar Mohanta; Ashutosh Bisht; Muthukumaran K Subject: Re: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)
Hi Chinmay,
your point makes sense. However, we should thoroughly consider removing these counters. These were introduced in the past to check if / where there are messages being lost between openflowplugin & openflowjava + to verify the backpressure mechanism. If we similar issue appears again, these counters might be handy.
Michal From: Chinmay.Mohanta <mohanta.chinmay@...>
Hi Michal,
Thanks for your reply.
Indeed the formula indicated by you gives the expected value !! So it obviates the implementation of a new counter.
However following new thoughts emerge.
Do we really need the counts DS_ENTERED_OFJAVA and DS_ENCODE_SUCCESS ?
Maintaining these two counts (for every message) is costly in terms of performance (due to need for synchronization).
I think we should have counts only for the error scenarios resulting least influence on the performance.
BTW, my goal is to simplify the debugging process to find out whenever/wherever there is a message drop due to resource contention. Message drop count will provide an essential input to rationalize the provisioning of resources.
Thanks and Regards, Chinmay @ ericsson
On Wed, May 11, 2016 at 5:22 PM, Michal Polkoráb <michal.polkorab@...> wrote: Hello Chinmay,
is it really needed to add such counter ? One can get this number by DS_ENTERED_OFJAVA - (DS_ENCODE_SUCCESS + DS_ENCODE_FAIL) if only OutboundQueue is used. This counter looses its meaning when OutboundQueueManager is used as the manager enqueues all messages and the message count is controlled byt rpcQuota in openflowplugin.
Regards, Michal
From: Chinmay.Mohanta <mohanta.chinmay@...>
Hi all,
To supplement present testing and diagnosing scenarios using message counts, I am proposing following new count.
Count name : DS_DROPPED_PACKET_QFULL Purpose : To count messages dropped because the queue present in ChannelOutboundQueue is full. This count will be helpful to mark the threshold downstream message processing capability of Openflow Java. Downsizing/upsizing resources surrounding this counter will decrease/increase downstream message processing capability.
Implementation implications:
This new count will be implemented using existing counter module StatisticsCounters.
Please share your comments (if any ).
Thanks and Regards, Chinmay @ ericsson MichalPolkoráb Software Engineer
MichalPolkoráb Software Engineer
|
|
Michal Polkoráb <michal.polkorab@...>
Hi Chinmay,
you can turn the counters on / off by providing the <statistics> element in 45-openflowjava-stats.xml file (inside openflowjava-config module). If this element is present, counters will be enabled. If the tag is missing, counters won't be enabled.
Regards, Michal From: Chinmay.Mohanta <mohanta.chinmay@...>
Sent: 16 May 2016 08:11 To: Michal Polkoráb Cc: openflowjava-dev@...; shuva.jyoti.kar@...; chinmay.kumar.mohanta@...; ashutosh.bisht@...; muthukumaran.k@... Subject: Re: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron) Hi Michal and all,
In that case I think best would be to introduce the functionality that would allow to enable/disable (via JMX or Config subsys) the counter module on demand.
In this way we can have the message counts when we need it otherwise count collection can be turned off.
comment ?
Thanks and Regards,
Chinmay @ Ericsson
On Fri, May 13, 2016 at 3:37 PM, Michal Polkoráb
<michal.polkorab@...> wrote:
MichalPolkoráb Software Engineer
|
|
Chinmay.Mohanta <mohanta.chinmay@...>
Hi Michal and all, In that case I think best would be to introduce the functionality that would allow to enable/disable (via JMX or Config subsys) the counter module on demand. In this way we can have the message counts when we need it otherwise count collection can be turned off. comment ? Thanks and Regards, Chinmay @ Ericsson On Fri, May 13, 2016 at 3:37 PM, Michal Polkoráb <michal.polkorab@...> wrote:
|
|
Michal Polkoráb <michal.polkorab@...>
Hi Chinmay,
your point makes sense. However, we should thoroughly consider removing these counters. These were introduced in the past to check if / where there are messages being lost between openflowplugin & openflowjava + to verify the backpressure mechanism. If
we similar issue appears again, these counters might be handy.
Michal From: Chinmay.Mohanta <mohanta.chinmay@...>
Sent: 12 May 2016 13:27 To: Michal Polkoráb Cc: openflowjava-dev@...; shuva.jyoti.kar@...; chinmay.kumar.mohanta@...; ashutosh.bisht@...; muthukumaran.k@... Subject: Re: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron) Hi Michal,
Thanks for your reply.
Indeed the formula indicated by you gives the expected value !!
So it obviates the implementation of a new counter.
However following new thoughts emerge.
Do we really need the counts DS_ENTERED_OFJAVA and DS_ENCODE_SUCCESS ?
Maintaining these two counts (for every message) is costly in terms of performance (due to need for synchronization).
I think we should have counts only for the error scenarios resulting least influence on the performance.
BTW, my goal is to simplify the debugging process to find out whenever/wherever there is a message drop due to resource contention. Message drop count will provide an essential input to rationalize the provisioning of resources.
Thanks and Regards,
Chinmay @ ericsson
On Wed, May 11, 2016 at 5:22 PM, Michal Polkoráb
<michal.polkorab@...> wrote:
MichalPolkoráb Software Engineer
|
|
Chinmay.Mohanta <mohanta.chinmay@...>
Hi Michal, Thanks for your reply. Indeed the formula indicated by you gives the expected value !! So it obviates the implementation of a new counter. However following new thoughts emerge. Do we really need the counts DS_ENTERED_OFJAVA and DS_ENCODE_SUCCESS ? Maintaining these two counts (for every message) is costly in terms of performance (due to need for synchronization). I think we should have counts only for the error scenarios resulting least influence on the performance. BTW, my goal is to simplify the debugging process to find out whenever/wherever there is a message drop due to resource contention. Message drop count will provide an essential input to rationalize the provisioning of resources. Thanks and Regards, Chinmay @ ericsson On Wed, May 11, 2016 at 5:22 PM, Michal Polkoráb <michal.polkorab@...> wrote:
|
|
Michal Polkoráb <michal.polkorab@...>
Hello Chinmay,
is it really needed to add such counter ? One can get this number by DS_ENTERED_OFJAVA - (DS_ENCODE_SUCCESS + DS_ENCODE_FAIL) if only OutboundQueue is used. This counter looses its meaning when OutboundQueueManager is used as the manager enqueues all messages and the message count is controlled byt rpcQuota in openflowplugin.
Regards, Michal From: Chinmay.Mohanta <mohanta.chinmay@...>
Sent: 10 May 2016 15:22 To: openflowjava-dev@... Cc: shuva.jyoti.kar@...; chinmay.kumar.mohanta@...; ashutosh.bisht@...; muthukumaran.k@... Subject: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron) Hi all,
To supplement present testing and diagnosing scenarios using message counts, I am proposing following new count.
Count name : DS_DROPPED_PACKET_QFULL
Purpose : To count messages dropped because the queue present in ChannelOutboundQueue is full. This count will be helpful to mark the threshold downstream message processing capability of Openflow Java. Downsizing/upsizing resources surrounding this counter
will decrease/increase downstream message processing capability.
Implementation implications:
This new count will be implemented using existing counter module StatisticsCounters.
Please share your comments (if any ).
Thanks and Regards,
Chinmay @ ericsson
MichalPolkoráb Software Engineer
|
|
Chinmay.Mohanta <mohanta.chinmay@...>
Hi all, To supplement present testing and diagnosing scenarios using message counts, I am proposing following new count. Count name : DS_DROPPED_PACKET_QFULL Purpose : To count messages dropped because the queue present in ChannelOutboundQueue is full. This count will be helpful to mark the threshold downstream message processing capability of Openflow Java. Downsizing/upsizing resources surrounding this counter will decrease/increase downstream message processing capability. Implementation implications: This new count will be implemented using existing counter module StatisticsCounters. Please share your comments (if any ). Thanks and Regards, Chinmay @ ericsson |
