The offset may be a function of distance.
Try this experiment:

Set up your ntp.conf file to have three servers (all examples assume you
are located in Eastern USA):
1.  A relatively unused stratum 1 or 2 server as close to you as possible.
2.  A relatively unused stratum 1 or 2 server about 1,000 miles away (e.g., 
    ntp.melancthon.net)
3.  A relatively unused stratum 1 or 2 server more than 2,000 miles away
    (e.g., ntp1.tp.pl, ntp2.tp.pl, time.coi.pw.edu.pl, ntp.certum.pl).

On my computer, the offset is proportional to distance:

Remote                 Refid Stratum            Type        When    Poll
Reach  Delay      Offset        Jitter
BR-350P                 GPS     0              Local clock      7       16
017     0.000    -17.653        2.345
FreeNAS            time-c.nist.gov  2          Unicast server   16      16
017     0.238      0.008        0.037
nist1-pa.ustiming.org     ACTS  1              Unicast server   15      16
017     28.844   0.135  3.158
2a01:1102:0:b::2                ATOM    1              Unicast server   16
16      017     120.732 -5.145  2.151
2a01:1100:1::2          ATOM    1              Unicast server   15      16
017     128.756 -3.931  4.635
213.222.200.99          PPS           1        Unicast server   13      16
017     110.727 -0.968  4.119
ntp.coi.pw.edu.pl              OCX0           1        Unicast server   14
16      017     122.100 -4.253  0.584
serenity.melancthon.net india.colorado.edu 2     Unicast server 35      32
003     53.520   2.019  3.556

Charles Elliott

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On
> Behalf Of mike cook
> Sent: Thursday, September 11, 2014 2:08 PM
> To: Questions List
> Subject: Re: [ntp:questions] Compensating for asymmetric delay on a
> per-peer/server basis?
> 
> 
> Le 11 sept. 2014 à 18:48, Rob a écrit :
> 
> > Paul <[email protected]> wrote:
> >> As an aside has anyone tried shaping traffic to make the
> >> upstream/downstream latencies similar?  It would seem more efficient
> >> to apply network solutions to network problems if possible.
> >
> > That does not work.  The asymmetry is not caused by traffic but by
> > modem parameters.
> 
>   Did I miss something? The OP did not offer any evidence that there
> was path asymmetry, just that there was an unexplained offset between
> two GPS sync'd servers. It is often not possible to identify the origin
> of such an offset, but it would help if the suggested feature was
> implemented to take care of these corner cases. I saw that Dr Mills was
> in agreement back in 2005 but that the implementation is complex. If
> anyone wants a subject for an MSc project, this could be it.
> 
> >
> > _______________________________________________
> > questions mailing list
> > [email protected]
> > http://lists.ntp.org/listinfo/questions
> _______________________________________________
> questions mailing list
> [email protected]
> http://lists.ntp.org/listinfo/questions

_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions

Reply via email to