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

Reply via email to