From: Eric Wong Date: 2017-06-02T20:52:54+00:00 Subject: [ruby-core:81539] Re: [Ruby trunk Bug#13624] MinGW - TestIO#test_copy_stream_no_busy_wait - new failure Greg.mpls@gmail.com wrote: > Bug #13624: MinGW - TestIO#test_copy_stream_no_busy_wait - new failure > https://bugs.ruby-lang.org/issues/13624 > Today's MinGW build had a new failure, one that I don't recall seeing before. Yes, it is a new test which already had some problems with lower clock resolution systems [ruby-core:81427] I admit it is a tricky test; and made trickier by the desire to have shorter tests in our test suite. > 88) Failure: > TestIO#test_copy_stream_no_busy_wait [E:/GitHub/ruby/test/ruby/test_io.rb:539]: > r58534 [ruby-core:80969] [Backport #13533]. > Expected 0.01599999999996271 to be <= 0.013757898662006482. > ``` Curious, do you know what the kernel timer resolution is on your system? For example; old Linux was always 100 Hz, but modern defaults are 250 Hz (via CONFIG_HZ in the kernel build), and 300 Hz and 1000 Hz are allowed for people who need higher resolution (for audio or other low-latency purpose). Also, r58935 changed Process.times to use the getrusage syscall for better resolution on Linux and *BSD; but maybe that is a regression on Win32... However; I notice gc.c::getrusage_time has a _WIN32 implementation which does not use getrusage; so I also wonder if you can try getting Process.times to use that. > From the assert `assert_cpu_usage_low`, it seems like a test that might be kind of arbitrary, especially when a user (or the OS) might be doing another task at the exact same time. Also, I'm not quite sure how `0.11` relates to the two numbers shown in the failure... I tried to increase the number to work with 100 Hz kernels and 100ms sleep. But maybe that is not enough for other kernels. I'll probably change it to the actual assert method to have a lower bound for time; since writing a short test to test CPU usage is challenging (and long tests are annoying...) > Again, I've never seen it before, and I'm ignoring it. I will add a minimum bound to assert_cpu_usage_low; but I also suggest you take a look at the Process.times implementation on Win32 to see if that can be improved. Unsubscribe: