[Snort-devel] Clarification upon stats
sockstat at ...445...
Tue Jul 30 21:08:58 EDT 2013
Thanks for your reply.
May I propose a patch to fi the OTN stats?
--- src/profiler.c.orig 2013-07-30 18:03:56.595012379 -0700
+++ src/profiler.c 2013-07-30 18:05:35.779014374 -0700
@@ -85,7 +85,7 @@
/* Externs ********************************************************************/
-extern PreprocStats mpsePerfStats, rulePerfStats, ncrulePerfStats;
+extern PreprocStats mpsePerfStats, rulePerfStats, ncrulePerfStats, ruleOTNEvalPerfStats, ruleRTNEvalPerfStats;
@@ -926,6 +926,8 @@
mpsePerfStats.ticks -= rulePerfStats.ticks;
/* And adjust the rules to include the NC rules */
rulePerfStats.ticks += ncrulePerfStats.ticks;
+ /* Also adjust the semi otn stats to not include the rtn stats */
+ ruleOTNEvalPerfStats.ticks -= ruleRTNEvalPerfStats.ticks;
Date: Tue, 30 Jul 2013 09:30:33 -0400
Subject: Re: [Snort-devel] Clarification upon stats
From: twease at ...402...
To: sockstat at ...445...
CC: snort-devel at lists.sourceforge.net
On Wed, Jul 24, 2013 at 6:01 AM, sockstat <sockstat at ...445...> wrote:
I wanted to ask about the performance counters that snort maintains. In the function detection_option_tree_evaluate you start maintaining ruleOTNEvalPerfStats using a macro. But this actually kicks in for any type of node while only the leaf nodes seem to be an OTN. It also adds up when a node type is Flow or pcre etc so maybe it should better be called ruleNODEEvalPerfStats? In detection_option_tree_evaluate you call detection_option_node_evaluate which in case of a leaf node gets the RTN from the OTN and fpEvalRTN is called where you maintain ruleRTNEvalPerfStats. So in the end screen where you print the stats out it seems to me that the microseconds for rule tree eval contain the rtn eval microseconds, because fpEvalRTN is called while counting the clock ticks for ruleOTNEvalPerfStats. In profile.c you print the amount of microseconds out. So rule tree eval is not just the ticks spent in detection_option_tree_evaluate, It has the clock ticks spent in fpEvalRTN included, while rtn eval is printed out sperately.
Yes, it looks like the RTN stats are counted in the OTN stats. I'll create a bug to see if we can get this fixed.
Same thing holds for the mpse stats when __process_queue calls rule_tree_match, then the ticks spent in detection_oprion_tree_evaluate and fpEvalRTN are included in the ticks spent in mpseSearch. Hence it seems there is some overlap in the stats, because I don't see the ticks spent in fpEvalRTN subtracted from the amount of ticks spent in detection_option_tree_evaluate for example or did I miss this?
In rule_tree_match(), rulePerfStats are started and in ShowPreprocProfiles() in profile.c it is subtracted from mpsePerfStats.
Also in case of a core 2duo CPU the tsc isn't stable and hence the calculation of how many clock ticks occur per microsecond might not be accurate?
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
Snort-devel mailing list
Snort-devel at lists.sourceforge.net
Please visit http://blog.snort.org for the latest news about Snort!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-devel