-
Notifications
You must be signed in to change notification settings - Fork 2k
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
xtimer_core: reduce idle time #8990
Conversation
I don't remember right now and I am too tired to examine this in detail, I believe there was some reason behind the ordering we currently have. Are there any races in the code here? |
@gebart how to test for race condition, and which timer calls exactly? I added a testcase, with different test. The periodic wakeup was firering to early. Result is still better as before, let me know if it has any benefit. Before:
After:
|
on first sight: this PR does severals things at once, at least the following:
Though all these changes might serve the same purpose, I guess fixing (x)timer on jiminy (?), it would IMHO be better to single them out into separate PRs. |
@smlng thats right. First i just wanted put the xtimer changes into this PR. |
308b2c2
to
4958b02
Compare
@smlng tried to only include relevant changes to this PR. |
85148a4
to
f11a0d6
Compare
bccdf46
to
1f3c0dc
Compare
80d2173
to
413845b
Compare
Using #8865 for timing: iotlab-m3: offset 14 us (same as before) I am running the other |
Using #8865 for timing: iotlab-m3: offset 14 us (same as before) I am running the other I only get errors for
https://gist.github.com/cladmi/3accb8837ad6d76d4c67570f42698103 |
Now when I run
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently breaking both samr21-xpro and arduino-zero with xtimer_usleep_short
test. Using an updated version of #9037
For the failed tests this can be caused by xtimer bug fixed in #9211 . For the long offsets, did you follow the procedure descriped in the readme? |
@Josar No I missed the xtimer_configure… my bad, I will do it before. If boards get stuck with this PR but is resolved by #9211, it means that this PR cannot be merged without it. However, both boards manage to execute the |
Xtimer_hang accepts an error of 10%, thus masks the problems sometimes. |
@cladmi #9211 fixes an error which could have been found with this test but was not as the test just skip the relevant parts. Thus the error is Masked. If this changes make the boards hang then it just reveals this problems. But its ok to merge this after the other as the other is much more crucial. |
@Josar in order to try to get some of the xtimer changes included for the release I will need some help from you. I spend most of my time not understanding where I am and if I am testing the right thing. To simplify reviewing and merging all the xtimer related PRs, could you do an issue where you describe all the PRs and dependencies, on implementation and testing. This would help me reviewing in the right order, because right now I am lost. Then keep the first message up to date by updating it. I think you should separate the "uncrustify" PRs, they are easy to review and merge and then simplify reviewing the "hard" stuff. Regarding this PR, I would like to split this PR in parts. The uncrustify/style related changes, the PR adding the new variables, the xtimer_configuration in a third one. Also it would be great if, by default, the behavior is kept the same as before so there is no need to test every boards before merging. |
@Josar Thank you :) I will re-read to understand the |
@cladmi rebased and heavily reworked this PR trying to solve some more issues with the xtimer implemetation. Would you mind to have a closer look? This is still WIP, but i could not provoke issues. Maybe there are some more ideas for hardening the xtimer implementation from your side! Please read the readme of |
1. Make it interrupt save. 2. Make periodic_wakeup to skip lost wakeups, solving a priodic race. 3. Remove xtimer_spin_until as this may lead to hanging conditions. 4. Improve/reduce delay of sleeps by introducing XTIMER_SHOOT_OVERHEAD, XTIMER_BACKOFF_OVERHEAD. 5. Implement a tests\xtimer_configuration whcih helps to properly set the values for the xtimer. 6. Introduce a second pin for tests/xtimer_hang to distinguish between worker 1 and 2.
Then I would take this PR as a big PR that will get split per issue fix, which is good to give an overview of final changes but not merge-able as is. As this is quite tricky to review with all platforms and parallel context (with the low timer always running and other tasks) I prefer to review the smallest possible atomic changes. And in case of an issue with one PR, one commit could be reverted which is not the case when everything is packed together. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not look in the code details and implementation but just the general change direction.
I do not like the global change with _xtimer_set_absolute
, it follows the current code implementation but for me goes in the wrong direction. As was done before, you still try to spin
in the calling function (which was for me already wrong) and do the irq handling in the calling function too, so you duplicate the handling in both calling functions. If you need it twice, why not putting it with a function that your reuse, so putting it common for both ?
And this is what _xtimer_set_absolute
should be for. With a more robust implementation of course but it would even remove the _spin
in _xtimer_set
and _xtimer_periodic_wakeup
.
It is working around the bad implementation of _xtimer_set_absolute
when it should be fixed to use without needing specific setup before calling it.
So basically I would prefer the changes inside the function than outside.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
The idle wait time for the xtimer can be reduced with this PR.
This is a improvement for platforms with slow cpu frequency, as the shoot overhead can be taken into account. It also can help to ensure that the iddle wait time in the timer ISR is as short as possible.
Following figures show the time which the xtimer core routine idles until the time is reached to shoot.
As shown it is reduced, see timing at the right side.