Resampled timestamps don't have constant interval

[shsms]

What happened?

The resampler uses the trigger times from a frequenz.channels.Timer as the timestamp for resampled messages. But the Timer returns the clock time at which it triggered, and not a calculated timestamp that always has a constant interval, adjusting for any delays from the rest of the program, as seen below:

>>> import asyncio
>>> from frequenz.channels.util import Timer
>>> async def test():
...   async for t in Timer(1.0): print(t)
... 
>>> asyncio.run(test())
2023-01-20 15:43:30.898930+00:00
2023-01-20 15:43:31.900304+00:00
2023-01-20 15:43:32.901836+00:00
2023-01-20 15:43:33.903355+00:00
2023-01-20 15:43:34.904885+00:00
2023-01-20 15:43:35.906479+00:00

What did you expect instead?

Timestamps in subsequent messages from the resampler should all have a constant interval, equal to the given resampling interval.

Affected version(s)

v0.16.0

Affected part(s)

Data pipeline (part:data-pipeline)

Extra information

No response

[shsms]

The Timer's behaviour of returning the clock time should ideally not change.

An easy fix would be to replace the use of Timer in the resampler with a custom implementation, that adjusts the time it sleeps based on how much time has elapsed since the last tick. But it should also be possible to add an optional setting to the Timer to implement the logic there instead.

[leandro-lucarella-frequenz]

An easy fix would be to replace the use of Timer in the resampler with a custom implementation, that adjusts the time it sleeps based on how much time has elapsed since the last tick. But it should also be possible to add an optional setting to the Timer to implement the logic there instead.

There are 2 problems here, I think:

1. The Timer doesn't adjust the next tick (I think it really should, why would you want to have a purposely drifting timer? I would be fine to keep that as an option but the default should be not to drift)
2. The resampler doesn't keep track of the window size, so even if the timer doesn't drift, the timer timestamp will probably be always slightly in the future, so the resampler should always stick its own timestamp (based on the resampling period) to generated samples, not the timestamp provided by the timer. This one is fixed by Make resampling window size constant #236.

[leandro-lucarella-frequenz]

OK, looking at the Timer implementation, I see that the timer is not started (or advanced) until you call ready() (or receive() or any derived method). I guess this makes sense, and what we really need is a periodic timer that will start when it is created and advance automatically after the timer has fired.