[core] improve by two the ttimer resolution

[ferdymercury]

Fixes #8582

[pcanal]

Do we understand why the result of 'only' cutting in half as such a dramatic effects (in #8582 it seems to imply (but the change was seemingly slightly different) that it goes from 'wasting' 10ms per loop to wasting none?

What is the actually effect on the original reported problem on this PR?

[ferdymercury]

Do we understand why the result of 'only' cutting in half as such a dramatic effects (in #8582 it seems to imply (but the change was seemingly slightly different) that it goes from 'wasting' 10ms per loop to wasting none?

What is the actually effect on the original reported problem on this PR?

Well, I guess alignment plays a role, if you had bad luck you were always sleeping the 10ms until the next check. When removing that extra 10ms, sometimes it was exactly 50, sometimes 53, others 52.
So the idea is to reduce the general latency so that the Thread checks more often if there is stuff to do.
In any case, I switched to std::thread which does not have this problem, so I am also fine with closing the issue as won't fix.

[pcanal]

When removing that extra 10ms,

This PR, does not remove the 10ms but reduce it to 5ms (and 5+5 in one of the case). The question I have is whether 5ms is good enough or need to be lower ....

[github-actions]

Test Results

    22 files      22 suites   3d 20h 5m 38s ⏱️
 3 704 tests  3 704 ✅ 0 💤 0 ❌
79 555 runs  79 555 ✅ 0 💤 0 ❌

Results for commit 4f47748.

[ferdymercury]

When removing that extra 10ms,

This PR, does not remove the 10ms but reduce it to 5ms (and 5+5 in one of the case). The question I have is whether 5ms is good enough or need to be lower ....

Tthreadtimer had a 10+10ms as rate. Back then I changed to 10+0 and it worked fine. Now i changed to 5+5 and additionally changed def resolution to 5.
Whether it's enough depends on the application I guess...