The ask from the pnda team was for a high-precision timestamp, not a
millisecond granularity timestamp. The current Linux epoch as of this writing
is approximately 1,478,087,552.
Double-precision FP numbers have a 53-bit fraction (52 bits explicitly stored).
Adding a fixed bias of O(1e9) to a double-precision floating point quantity
reduces precision to the point where events separated by less than 1us will
have the same time stamp.
In a single-core case, vpp processes ~ 15 MPPS. If you care about
differentiable time stamps across those packets, adding a large bias is not
helpful.
If you want, feel free to change the collector code to send 64-bit nanoseconds
since 1/1/70. Should take ten minutes.
Here’s the back of the envelope calculation:
(gdb) p (f64)(0x7ffffffffffffffffULL)
$5 = 1.8446744073709552e+19
The largest positive 64-bit integer is approximately 2e19. The current epoch is
O(1e18) ns. So that would work for years to come.
Here’s a simple test code which demonstrates the effect:
static clib_error_t *
test_fp_command_fn (vlib_main_t * vm,
unformat_input_t * input, vlib_cli_command_t * cmd)
{
f64 zero_origin, big_origin, one_ns, ten_ns, hundred_ns;
f64 one_us, ten_us, hundred_us;
big_origin = 1478087552.0;
zero_origin = 0.0;
one_ns = 1e-9;
ten_ns = 1e-8;
hundred_ns = 1e-7;
one_us = 1e-6;
ten_us = 1e-5;
hundred_us = 1e-4;
vlib_cli_output (vm, "zero plus 1 ns %.9f",
zero_origin + one_ns);
vlib_cli_output (vm, "big_origin %.9f", big_origin);
vlib_cli_output (vm, "big_origin plus 1 ns %.9f",
big_origin + one_ns);
vlib_cli_output (vm, "big_origin plus 10 ns %.9f",
big_origin + ten_ns);
vlib_cli_output (vm, "big_origin plus 100 ns %.9f",
big_origin + hundred_ns);
vlib_cli_output (vm, "big_origin plus 1 us %.9f",
big_origin + one_us);
vlib_cli_output (vm, "big_origin plus 10 us %.9f",
big_origin + ten_us);
vlib_cli_output (vm, "big_origin plus 100 us %.9f",
big_origin + hundred_us);
return 0;
}
DBGvpp# test fp
zero plus 1 ns .000000001
big_origin 1478087552.000000000
big_origin plus 1 ns 1478087552.000000000
big_origin plus 10 ns 1478087552.000000000
big_origin plus 100 ns 1478087552.000000000
big_origin plus 1 us 1478087552.000001000
big_origin plus 10 us 1478087552.000010000
big_origin plus 100 us 1478087552.000100000
Thanks… Dave
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
Behalf Of Andrew Li (zhaoxili)
Sent: Wednesday, November 2, 2016 7:31 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Discussion on flowStartNanoSeconds field in flow-per-packet
plugin
Hi everyone,
Trying out the flow-per-packet plugin which Dave hacked and merged a few days
ago. While it works fine in general I’ve noticed the flowStartNanoseconds field
here stands for the time since vpp started.
This brings in the problem that the collector has to know when VPP started as
well. So here’re my questions:
1. How should I know the time when VPP started?
2. Is there a special concern that why this field can’t be the time since
a fixed time, say 19700101? In RFC 5102 it said:
Timestamps flowStartSeconds, flowEndSeconds, flowStartMilliseconds,
flowEndMilliseconds, flowStartMicroseconds, flowEndMicroseconds,
flowStartNanoseconds, flowEndNanoseconds, and
systemInitTimeMilliseconds are absolute and have a well-defined fixed
time base, such as, for example, the number of seconds since 0000 UTC
Jan 1st 1970.
It also recommended using flowStartSysUpTime to represent the time relative to
the last initialization of the IPFIX Device:
Timestamps flowStartSysUpTime and flowEndSysUpTime are relative
timestamps indicating the time relative to the last (re-
)initialization of the IPFIX Device. For reporting the time of the
last (re-)initialization, systemInitTimeMilliseconds can be reported,
for example, in Data Records defined by Option Templates.
For reference the plugin is in vpp/plugins/flowperpkt-plugin.
Thanks,
Andrew
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
