clock_gettime(CLOCK_MONOTONIC, struct timespec*) equivalent for c#

[Daniel Kay]

Hello folks!

I am new to c# and want to port a c++ library to c#. I need an accurate
timesource which has at least millisecond resolution. A clock, which
counts the seconds/milliseconds since booting windows would be great. A
clock which may jump in time during runtime would lead to false result.
Under Linux and c++ I used the function clock_gettime(CLOCK_MONOTONIC,
struct timespec*).

Any suggestions?

CU,
Daniel

 

[Daniel Kay]

Hello again,
after further searching on the net I found the class
System.Diagnostics.StopWatch. I can start that stopwatch when my
library/application starts, and use the Elapsed Property. Any doubts
that this is a good idea? Or ar there better ways?

CU,
Daniel

 

[Peter Duniho]

Hello again,
after further searching on the net I found the class
System.Diagnostics.StopWatch. I can start that stopwatch when my
library/application starts, and use the Elapsed Property. Any doubts
that this is a good idea? Or ar there better ways?

A Stopwatch instance would be fine. You could also just use
DateTime.Now to obtain the current time, subtracting from that a
previously acquired time to obtain a TimeSpan value. I would say those
are the two most common time-keeping techniques.

You should keep in mind that even though Stopwatch and DateTime
ostensibly provide millisecond precision, they aren't actually accurate
to the nearest millisecond. The nature of Windows thread scheduling
will prevent you from getting timing information more accurate than to
tens of milliseconds.

Finally, note that there are actually timer classes (at least three
that I'm aware of). Depending on what the original code did with the
time information, it may be better to use a timer. In particular, you
probably would not want to poll the current time on a very frequent
basis (e.g. in a tight loop).

Pete

 

[Daniel Kay]

A Stopwatch instance would be fine. You could also just use
DateTime.Now to obtain the current time, subtracting from that a
previously acquired time to obtain a TimeSpan value. I would say those
are the two most common time-keeping techniques.

You should keep in mind that even though Stopwatch and DateTime
ostensibly provide millisecond precision, they aren't actually accurate
to the nearest millisecond. The nature of Windows thread scheduling
will prevent you from getting timing information more accurate than to
tens of milliseconds.

Finally, note that there are actually timer classes (at least three that
I'm aware of). Depending on what the original code did with the time
information, it may be better to use a timer. In particular, you
probably would not want to poll the current time on a very frequent
basis (e.g. in a tight loop).

Thanks for your reply. The library I like to port receives data from the
serial port in a message based protocol. I save every received byte in
an object, which retrieves the current timestamp. When a message is
completly received I check if any abnormal delays occured during
transmission by calculating the timespan between the first and last
received byte. Knowing the transfer speed I can decide whether to accept
and process the message or not. If for instance a message took 44ms to
transmit, but I calculated an expected time of 12ms, I ignore the
message. I am not so strict on the thresholds, because the UART may
delay the interrupt if the FIFO isn't totally filled up. But at the end
I don't want to use the systemtime, because the user may change the time
while I receive a message and then messages would be dropped which
weren't received delayed.

The serialport is usally set at 19200bps and data isn't received all the
time. So I do not expect that polling the stopwatch time does use to
much system resources. Thanks again for your comments. It seems that
it's not the worst solution I have found.

CU,
Daniel

CU,
Daniel

 

[Peter Duniho]

[...]
The serialport is usally set at 19200bps and data isn't received all
the time. So I do not expect that polling the stopwatch time does use
to much system resources. Thanks again for your comments. It seems that
it's not the worst solution I have found.

No, it should work pretty well for your purposes. Do keep in mind that
in Windows tracking the time this way isn't going to provide a reliable
distinction between a 12ms delay and a 44ms delay. The 32ms difference
is barely within the granularity the thread scheduler allows; a delay
in transmission that small could easily be due simply to the fact that
the thread receiving the data didn't get run any sooner than that.

Also, rather than getting a timestamp for every byte received, you may
find it's more efficient to just start the Stopwatch at the first byte,
and then check the elapsed time at the last byte.

Other than that, I think that Stopwatch would probably be fine for what
you're talking about.

Pete