Changing Time stamps from Monotonic to Real-Time
-
Hello,
This is probably more of a question that is probably designed to make everything on the voxl2 stop working correctly but I am going to ask it anyways.
What would happen if we changed the code to use the real-time clock instead of Monotonic for voxl-camera-server and the voxl-imu-server?
Would the other services not function correctly? Would they have to also be changed to Real-time clocks? Is everything going to work smoothly like before?
Not sure where IMU-server is located, otherwise I would try it out and post here but I see Camera server can access real-time but it is not used.
Thank you for your time,
Aaron Porter -
Hello,
This is probably more of a question that is probably designed to make everything on the voxl2 stop working correctly but I am going to ask it anyways.
What would happen if we changed the code to use the real-time clock instead of Monotonic for voxl-camera-server and the voxl-imu-server?
Would the other services not function correctly? Would they have to also be changed to Real-time clocks? Is everything going to work smoothly like before?
Not sure where IMU-server is located, otherwise I would try it out and post here but I see Camera server can access real-time but it is not used.
Thank you for your time,
Aaron Porter@Aaron-Porter Why would you want to do that?
-
@Aaron-Porter Why would you want to do that?
A second device use NTP + PPS for time sync. the problem is that the second device uses the Real-Time clock when time stamping its data. The goal is to sync up the data from the second device with the camera-server, and IMU data generated but the VOXL2. The Problem is that camera-server and imu-server use Monotonic. There is an obvious offset between real-time and monotonic but that varies from the offset +/- 150 ms. This wouldn't be a huge deal but using that data with that level of deviation cause problems with the postprocessing.
So the current thought is if it is possible to just use the real-time instead of monotonic then there will still be an offset but should be far more consistent especially when using Pulse-per-second (PPS).
Thank you,
Aaron Porter -
A second device use NTP + PPS for time sync. the problem is that the second device uses the Real-Time clock when time stamping its data. The goal is to sync up the data from the second device with the camera-server, and IMU data generated but the VOXL2. The Problem is that camera-server and imu-server use Monotonic. There is an obvious offset between real-time and monotonic but that varies from the offset +/- 150 ms. This wouldn't be a huge deal but using that data with that level of deviation cause problems with the postprocessing.
So the current thought is if it is possible to just use the real-time instead of monotonic then there will still be an offset but should be far more consistent especially when using Pulse-per-second (PPS).
Thank you,
Aaron Porter@Aaron-Porter Using CLOCK_REALTIME can be bad because it can move around. That can lead to errors when the clock jumps and it makes it seem like a deadline has passed that hasn't, etc. So, it would be much better if the application using CLOCK_REALTIME switches to CLOCK_MONOTONIC instead.
-
@Aaron-Porter Using CLOCK_REALTIME can be bad because it can move around. That can lead to errors when the clock jumps and it makes it seem like a deadline has passed that hasn't, etc. So, it would be much better if the application using CLOCK_REALTIME switches to CLOCK_MONOTONIC instead.
Sorry for the delay I had to do some research since I didn't fully understand how deadlines for Real Time clocks worked and why a Real-Time Clock might skip/jump other than for reasons like Daylight savings.
Basically since RTC is known for jumping ahead from time to time this will cause other voxl-services to believe that they are late one performing a task but the clock just jumped ahead. If we are not using a voxl2 connected to the internet or GPS then this shouldn't pose a problem? The reason I am asking is because the information I did find pointed to jumps being cased by NTP, Battery problems, or temperature.
I am guessing the most likely cause for a jump is temperature.
Thank you for your time,
Aaron Porter -
Sorry for the delay I had to do some research since I didn't fully understand how deadlines for Real Time clocks worked and why a Real-Time Clock might skip/jump other than for reasons like Daylight savings.
Basically since RTC is known for jumping ahead from time to time this will cause other voxl-services to believe that they are late one performing a task but the clock just jumped ahead. If we are not using a voxl2 connected to the internet or GPS then this shouldn't pose a problem? The reason I am asking is because the information I did find pointed to jumps being cased by NTP, Battery problems, or temperature.
I am guessing the most likely cause for a jump is temperature.
Thank you for your time,
Aaron Porter@Aaron-Porter Most likely jump is due to NTP aligning the clock. The other device that is time stamping using real time clock really should move to monotonic.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login