On 1/8/2022 6:52 pm, Sebastian Huber wrote: > On 01/08/2022 10:48, Chris Johns wrote: >> On 1/8/2022 6:20 pm, Sebastian Huber wrote: >>> On 01/08/2022 10:16, Chris Johns wrote: >>>> On 1/8/2022 5:22 pm, Sebastian Huber wrote: >>>>> A relative CLOCK_REALTIME time out shall not be affected by CLOCK_REALTIME >>>>> changes through clock_settime(). Since our CLOCK_REALTIME is basically >>>>> just >>>>> CLOCK_MONOTONIC plus an offset, we can simply use the CLOCK_MONOTONIC >>>>> watchdog >>>>> for relative CLOCK_REALTIME time outs. >>>> Thank for this. I can confirm it works with the modified test code I >>>> attached to >>>> the ticket. I am ts-validation-no-clock-0.exe now failing on >>>> xilinx_zynq_a9_qemu >>>> but I am not sure? >>> I have to adjust the ts-validation-no-clock-0.exe if we want to fix the >>> issue >>> like this. >>> >>>> There is one issue my test changes have exposed and that is the ticks a >>>> thread >>>> sleeps for is 1 more than the requested number. >>> I think this is the expected behaviour. You should sleep at least the >>> requested >>> amount of time. >> I am using 500msec so I would expect the result to be exact? If it was >> 501msec >> then I would agree. > > What do you mean with exact? If you want to wait for 500ms, then you will wake > up in 500ms plus one clock tick interval (unless you measure the start time > exactly at the clock tick event which is very unlikely).
Yeap I agree after looking at this again. You have to account for the extra tick. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
