search

dhardy / rand

http://doc.rust-lang.org/rand
Other
2 stars 2 forks source link

Fix / suppress JitterRng x86_64-apple-darwin test? #55

Closed dhardy closed 6 years ago

dhardy commented 6 years ago

This CI run failed due to CoarseTimer: https://travis-ci.org/dhardy/rand/jobs/303686167

---- gen_u64_jitter stdout ----

    thread 'gen_u64_jitter' panicked at 'called `Result::unwrap()` on an `Err` value: Error { kind: Unavailable, msg: "timer jitter failed basic quality tests", cause: Some(CoarseTimer) }', src/libcore/result.rs:906:4

note: Run with `RUST_BACKTRACE=1` for a backtrace.

---- init_jitter stdout ----

    thread 'init_jitter' panicked at 'called `Result::unwrap()` on an `Err` value: Error { kind: Unavailable, msg: "timer jitter failed basic quality tests", cause: Some(CoarseTimer) }', src/libcore/result.rs:906:4

I'm a bit surprised that it failed on a common platform. Note that this test is part of the benchmark, which is only run in nightly builds, of which we only have two. Should we add regular tests? Should we simply not test JitterRng because we can't expect it to run on all platforms?

dhardy commented 6 years ago

Experiment: which platforms fail? https://travis-ci.org/dhardy/rand/builds/304256548

Result: from the platforms we test, only x64_64-apple-darwin.

pitdicker commented 6 years ago

It is a bit strange, but I didn't add test to JitterRng for a reason. The unoptimised code with all the debug checks messes up the timer measurements. The intervals are much higher and more constant. Should have added a comment saying so...

pitdicker commented 6 years ago

I now see it is part of the benchmarks. That is strange! I wonder if it happens on real macs, or somehow depends on Travis' machines.

dhardy commented 6 years ago

Yes, I wonder. It could simply be that std::time::SystemTime uses a low-precision API.

The FreeBSD nightly failed too (unknown error). Whatever, we can make do with just one nightly test.

pitdicker commented 6 years ago

The documentation of jitterentropy say clock_gettime on Mac OS increments in steps of 1000, and that we should be using mach_absolute_time.

std::time::SystemTime uses clock_gettime, while std::time::Instant uses mach_absolute_time. But there is no way to get the raw values out of an Instant, so I think we have to call mach_absolute_time ourselves.

I will make a PR and see how it goes (can't test because I have not Apple device).

pitdicker commented 6 years ago

I would not add a FreeBSD nightly for now. Nightly rustc breaks once in a while because it is not tier 1, I think?