Hi Paolo, I have correct timestamp_start value and I will disable sql_history.
In latest trail I found I missed aggregate 'timestamp_end'. But I noticed a weird thing that my timestamp_end was wrong: I also checked the post @2013. It seems ' timestamp_end' aggregate was already done. Do you have any idea? [root@LDeltaR1S9 ~]# sfacctd -l 9999 -P print -c timestamp_start,timestamp_end -r 1 INFO ( default/core ): Reading configuration from cmdline. INFO ( default/core ): waiting for sFlow data on 0.0.0.0:9999 TIMESTAMP_START TIMESTAMP_END PACKETS BYTES INFO ( default/print ): *** Purging cache - START (PID: 6707) *** 2014-09-10 19:52:52.702513 1970-01-01 08:00:00.0 1 98 2014-09-10 19:52:52.702552 1970-01-01 08:00:00.0 1 98 Yours, TC -----Original Message----- From: pmacct-discussion [mailto:pmacct-discussion-boun...@pmacct.net] On Behalf Of Paolo Lucente Sent: Wednesday, September 10, 2014 9:14 AM To: pmacct-discussion@pmacct.net Subject: Re: [pmacct-discussion] More precise flow timestamp Hi, Yes, with the "timestamp_start" primitive you can get a timestamp per sFlow packet. If timestamps_secs config directive is set to false (which is default) then you get also residual time after secs populated (which is what you want). sql_history does not clash with the timestamp_start primitive, you can use both. Cheers, Paolo On Tue, Sep 09, 2014 at 12:14:12PM +0000, itria30...@itri.org.tw wrote: > Hi Paolo and all, > Hope this is right place to post my question. > For recording flow’s corresponding timestamp I use sql_history primitive > and my sfacctd.conf looks like: > ……………… > sql_dont_try_update: true > sql_history: 1m > !ql_history_roundoff: mh > …………….. > > The sql data I got > mysql> select * from acct_v9 limit 3; > +-----+-------+----------+----------+-----+----------+-------------------+-------------------+------+--------+--------+-------------+---------------+----------+----------+-----------+----------+-----+---------+-------+-------+---------------------+---------------------+ > | cos | etype | mask_src | mask_dst | tag | class_id | mac_src | > mac_dst | vlan | as_src | as_dst | ip_src | ip_dst | > port_src | port_dst | tcp_flags | ip_proto | tos | packets | bytes | flows | > stamp_inserted | stamp_updated | > +-----+-------+----------+----------+-----+----------+-------------------+-------------------+------+--------+--------+-------------+---------------+----------+----------+-----------+----------+-----+---------+-------+-------+---------------------+---------------------+ > | 0 | 800 | 0 | 0 | 0 | unknown | 00:26:55:55:e0:06 | > 80:71:1f:4c:be:01 | 100 | 0 | 0 | 10.100.1.2 | 140.96.27.220 | > 53 | 34504 | 0 | udp | 0 | 1 | 428 | 0 | > 2014-09-09 19:39:00 | 2014-09-09 19:40:01 | > | 0 | 800 | 0 | 0 | 0 | unknown | 00:26:55:55:82:84 | > 02:a0:98:28:51:d9 | 98 | 0 | 0 | 10.98.1.32 | 10.98.1.22 | > 678 | 2049 | 16 | tcp | 0 | 1 | 1522 | 0 | > 2014-09-09 19:39:00 | 2014-09-09 19:40:01 | > | 0 | 800 | 0 | 0 | 0 | unknown | 00:e0:81:ce:9b:10 | > 80:71:1f:4c:be:01 | 236 | 0 | 0 | 10.236.39.1 | 140.96.27.144 | > 22 | 52098 | 16 | tcp | 16 | 3 | 4566 | 0 | > 2014-09-09 19:39:00 | 2014-09-09 19:40:01 | > +-----+-------+----------+----------+-----+----------+-------------------+-------------------+------+--------+--------+-------------+---------------+----------+----------+-----------+----------+-----+---------+-------+-------+---------------------+---------------------+ > 3 rows in set (0.00 sec) > > > Flow are written into mysql every 1 second. (It’s nice to have such a > timestamp for each flow.) > And is there any more precise primitive or mechanism to use , for example, > some timing information in packet header in millisecond precision? > > Thanks in advance. And good day :) > > TC Wu > > > > > ==================================================================== > 本信件可能包含工研院機密資訊,非指定之收件者,請勿使用或揭露本信件內容,並請銷毀此信件。 > This email may contain confidential information. Please do not use or > disclose it in any way and delete it if you are not the intended recipient. > _______________________________________________ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists ==================================================================== 本信件可能包含工研院機密資訊,非指定之收件者,請勿使用或揭露本信件內容,並請銷毀此信件。 This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient. _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists