Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why is NeighborRateRatio not considered when measuring PTP path delay #91

Open
liu-jeff opened this issue Aug 19, 2022 · 1 comment
Open

Comments

@liu-jeff
Copy link

liu-jeff commented Aug 19, 2022

Hello, I am very sorry to bother you , but I have some confusion about this, why is NeighborRateRatio not considered when measuring PTP path delay.
54bd2941-83ee-4605-bf2c-94543bb4880b

@aaeegg
Copy link

aaeegg commented Jan 20, 2023

ptpd calculates meanPathDelay according to IEEE 1588-2008 11.4.3. The equation in IEEE 1588-2008 11.4.3 doesn't include neighbor rate ratio correction. IEEE 1588-2008 6.5.5 offers neighbor rate ratio correction of link delay as a way to reduce residence time inaccuracy in peer-to-peer transparent clocks, but doesn't require it, and doesn't suggest such correction on ordinary clocks. On the other hand, the equation in IEEE Std 802.1AS-2020 16.4.3.2 includes neighbor rate ratio correction in the mean link delay calculation. IEEE Std 802.1AS-2020 seems to strongly suggest that all PTP instances should perform neighbor rate ratio correction, although 12.5.2.4.4 allows "other means" of computing mean link delay.

So in short, I believe ptpd disregards neighbor rate ratio because ptpd implements IEEE 1588-2008 PTPv2 and not IEEE Std 802.1AS-2020 gPTP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants