[Snort-devel] Clarification upon stats
sockstat at ...445...
Tue Jul 30 04:13:39 EDT 2013
Does anybody have time to answer my question?
Date: Wed, 24 Jul 2013 03:01:06 -0700
Subject: Clarification upon stats
From: sockstat at ...445...
To: snort-devel at lists.sourceforge.net
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.
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?
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-devel