timestamps

[31415us]

at some point we're going to need timestamps to measure time and timedifferences. we should discuss resolutions (milli-, micro-, nano-) and how to achieve synchronization.

[antoinealb]

Yeah, its time to do it. http://stream1.gifsoup.com/view1/1336353/horatio-lunettes-o.gif

[antoinealb]

More seriously : unsigned int, 32 bits, microseconds ?

[msplr]

+1 for uint32 in us

[msplr]

/** Get a timestamp in microseconds */
uint32_t os_timestamp(void);

/** Updates the timestamp and returns the difference to the previous. */
uint32_t os_timestamp_update(uint32_t *ts);

Something like that?

[31415us]

hmm what happens if you update with a past value? or more precisely what exactly are the responsibilities of os_timestamp_update?

[msplr]

uint32_t os_timestamp_update(uint32_t *ts)
{
    uint32_t diff, now;
    now = os_timestamp();
    diff = now - *ts;
    *ts = now;
    return diff;
}

I thought this would be a regular use case, so we could implement it in a simple function directly.

[antoinealb]

I think actually expanding the computation in caller code is more readable.

[antoinealb]

By the way after a bit of thinking I would split this functionality into two modules : The local timestamp in platform abstraction and the clock sync in the network / bus module. What do you think ?

[31415us]

@antoinealb yeah i agree that it's best to separate those two

[Stapelzeiger]

We neet two sorts of timestamps anyway. One monotonic for computation and one that is synced. For the monotonic we should have a function like the one nuft proposed, because it will be used a lot. We could find a clearer name for it though.

[antoinealb]

Maybe something more explicit like timestamp_diff_and_update.

[Stapelzeiger]

yes, that looks good

[msplr]

sounds good.

[msplr]

I think timestamp_diff_and_update() should also be atomic.

[Stapelzeiger]

It should be enough if the timestamp function is atomic

[antoinealb]

The timestamp function obviously has to be atomic, doesn't it ?

[Stapelzeiger]

Well, yes.