Is the time from the GPS receiver bad ? - NTP

This is a discussion on Is the time from the GPS receiver bad ? - NTP ; >From time to time the ntpq -pe output from my servers looks like this: remote refid st t when poll reach delay offset jitter ================================================== ============================ +GPS_NMEA(1) .GPS. 0 l 52 64 377 0.000 0.000 0.004 ptbtime1.ptb.de .PTB. 1 u ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Is the time from the GPS receiver bad ?

  1. Is the time from the GPS receiver bad ?

    >From time to time the ntpq -pe output from my servers looks like this:

    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    +GPS_NMEA(1) .GPS. 0 l 52 64 377 0.000 0.000
    0.004
    ptbtime1.ptb.de .PTB. 1 u 75 256 377 155.060 -48.458
    35.782
    ntps1-1.cs.tu-b .PPS. 1 u 91 256 377 151.487 -47.099
    1.731
    ntp-p1.obspm.fr .1PPS. 1 u 11 256 377 123.504 -22.762
    19.197
    gps-2.mit.edu .GPS. 1 u 34 256 377 246.793 -49.433
    3.131
    oPPS(1) .PPS. 0 l 4 16 377 0.000 0.000
    0.004
    ptbtime2.ptb.de .PTB. 1 u 38 256 377 157.004 -47.865
    2.205
    gps-1.mit.edu .GPS. 1 u 24 256 377 239.559 -38.903
    31.765

    The question is: is it the time received from the GPS receiver bad ? I
    suppose a network problem (upstream delay different from downstream
    delay) but how may I bypass this problem - for the moment I have the
    noselect for all external servers (without the noselect option the
    server will reject the time from the GPS receiver).

    Thanks !


  2. Re: Is the time from the GPS receiver bad ?

    Eugen COCA wrote:
    >>From time to time the ntpq -pe output from my servers looks like this:

    >
    > remote refid st t when poll reach delay offset
    > jitter
    > ================================================== ============================
    > +GPS_NMEA(1) .GPS. 0 l 52 64 377 0.000 0.000
    > 0.004
    > ptbtime1.ptb.de .PTB. 1 u 75 256 377 155.060 -48.458
    > 35.782
    > ntps1-1.cs.tu-b .PPS. 1 u 91 256 377 151.487 -47.099
    > 1.731
    > ntp-p1.obspm.fr .1PPS. 1 u 11 256 377 123.504 -22.762
    > 19.197
    > gps-2.mit.edu .GPS. 1 u 34 256 377 246.793 -49.433
    > 3.131
    > oPPS(1) .PPS. 0 l 4 16 377 0.000 0.000
    > 0.004
    > ptbtime2.ptb.de .PTB. 1 u 38 256 377 157.004 -47.865
    > 2.205
    > gps-1.mit.edu .GPS. 1 u 24 256 377 239.559 -38.903
    > 31.765
    >
    > The question is: is it the time received from the GPS receiver bad ? I
    > suppose a network problem (upstream delay different from downstream
    > delay) but how may I bypass this problem - for the moment I have the
    > noselect for all external servers (without the noselect option the
    > server will reject the time from the GPS receiver).
    >
    > Thanks !
    >


    If the outgoing and incoming delays are not symmetric, an error will
    be introduced. The size of your offsets suggests that this might be
    the case. The delay figures for all your internet servers seem
    unreasonably large! Can you not use servers nearer to your site?

  3. Re: Is the time from the GPS receiver bad ?

    This is a normal situation:

    ntpq> pe
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    +GPS_NMEA(1) .GPS. 0 l 49 64 377 0.000 0.000
    0.004
    ptbtime1.ptb.de .PTB. 1 u 222 256 377 59.668 -0.685
    0.256
    ntps1-1.cs.tu-b .PPS. 1 u 8 256 377 54.452 0.015
    17.763
    ntp-p1.obspm.fr .1PPS. 1 u 135 256 377 55.599 -0.639
    6.994
    gps-2.mit.edu .GPS. 1 u 199 256 357 145.327 -0.031
    20.853
    oPPS(1) .PPS. 0 l 1 16 377 0.000 0.000
    0.004
    ntp2.usv.ro .PPS. 1 u 63 64 377 0.267 -0.008
    0.005
    ntp3.usv.ro .PPS. 1 u 20 64 377 0.320 -0.002
    0.041
    ptbtime2.ptb.de .PTB. 1 u 223 256 377 59.589 -0.175
    0.342
    gps-1.mit.edu .GPS. 1 u 212 256 377 146.007 0.049
    0.230


    As I said before, when that situation happen the ntpq algorithm exclude
    the GPS+PPS source from the trusted sources list and syncronize - in
    error - with one of the "bad" timetikers.


+ Reply to Thread