You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by "Benjamin Mahler (JIRA)" <ji...@apache.org> on 2013/02/26 03:30:12 UTC

[jira] [Comment Edited] (MESOS-335) Statistics.truncate is flaky.

    [ https://issues.apache.org/jira/browse/MESOS-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586641#comment-13586641 ] 

Benjamin Mahler edited comment on MESOS-335 at 2/26/13 2:28 AM:
----------------------------------------------------------------

This is because the double returned from Clock::now() does not go through the Seconds constructor that multiplied into a double representing nanoseconds.

Notice how we lose precision at the microsecond precision level.

double _now:                1361844790.21959590911865234375
Seconds(_now).secs():  1361844790.2195961475372314453125
older.secs():                 1361844790.2195961475372314453125

There are a few ways to fix this:
1. We've been meaning to push Duration into clock.hpp, but I don't know if I like that, given we're losing precision at the microsecond level!!
2. Modify Duration to use int64_t (which should have been done in the first place, I don't like that ev_time returns double!). This can represent upwards of 292 years precisely. Even so, people can call secs() on duration and get an imprecise value!! Seems to me that Duration should resemble Bytes, where discrete values are used throughout the file.
                
      was (Author: bmahler):
    This is because the double returned from Clock::now() does not go through the Seconds constructor that multiplied into a double representing nanoseconds.

Notice how we lose precision at the microsecond precision level.

_now:                1361844790.21959590911865234375
Seconds(_now): 1361844790.2195961475372314453125
secs():              1361844790.2195961475372314453125

There are a few ways to fix this:
1. We've been meaning to push Duration into clock.hpp, but I don't know if I like that, given we're losing precision at the microsecond level!!
2. Modify Duration to use int64_t (which should have been done in the first place, I don't like that ev_time returns double!). This can represent upwards of 292 years precisely. Even so, people can call secs() on duration and get an imprecise value!! Seems to me that Duration should resemble Bytes, where discrete values are used throughout the file.
                  
> Statistics.truncate is flaky.
> -----------------------------
>
>                 Key: MESOS-335
>                 URL: https://issues.apache.org/jira/browse/MESOS-335
>             Project: Mesos
>          Issue Type: Bug
>            Reporter: Benjamin Mahler
>            Assignee: Benjamin Mahler
>
> Looks like a double comparison issue..?
> [ RUN      ] Statistics.truncate
> ../../../third_party/libprocess/src/tests/statistics_tests.cpp:58: Failure
> Expected: (Clock::now()) >= (values.get().begin()->first.secs()), actual: 1.36184e+09 vs 1.36184e+09
> ../../../third_party/libprocess/src/tests/statistics_tests.cpp:71: Failure
> Expected: (Clock::now()) >= (values.get().begin()->first.secs()), actual: 1.36193e+09 vs 1.36193e+09
> [  FAILED  ] Statistics.truncate (1 ms)
> Another flaky one:
> [ RUN      ] Statistics.archive
> ../../../third_party/libprocess/src/tests/statistics_tests.cpp:175: Failure
> Value of: values.get().empty()
>   Actual: false
> Expected: true
> [  FAILED  ] Statistics.archive (2 ms)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira