search

Avnu / OpenAvnu

OpenAvnu - an Avnu sponsored repository for Time Sensitive Network (TSN and AVB) technology
471 stars 290 forks source link

HWTimestamper_settime (OID_INTEL_SET_SYSTIM) implementation #413

Open ibrahimdanish opened 8 years ago

ibrahimdanish commented 8 years ago

Hi,

I would like know if it is possible to use windows time to set the network interface time instead of using its counter (if somebody has used OID_INTEL_SET_SYSTIM to implement HWTimestamper_settime()) function which is missing in the windows_hal file right now. Because I am experimenting a gptp domain where the fixed master will use its windows time to time stamp the messages and all the fixed slaves will adjust there windows clock accordingly.

Any suggestions?

Ibrahim

andrew-elder commented 8 years ago

You haven't said what accuracy you are looking for between systems. If you only need 100ms or so accuracy between systems it would probably work. I don't know about the missing OID interface....

ibrahimdanish commented 8 years ago

Default timer resolution on Windows is 15.6 ms which can be brought down to 1ms (I read somewhere) and is acceptable to us. So if master/slave can set the network interface time in nanoseconds w.r.t PTP epoch (1 January 1970 00:00:00) where micro and nano parts are set to '0', I believe we can sync the slaves to 1ms accuracy w.r.t master.

pinealservo commented 8 years ago

If the best resolution you can get from that clock is 1ms, that is probably why support for it is currently missing. The gPTP spec (802.1AS) requires much higher resolution--I think 25MHz is the slowest acceptable timestamp counter rate. As most of the development here has been in the context of gPTP and AVB, which can assume much higher-resolution timestamps, I don't know what the effect of the resulting measurement noise in low-res timestamps would do to the clock servo code. It might work; it might not.

I don't know IEEE 1588 PTP as well as 802.1AS gPTP (gPTP can technically be considered a profile of PTP, but 802.1AS is a largely standalone specification), but I think it may explicitly support lower-resolution timestamps than gPTP as well as supporting networks with switches that don't natively speak PTP. If there is an existing Windows PTP implementation, it might do what you need out-of-the-box. If not, I would not be opposed to making it possible to configure our gPTP daemon with lower-res timestamps or other PTP features, but I don't think any such support is on anyone's roadmap right now, and it would probably have to be a compile-time option if it involved serious code-size increases or significant clock servo changes.