Hi George-Cristian, You do not specify what is input of network traffic - netflow, sflow or packet capture. Since you speak of one minute temporal aggregation being too coarse-grained, i believe your input is netflow. Is then your purpose to log down micro-flows to the database, ie. ideally disable any sort of time aggregation? If this is all correct you can get latest code from the CVS where you have availability of newly introduced timestamp_start and timestamp_end primitives precisely for this purpose.
Your question could be why introducing such basic time-related primitives so recently. Q6 in the new FAQS document addresses this point: "pmacct was not originally meant to log network traffic at packet/micro-flow level: it allows to get an aggregated view of the traffic -- both in space and in time. On top of that, there are layers of filtering, sampling and tagging. These are the keys to scale. As these features are fully configurable, data granularity and resolution can be traded off in favour of increased scalability or less resources consumption. More recently, logging has been introduced, by means of two new primitives timestamp_start and timestamp_end, fostered by the development of NetFlow/IPFIX as generic transport protocol, ie. as a replacement of syslog; it was then intuitive to generalize the logging support to the more traditional traffic accounting part." Hope the above helps, let me know. Cheers, Paolo On Sun, Apr 28, 2013 at 12:30:00AM +0300, George-Cristian Bîrzan wrote: > Is it possible to set the SQL history value to lower than 1m? From the > docs, it seems not, same with the source, and my attempts at doing it > failed: 's' is not a recognized and putting in something without a suffix > is the same as leaving it false. > > I've been, also, playing with 'sql_dont_use_update', which does give me a > better resolution, but it makes it impossible to tell for how long a period > the rows are for (probably, this only applies for a sql_refresh_time > smaller than sql_history, but yeah). > > Assuming it's not possible, is there a particular reason for this? We don't > have that much traffic, I think we peek at 500Mbps during normal times, I'm > pretty sure we can scrounge up a server good enough to handle way more than > that, especially since we really don't need ACID on this stuff... > > -- > George-Cristian Bîrzan > _______________________________________________ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
