I personally don't touch absolute one-way-delays for those reasons, and almost always use good old RTT that does not need time sync.
If you measure RTT, you can detect when clock are unsync. If you have the sent-time, rcv-time and return-time, you can check that sent-time < rcv-time < return-time. As sent-time and return-time use the same clock, you can detect any drift bigger than RTT.
Note also that in linux, there are different types of clocks. In theory, for any type of such time measurements, you want to use CLOCK_MONOTONIC. Unfortunately, packet timestamps are in CLOCK_REALTIME...
Good luck...
Jean
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wouldn't CLOCK_MONOTONIC fail with the calculation per being two different clocks?
Doh, you are right. Another reason why absolute one-way-delays should be avoided.
I have experiments where I have weird small jumps in packet timing, I've always assumed it's due to using CLOCK_REALTIME.
Regards,
Jean
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We've had good success with linux-ptp (ptp4l & phc2sys) on a local 10g switch with GPS disciiplined oscillator in the PTP grandmaster. We're using INTC chips that have hardware timestamping. The corrections at 1 second are less than 100 nanosecond.
Bob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
if(isTripTime(stats->common)){doublebbowdto=TimeDifference(packet->sentTimeRX,packet->sentTime);doublebbowdfro=TimeDifference(packet->packetTime,packet->sentTimeTX);doubleasym=bbowdfro-bbowdto;doublebbturnaround=TimeDifference(packet->sentTimeTX,packet->sentTimeRX);doublebbadj=TimeDifference(packet->packetTime,packet->sentTimeRX);// If you measure RTT, you can detect when clock are unsync.// If you have the sent-time, rcv-time and return-time, you can check that// sent-time < rcv-time < return-time. As sent-time and return-time use// the same clock, you can detect any drift bigger than RTT. JT//// Adjust this clock A write < clock B read < Clock A read - (clock B write - clock B read)if((bbowdto<0)||((bbadj-bbturnaround)<0)){stats->bb_clocksync_error++;}reporter_update_mmm(&stats->bbowdto.total,bbowdto);reporter_update_mmm(&stats->bbowdfro.total,bbowdfro);reporter_update_mmm(&stats->bbasym.total,fabs(asym));if(stats->bbowdto_histogram){histogram_insert(stats->bbowdto_histogram,bbowdto,NULL);}if(stats->bbowdfro_histogram){histogram_insert(stats->bbowdfro_histogram,bbowdfro,NULL);}}
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I personally don't touch absolute one-way-delays for those reasons, and almost always use good old RTT that does not need time sync.
If you measure RTT, you can detect when clock are unsync. If you have the sent-time, rcv-time and return-time, you can check that sent-time < rcv-time < return-time. As sent-time and return-time use the same clock, you can detect any drift bigger than RTT.
Note also that in linux, there are different types of clocks. In theory, for any type of such time measurements, you want to use CLOCK_MONOTONIC. Unfortunately, packet timestamps are in CLOCK_REALTIME...
Good luck...
Jean
Thanks for this. Wouldn't CLOCK_MONOTONIC fail with the calculation per being two different clocks?
Last edit: Robert McMahon 2023-03-18
Doh, you are right. Another reason why absolute one-way-delays should be avoided.
I have experiments where I have weird small jumps in packet timing, I've always assumed it's due to using CLOCK_REALTIME.
Regards,
Jean
We've had good success with linux-ptp (ptp4l & phc2sys) on a local 10g switch with GPS disciiplined oscillator in the PTP grandmaster. We're using INTC chips that have hardware timestamping. The corrections at 1 second are less than 100 nanosecond.
Bob
WiFi really needs to test & measure OWDs as the paths are inherently asymmetric.
Can you double check this? I did it for the boundeback tests since this already has all the timestamps.
sorry, I think this isn't right. my first commit should be
Ok, I think this is correct.
This was added for the --bounceback test. Need to consider other OWD tests.