Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
dhardy opened this issue Nov 18, 2017 · 6 comments
Closed

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

dhardy opened this issue Nov 18, 2017 · 6 comments

Comments

@dhardy
Copy link
Owner

dhardy commented Nov 18, 2017

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
Copy link
Owner Author

dhardy commented Nov 19, 2017

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

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

@pitdicker
Copy link

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
Copy link

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
Copy link
Owner Author

dhardy commented Nov 20, 2017

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.

dhardy added a commit that referenced this issue Nov 20, 2017
Workaround #55: don't run nightly tests on darwin
@pitdicker
Copy link

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
Copy link

pitdicker commented Nov 21, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants