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?

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.