Hi Rainer; On Mon, Mar 20, 2023 at 10:31 PM Rainer Jung <rainer.j...@kippdata.de> wrote: > > Am 17.03.23 um 15:11 schrieb Yann Ylavic: > > > > Hm OK, these commits were meant to address that precisely.. > > It looks like SLES has some special epoll_wait() implementation that > > can return before the timeout. Could you printf the t2 - t1 diff in > > the justsleep() test after apr_pollset_poll()? It could be interesting > > to know if it's almost 200ms or close to zero (the latter could mean > > epoll_wait() does not block if there is no fd in the pollset, which is > > the case in this test). > > The observed time delta on this platform is between 197 and 198.5 ms > instead of somewhat above 200ms. I should note it is an old patch level > of SLES 11 using kernel 2.6.32.12-0.7. > > There are some old informations about the rounding of the timeout: > > https://linux-fsdevel.vger.kernel.narkive.com/9jp0o6FA/bug-epoll-wait-timeout-is-shorter-than-requested
Thanks for looking. Well, it seems that there is no guarantee of a minimal timeout on this system. There is something fishy though, the only change w.r.t. before is the millisecond round _up_.. > > On this system HZ is 100, so a jiffie is 10ms and probably this means it > should suffice to accept 200-10=190ms as the minimum sleep time. Is there something I can #ifdef (or check at configure/run time) for SLELS11 or the kernel? This would document in the test that a minimal timeout is usually expected, but on this platform/kernel. Or I'll use 190ms for everyone, which looks "unfair". Regards; Yann.
