Ping test fails because of Windows time precision #214
Comments
DifferentialOrange
added
bug
DifferentialOrange
added a commit
that referenced
this issue
Mar 22, 2022
Ping test started to fail (in ~70% cases) after Windows CI migration from Appveyor to GitHub Actions. As a part of this migration, the test Tarantool instance was changed from an instance started on a remote Linux server to an instance started on the same Windows server under WSL. Thus, request time has shortened and it supposedly caused the ping test to fail. Python documentation [1] declares that ...though the time is always returned as a floating point number, not all systems provide time with a better precision than 1 second... Particularly, StackOverflow answer [2] argues that For Linux and Mac precision is +- 1 microsecond or 0.001 milliseconds. Python on Windows uses +- 16 milliseconds precision due to clock implementation problems due to process interrupts. based on Windows documentation [3]. Assuming that ping requests between the same server services can easily be under 1 ms, it caused the test to fail. This patch adds skip for the flaky test, refer to #214 for further development. 1. https://docs.python.org/3/library/time.html#time.time 2. https://stackoverflow.com/a/1938096/11646599 3. https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/high-resolution-timers Follows up #182, part of #214
DifferentialOrange
added a commit
that referenced
this issue
Mar 22, 2022
Ping test started to fail (in ~70% cases) after Windows CI migration from Appveyor to GitHub Actions. As a part of this migration, the test tarantool instance was changed from an instance started on a remote Linux server to an instance started on the same Windows server under WSL. Thus, request time has shortened and it supposedly caused the ping test to fail. Python documentation [1] declares that ...though the time is always returned as a floating point number, not all systems provide time with a better precision than 1 second... Particularly, StackOverflow answer [2] argues that For Linux and Mac precision is +- 1 microsecond or 0.001 milliseconds. Python on Windows uses +- 16 milliseconds precision due to clock implementation problems due to process interrupts. based on Windows documentation [3]. Assuming that ping requests between the same server services can easily be under 1 ms, it caused the test to fail. This patch adds skip for the flaky test, refer to #214 for further development. 1. https://docs.python.org/3/library/time.html#time.time 2. https://stackoverflow.com/a/1938096/11646599 3. https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/high-resolution-timers Follows up #182, part of #214
Merged
DifferentialOrange
added a commit
that referenced
this issue
Mar 22, 2022
Ping test started to fail (in ~70% cases) after Windows CI migration from Appveyor to GitHub Actions. As a part of this migration, the test tarantool instance was changed from an instance started on a remote Linux server to an instance started on the same Windows server under WSL. Thus, request time has shortened and it supposedly caused the ping test to fail. Python documentation [1] declares that ...though the time is always returned as a floating point number, not all systems provide time with a better precision than 1 second... Particularly, StackOverflow answer [2] argues that For Linux and Mac precision is +- 1 microsecond or 0.001 milliseconds. Python on Windows uses +- 16 milliseconds precision due to clock implementation problems due to process interrupts. based on Windows documentation [3]. Assuming that ping requests between the same server services can easily be under 1 ms, it caused the test to fail. This patch adds skip for the flaky test, refer to #214 for further development. 1. https://docs.python.org/3/library/time.html#time.time 2. https://stackoverflow.com/a/1938096/11646599 3. https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/high-resolution-timers Follows up #182, part of #214
DifferentialOrange
added a commit
that referenced
this issue
Mar 22, 2022
Ping test started to fail (in ~70% cases) after Windows CI migration from Appveyor to GitHub Actions. As a part of this migration, the test tarantool instance was changed from an instance started on a remote Linux server to an instance started on the same Windows server under WSL. Thus, request time has shortened and it supposedly caused the ping test to fail. Python documentation [1] declares that ...though the time is always returned as a floating point number, not all systems provide time with a better precision than 1 second... Particularly, StackOverflow answer [2] argues that For Linux and Mac precision is +- 1 microsecond or 0.001 milliseconds. Python on Windows uses +- 16 milliseconds precision due to clock implementation problems due to process interrupts. based on Windows documentation [3]. Assuming that ping requests between the same server services can easily be under 1 ms, it caused the test to fail. This patch adds skip for the flaky test, refer to #214 for further development. 1. https://docs.python.org/3/library/time.html#time.time 2. https://stackoverflow.com/a/1938096/11646599 3. https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/high-resolution-timers Follows up #182, part of #214
DifferentialOrange
added a commit
that referenced
this issue
Mar 22, 2022
Ping test started to fail (in ~70% cases) after Windows CI migration from Appveyor to GitHub Actions. As a part of this migration, the test tarantool instance was changed from an instance started on a remote Linux server to an instance started on the same Windows server under WSL. Thus, request time has shortened and it supposedly caused the ping test to fail. Python documentation [1] declares that ...though the time is always returned as a floating point number, not all systems provide time with a better precision than 1 second... Particularly, StackOverflow answer [2] argues that For Linux and Mac precision is +- 1 microsecond or 0.001 milliseconds. Python on Windows uses +- 16 milliseconds precision due to clock implementation problems due to process interrupts. based on Windows documentation [3]. Assuming that ping requests between the same server services can easily be under 1 ms, it caused the test to fail. This patch adds skip for the flaky test, refer to #214 for further development. 1. https://docs.python.org/3/library/time.html#time.time 2. https://stackoverflow.com/a/1938096/11646599 3. https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/high-resolution-timers Follows up #182, part of #214
DifferentialOrange
added a commit
that referenced
this issue
Mar 22, 2022
Ping test started to fail (in ~70% cases) after Windows CI migration from Appveyor to GitHub Actions. As a part of this migration, the test tarantool instance was changed from an instance started on a remote Linux server to an instance started on the same Windows server under WSL. Thus, request time has shortened and it supposedly caused the ping test to fail. Python documentation [1] declares that ...though the time is always returned as a floating point number, not all systems provide time with a better precision than 1 second... Particularly, StackOverflow answer [2] argues that For Linux and Mac precision is +- 1 microsecond or 0.001 milliseconds. Python on Windows uses +- 16 milliseconds precision due to clock implementation problems due to process interrupts. based on Windows documentation [3]. Assuming that ping requests between the same server services can easily be under 1 ms, it caused the test to fail. This patch adds skip for the flaky test, refer to #214 for further development. 1. https://docs.python.org/3/library/time.html#time.time 2. https://stackoverflow.com/a/1938096/11646599 3. https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/high-resolution-timers Follows up #182, part of #214
DifferentialOrange
added a commit
that referenced
this issue
Mar 30, 2022
Ping test started to fail (in ~70% cases) after Windows CI migration from Appveyor to GitHub Actions. As a part of this migration, the test tarantool instance was changed from an instance started on a remote Linux server to an instance started on the same Windows server under WSL. Thus, request time has shortened and it supposedly caused the ping test to fail. Python documentation [1] declares that ...though the time is always returned as a floating point number, not all systems provide time with a better precision than 1 second... Particularly, StackOverflow answer [2] argues that For Linux and Mac precision is +- 1 microsecond or 0.001 milliseconds. Python on Windows uses +- 16 milliseconds precision due to clock implementation problems due to process interrupts. based on Windows documentation [3]. Assuming that ping requests between the same server services can easily be under 1 ms, it caused the test to fail. This patch adds skip for the flaky test, refer to #214 for further development. 1. https://docs.python.org/3/library/time.html#time.time 2. https://stackoverflow.com/a/1938096/11646599 3. https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/high-resolution-timers Follows up #182, part of #214
DifferentialOrange
added a commit
that referenced
this issue
Mar 30, 2022
Ping test started to fail (in ~70% cases) after Windows CI migration from Appveyor to GitHub Actions. As a part of this migration, the test tarantool instance was changed from an instance started on a remote Linux server to an instance started on the same Windows server under WSL. Thus, request time has shortened and it supposedly caused the ping test to fail. Python documentation [1] declares that ...though the time is always returned as a floating point number, not all systems provide time with a better precision than 1 second... Particularly, StackOverflow answer [2] argues that For Linux and Mac precision is +- 1 microsecond or 0.001 milliseconds. Python on Windows uses +- 16 milliseconds precision due to clock implementation problems due to process interrupts. based on Windows documentation [3]. Assuming that ping requests between the same server services can easily be under 1 ms, it caused the test to fail. This patch adds skip for the flaky test, refer to #214 for further development. 1. https://docs.python.org/3/library/time.html#time.time 2. https://stackoverflow.com/a/1938096/11646599 3. https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/high-resolution-timers Follows up #182, part of #214
DifferentialOrange
added a commit
that referenced
this issue
Mar 30, 2022
Ping test started to fail (in ~70% cases) after Windows CI migration from Appveyor to GitHub Actions. As a part of this migration, the test tarantool instance was changed from an instance started on a remote Linux server to an instance started on the same Windows server under WSL. Thus, request time has shortened and it supposedly caused the ping test to fail. Python documentation [1] declares that ...though the time is always returned as a floating point number, not all systems provide time with a better precision than 1 second... Particularly, StackOverflow answer [2] argues that For Linux and Mac precision is +- 1 microsecond or 0.001 milliseconds. Python on Windows uses +- 16 milliseconds precision due to clock implementation problems due to process interrupts. based on Windows documentation [3]. Assuming that ping requests between the same server services can easily be under 1 ms, it caused the test to fail. This patch adds skip for the flaky test, refer to #214 for further development. 1. https://docs.python.org/3/library/time.html#time.time 2. https://stackoverflow.com/a/1938096/11646599 3. https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/high-resolution-timers Follows up #182, part of #214
DifferentialOrange
added a commit
that referenced
this issue
Mar 31, 2022
Ping test started to fail (in ~70% cases) after Windows CI migration from Appveyor to GitHub Actions. As a part of this migration, the test tarantool instance was changed from an instance started on a remote Linux server to an instance started on the same Windows server under WSL. Thus, request time has shortened and it supposedly caused the ping test to fail. Python documentation [1] declares that ...though the time is always returned as a floating point number, not all systems provide time with a better precision than 1 second... Particularly, StackOverflow answer [2] argues that For Linux and Mac precision is +- 1 microsecond or 0.001 milliseconds. Python on Windows uses +- 16 milliseconds precision due to clock implementation problems due to process interrupts. based on Windows documentation [3]. Assuming that ping requests between the same server services can easily be under 1 ms, it caused the test to fail. This patch adds skip for the flaky test, refer to #214 for further development. 1. https://docs.python.org/3/library/time.html#time.time 2. https://stackoverflow.com/a/1938096/11646599 3. https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/high-resolution-timers Follows up #182, part of #214
DifferentialOrange
added a commit
that referenced
this issue
Mar 31, 2022
Ping test started to fail (in ~70% cases) after Windows CI migration from Appveyor to GitHub Actions. As a part of this migration, the test tarantool instance was changed from an instance started on a remote Linux server to an instance started on the same Windows server under WSL. Thus, request time has shortened and it supposedly caused the ping test to fail. Python documentation [1] declares that ...though the time is always returned as a floating point number, not all systems provide time with a better precision than 1 second... Particularly, StackOverflow answer [2] argues that For Linux and Mac precision is +- 1 microsecond or 0.001 milliseconds. Python on Windows uses +- 16 milliseconds precision due to clock implementation problems due to process interrupts. based on Windows documentation [3]. Assuming that ping requests between the same server services can easily be under 1 ms, it caused the test to fail. This patch adds skip for the flaky test, refer to #214 for further development. 1. https://docs.python.org/3/library/time.html#time.time 2. https://stackoverflow.com/a/1938096/11646599 3. https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/high-resolution-timers Follows up #182, part of #214
DifferentialOrange
added a commit
that referenced
this issue
Mar 31, 2022
Ping test started to fail (in ~70% cases) after Windows CI migration from Appveyor to GitHub Actions. As a part of this migration, the test tarantool instance was changed from an instance started on a remote Linux server to an instance started on the same Windows server under WSL. Thus, request time has shortened and it supposedly caused the ping test to fail. Python documentation [1] declares that ...though the time is always returned as a floating point number, not all systems provide time with a better precision than 1 second... Particularly, StackOverflow answer [2] argues that For Linux and Mac precision is +- 1 microsecond or 0.001 milliseconds. Python on Windows uses +- 16 milliseconds precision due to clock implementation problems due to process interrupts. based on Windows documentation [3]. Assuming that ping requests between the same server services can easily be under 1 ms, it caused the test to fail. This patch adds skip for the flaky test, refer to #214 for further development. 1. https://docs.python.org/3/library/time.html#time.time 2. https://stackoverflow.com/a/1938096/11646599 3. https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/high-resolution-timers Follows up #182, part of #214
I agree. Let's adjust the test. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See #213 PR. The issue is as follows: ping test started to fail (in ~70% cases) after I migrated Windows CI from Appveyor to GitHub Actions. As a part of this migration, the test Tarantool instance was changed from an instance started on a remote Linux server to an instance started on the same Windows server under WSL. Thus, request time has shortened and it supposedly caused the ping test to fail.
Python documentation declares that
Particularly, this StackOverflow answer argues that
based on Windows documentation.
Assuming that ping requests between the same server services can easily be under 1 ms, it caused the test to fail.
I see two ways to "solve" this issue:
The second approach is more time-consuming and I'm not sure there are any users that really need this to be fixed. So I think it should be the first one until someone interested in the second one appears.
The text was updated successfully, but these errors were encountered: