perfsonar-user - Re: [perfsonar-user] a nit on owping timestamp output
Subject: perfSONAR User Q&A and Other Discussion
List archive
- From: Matt Mathis <>
- To: "David A. J. Ripley" <>
- Cc: Aaron Brown <>, Alan Whinery <>, " Users" <>
- Subject: Re: [perfsonar-user] a nit on owping timestamp output
- Date: Mon, 9 Jun 2014 14:05:09 -0700
I would invert the flag: --legacy-no-tz
Thanks,
--MM--
Matt Mathis Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know "The Truth" and use force to apply it to others.
Matt Mathis Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know "The Truth" and use force to apply it to others.
On Mon, Jun 9, 2014 at 1:06 PM, David A. J. Ripley <> wrote:
Timestamps are only meaningful when they include a timezone specification. :-)
</pet-peeve>
D.
--
On Jun 9, 2014, at 3:39 PM, Aaron Brown <> wrote:
> Hey Alan,
>
> It’d probably be reasonable to add a flag to bwctl (and if possible the tools it calls) to let the user configure the timestamp output. I’m not positive if we’d want to go full-on timezone, but maybe something like “—gmtime”, and have a flag in the protocol to say “i want all timestamps to be output in gmtime” or something similar. I’m not sure if any of the other tools spit out a timestamp (iperf3 might) so it may be a more “one-use” flag, but I could see a use for it.
>
> Cheers,
> Aaron
>
> On Jun 5, 2014, at 4:00 PM, Alan Whinery <> wrote:
>
>> I notice that owping returns the "first" and "last" timestamps as a zone-less time reference, apparently using local time on the sender as the reference. This matters little when one is using the command line and getting a report for each of two tests, one each direction, in a terminal. A newer, emerging use-case, with one-way tests invoked through bwctl, possibly from a third host, possibly saving output to parse, can leave one with un-clear timestamps.
>>
>> Below is an example, with "bwping -T owamp", invoking tests between two bwctl hosts. I just stumbled onto this because Ubuntu-armhf installed with local=GMT, and Raspbian installs with local=HST. The tests were run one right after the other, but appear to have occurred 10 hours apart.
>>
>> The obvious fix would be to simply have owping always get time with gmtime() versus localtime() (or similar, I haven't looked at code). Of course, one would need to consider breaking existing owping-output-parsers. Using localtime even be a flaw/oversight in owamp implementation, since it seems counter-intuitive for such things.
>>
>> -Alan
>>
>>> root@armv6l-b8-27-eb-c1-45-11:/etc/owampd# bwping -T owamp -N 50 -i 0.1 -s hostA.hawaii.edu A AESKEY bob /etc/bwctld/bwctld.keys -c hostB.hawaii.edu A AESKEY bob /etc/bwctld/bwctld.keys
>>> bwping: 15 seconds until test results available
>>>
>>> SENDER START
>>> bwctl: start_endpoint: 3610982384.435748
>>> bwctl: run_endpoint: receiver: hostB.hawaii.edu
>>> bwctl: run_endpoint: sender: hostA.hawaii.edu
>>> bwctl: exec_line: owping -t -c 50 -i 0.100000 [hostB.hawaii.edu]:4000
>>> bwctl: run_tool: tester: owamp
>>> bwctl: run_tool: receiver: hostB.hawaii.edu
>>> bwctl: run_tool: sender: hostA.hawaii.edu
>>> bwctl: start_tool: 3610982390.995661
>>> Approximately 8.1 seconds until results available
>>>
>>> --- owping statistics from [hostA.hawaii.edu]:39037 to [hostB.hawaii.edu]:45477 ---
>>> SID: 80ab5714d73b37f719eed0d875a81922
>>> first: 2014-06-05T18:39:52.181
>>> last: 2014-06-05T18:39:57.101
>>> 50 sent, 0 lost (0.000%), 0 duplicates
>>> one-way delay min/median/max = 0.196/0.3/0.462 ms, (err=0.414 ms)
>>> one-way jitter = 0.1 ms (P95-P50)
>>> Hops = 5 (consistently)
>>> no reordering
>>>
>>> bwctl: stop_tool: 3610982400.301793
>>> bwctl: stop_endpoint: 3610982401.804053
>>>
>>> SENDER END
>>> root@armv6l-b8-27-eb-c1-45-11:/etc/owampd# bwping -T owamp -N 50 -i 0.1 -c hostA.hawaii.edu A AESKEY bob /etc/bwctld/bwctld.keys -s hostB.hawaii.edu A AESKEY bob /etc/bwctld/bwctld.keys
>>> bwping: 15 seconds until test results available
>>>
>>> SENDER START
>>> bwctl: start_endpoint: 3610982423.024834
>>> bwctl: run_endpoint: receiver: hostA.hawaii.edu
>>> bwctl: run_endpoint: sender: hostB.hawaii.edu
>>> bwctl: exec_line: owping -t -c 50 -i 0.100000 [hostA.hawaii.edu]:4000
>>> bwctl: run_tool: tester: owamp
>>> bwctl: run_tool: receiver: hostA.hawaii.edu
>>> bwctl: run_tool: sender: hostB.hawaii.edu
>>> bwctl: start_tool: 3610982429.660192
>>> Approximately 8.1 seconds until results available
>>>
>>> --- owping statistics from [hostB.hawaii.edu]:51330 to [hostA.hawaii.edu]:54300 ---
>>> SID: 80abd6f4d73b381dc3ef584157befacb
>>> first: 2014-06-05T08:40:30.808
>>> last: 2014-06-05T08:40:34.978
>>> 50 sent, 0 lost (0.000%), 0 duplicates
>>> one-way delay min/median/max = 0.721/0.9/1.02 ms, (err=0.414 ms)
>>> one-way jitter = 0.1 ms (P95-P50)
>>> Hops = 6 (consistently)
>>> no reordering
>>>
>>> bwctl: stop_tool: 3610982437.321193
>>> bwctl: stop_endpoint: 3610982439.333351
>>>
>>> SENDER END
>>
>
David A. J. Ripley
Indiana University GlobalNOC.
<> +1-812-855-5079
http://mypage.iu.edu/~daripley/daripley.pgp
- [perfsonar-user] a nit on owping timestamp output, Alan Whinery, 06/05/2014
- Re: [perfsonar-user] a nit on owping timestamp output, Aaron Brown, 06/09/2014
- Re: [perfsonar-user] a nit on owping timestamp output, David A. J. Ripley, 06/09/2014
- Re: [perfsonar-user] a nit on owping timestamp output, Matt Mathis, 06/09/2014
- Re: [perfsonar-user] a nit on owping timestamp output, David A. J. Ripley, 06/09/2014
- Re: [perfsonar-user] a nit on owping timestamp output, Aaron Brown, 06/09/2014
Archive powered by MHonArc 2.6.16.