Hi,

Sure, it will slightly skew the offset, but it is quite small compared
to jitter or usual performance so not really a problem. Asymmetries like
these needs to be handled when you operate over infrastructure not
supporting timing anyway, so PON is no major difference. PTP can be
asymmetry compensated, and some implementations support that. You
typically use GNSS to measure / estimate asymmetry and compensate. Turns
out that WAN networks offer larger challenges than PON, since IP
networks does not really have any guarantee for two directions between
two nodes take the same path. In fact, for traffic engineering reasons
it can vary quite a bit in some cases. NTP and PTP will suffer the same
way from any such asymmetries / delay-differences in underlying network.
PTP was not designed for it, NTP wasn't designed for it either, but
achieved performane is lower so it is of less care.

Trying to address this require a multitude of solutions, first packet
filtering to filter out measurements with less impact from jitter, then
asymmery compensation and change that when there is reroutes. In ITU-T
we work on that under the name of ePTS.

Cheers,
Magnus

On 2025-07-24 01:25, Kapp, Francois B. via time-nuts wrote:

This is actually a very interesting question. I have the impression that
the latency with PON is much lower than with DSL and other techniques, so
for this reason I wonder if the lower latency could, to a certain degree,
compensate for the jitter?

For example, before I had GPON FTTH internet, a ping google.com took some
~12ms. Now it is quite consistently just below 7ms. So while my speed is
the same, I would guess that now the latency is smaller somehow.

On Thu, 24 Jul 2025, 21:02 Kapp, Francois B. via time-nuts, <
time-nuts@lists.febo.com> wrote:

I used to to a lot of work around analyzing and characterizing internet
latency, so I might be marginally qualified to answer this!

I imagine that the GPON induced jitter would be no worse than the queueing
induced jitter from the countless layer 2 and layer 3 hops that NTP packets
experience on their journey. A 2.5 Gbps GPON frame is 125 µs long,  which
is well below the noise floor of the of the rest of the internet,
especially if there are congested links in the path.

This page is interesting reading:
https://sites.google.com/site/amitsciscozone/gpon/gpon-fundamentals

• Keelan

On Thu, Jul 24, 2025 at 12:03 PM Kapp, Francois B. via time-nuts <
time-nuts@lists.febo.com> wrote:

Hello

here is a machine on a GPON network in a france suburban area :

ntpq -c lpeers
    remote           refid      st t when poll reach   delay   offset
 jitter

---============

0.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000
  0.001
1.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000
  0.001
2.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000
  0.001
3.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000
  0.001
+195-154-185-215 109.190.177.205  2 u  322 1024  377    2.798    0.246
  0.110
+meshflow.net    5.196.160.139    3 u   70 1024  377    6.172   -0.233
  0.417
-time.cloudflare 10.20.8.5        3 u   77 1024  377    3.373   -0.429
  0.374
+passion.bitschi 192.168.4.3      2 u  108 1024  377    7.065    0.298
  0.267
-45.13.105.44 (m 230.226.69.180   3 u  504 1024  377   16.239   -1.823
  0.648
*dns.freewebworl .PPS.            1 u 1017 1024  377   12.033    0.176
  0.164

Here is a machine on "black fiber" in paris center

ntpq -c lpeers
    remote                                   refid      st t when poll
reach   delay   offset   jitter

---====

0.debian.pool.ntp.org                   .POOL.          16 p    -  256
   0   0.0000   0.0000   0.0001
1.debian.pool.ntp.org                   .POOL.          16 p    -  256
   0   0.0000   0.0000   0.0001
2.debian.pool.ntp.org                   .POOL.          16 p    -  256
   0   0.0000   0.0000   0.0001
3.debian.pool.ntp.org                   .POOL.          16 p    -  256
   0   0.0000   0.0000   0.0001
+ciran28.fr                              134.59.1.5       3 u   49   64
   7   3.1525  -2.0954   1.4904
+bethany.fangfufu.co.uk                  192.171.1.150    2 u   54   64
   7   5.9604   0.0356   1.2179
#x.ns.gin.ntt.net                        129.250.35.222   2 u   52   64
   7  90.8017  -7.5388   1.2852
+vps-mrs1.orleans.ddnss.de               145.238.80.80    2 u   52   64
   7  11.9088  -0.6803   1.1795
*dns.freewebworld.fr                     .PPS.            1 u   50   64
   7   9.9991  -1.0038   1.1328
+web1.ciran28.fr                         82.64.45.50      2 u   52   64
   7   2.5726  -1.3235   1.5186
+time.cloudflare.com                     10.25.8.4        3 u   50   64
   7   2.0753  -1.6802   1.2405
#82-64-81-218.subs.proxad.net            131.188.3.222    2 u   53   64
   7  12.3248  -0.1797   1.3448
+ns1.univ-montp3.fr                      145.238.80.80    2 u   51   64
   7  13.7076  -1.0098   1.1377
+vps-761b8f12.vps.ovh.net                129.134.28.123   2 u   51   64
   7   5.9942  -1.5038   1.1760
+op.success.ovh                          193.190.230.37   2 u   50   64
   7   5.3664   0.0757   1.1355
#45.90.162.253                           195.13.1.153     3 u   51   64
   7  23.0761   9.3761   0.8971
2001:41d0:801:2000::acb                 .INIT.          16 u    -   64
   0   0.0000   0.0000   0.0001
2001:41d0:8:7a7d::1                     .INIT.          16 u    -   64
   0   0.0000   0.0000   0.0001
2001:41d0:701:1100::1ecc                .INIT.          16 u    -   64
   0   0.0000   0.0000   0.0001
h2.ncomputers.org                       .INIT.          16 u    -   64
   0   0.0000   0.0000   0.0001
+ntp1.omdc.pl                            210.100.177.101  2 u   47   64
   7   6.0255  -0.7889   1.0913
+109.190.177.205                         .PPS.            1 u   49   64
   7  10.1852  -1.0822   1.0509

I have no conclusion.

With fast 10GPON I am not sure that the TDM latencies are significant
compared to frame processing at the network nodes.

APTP link to a machine known to be on a network without jitter is
probably required to check for this accurately.

Is such a thing available somewhere? We can do some tests if that's easy
to setup.

Sebastien

On 24/07/2025 01:25, Kapp, Francois B. via time-nuts wrote: