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
test_protocol unittest failures on Windows #63
Comments
Great, thanks for reporting these. I also noticed some failures when running tests under tox. (I'm not sure why this makes a difference.) I'm a bit busy today, I'll try to follow up as soon as possible. |
The ailures above were produced by my work environment, an old IBM Thinkcentre with 2.8 Ghz Celeron CPU. Current lines are 488, 366, and 382. This PC produces the failures above constantly. However, I was also tested it with my (also old) MSI laptop (AMD Athlon 64 X2 Dual-Core TK-57) which produces inconsistent results.
This was a first-time run. For the subsequent test, when I wait some time, only line 505 fails. However, when I start another unittest immediately, 366 seems to fail sometimes aswell. I switch to the Windows OS on the MSI to test there too... Hmm...
At least these failures seem to be consistent on that environment. Hard to test asyncio code, that is for sure. :) |
Now I noticed I do testing while the repo is acively changing. I get back later. |
Yes, I just pushed a bunch of changes I've been working on yesterday and today. (I have limited Internet connectivity.) But I don't think they help for this issue. I can reproduce If you're running the tests on a slow machine, try increasing the value of |
I took a closer look at your report. There are several issues.
Would you mind pulling the latest commit to master, setting |
Sure, I'll do that today afternoon/evening. |
Done. Conclusions:
|
Thanks for the feedback. I just had an idea to make the tests both fast and robust: instead of using I'm working on a patch. Not only does this makes the tests look much nicer, but they should also be more deterministic and faster. Then I can increase the value of MS when I test timeouts without making the whole test suite proportionally slower. Let's see where we stand once I've completed this refactoring! |
Good idea! I wasn't aware of this benefit of |
I just pushed a series of commits that should improve the situation significantly. Feel free to test again and report your findings at your convenience. Thanks! |
Tentatively closing as fixed. |
At commit 9bdfb81 on my Windows environment:
All tests passes on same PC in ARCH Linux environment. However my Thinkcentre produces some of the filures too on ARCH Linux:
|
The second set of failures is clearly caused by the old Thinkcentre being a bit slow. With |
I would need access to a Windows machine to reproduce your first set of failures. Two causes come to mind:
|
Confirmed working with |
asyncio's clock relies on |
With the commit I just pushed, I don't see failures on Windows anymore. |
Confirmed fixed. |
Success \o/ Thanks! |
After fixing #62 there is still receive three failures. Note that these failures are identical for this repo and for my fork. Since these involving the protocol which I am not know enough yet to fix, I am dumping them to here.
Currently I am on my Linux environment:
4.0.7-2-ARCH
Python 3.4.3
64bit
If we got different failures here, I am here to help.
The text was updated successfully, but these errors were encountered: