Re: SBC-ATT Time Servers

Others have observed that ATT/SBC's NTP servers are always off by
about 50ms.

There may be more to it, because I just started monitoring a server of
mine connected through ATT/SBC's DSL and I noticed that it's always
the same 50ms behind. However, on the server console, it doesn't
consider that it's behind at all.

Here's the output of "ntp -q" from its console:

remote refid st t when poll reach delay
offset jitter
==============================================================================
LOCAL(0) LOCAL(0) 10 l 5 64 377 0.000
0.000 0.061
+pool.ntp.org 99.150.184.201 2 u 866 1024 377 203.189
-3.074 0.611
-0.pool.ntp.org 132.163.4.103 2 u 40 1024 377 126.937
-13.291 20.243
+1.pool.ntp.org 69.25.96.11 2 u 948 1024 377 128.311
-4.087 0.255
-2.pool.ntp.org 69.36.224.15 2 u 54 1024 377 149.949
11.946 0.222
*3.pool.ntp.org 18.26.4.105 2 u 876 1024 377 107.562
-2.713 0.480
-nihil-a .GPS. 1 u 930 1024 377 153.354
14.843 27.568
+nihil-b 69.25.106.19 2 u 888 1024 377 117.809
-2.424 0.940

However, from the server which monitors it (added as a "noselect"
server):

remote refid st t when poll reach delay
offset jitter
==============================================================================
....
*nihil .GPS. 1 u 88 256 377 43.086
-3.273 1.211
adsl-71-145-171 217.160.254.116 3 u 968 1024 377 81.478
-50.927 4.942

Note that the delays from my server to its NTP servers are rather
inflated. Interestingly enough, pinging its servers, say
"3.pool.ntp.org", the same 50ms difference shows up between its ICMP
distance and its NTP distance:

rtt min/avg/max/mdev = 52.745/58.533/84.990/11.841 ms

I suspect that ATT/SBC botches NTP packets in its consumer network,
making everyone get the time incorrect by 50ms...

HTH

On May 23, 3:52*pm, Evandro Menezes <evan...@mailinator.com> wrote:[color=blue]
> Others have observed that ATT/SBC's NTP servers are always off by
> about 50ms.
>
> There may be more to it, because I just started monitoring a server of
> mine connected through ATT/SBC's DSL and I noticed that it's always
> the same 50ms behind. *However, on the server console, it doesn't
> consider that it's behind at all.
>
> Here's the output of "ntp -q" from its console:
>
> * * *remote * * * * * refid * * *st t when poll reach * delay
> offset *jitter
> ===========================================================================*===
> *LOCAL(0) * * * *LOCAL(0) * * * *10 l * *5 * 64 *377 * *0.000
> 0.000 * 0.061
> +pool.ntp.org * *99.150.184.201 * 2 u *866 1024 *377 *203.189
> -3.074 * 0.611
> -0.pool.ntp.org *132.163.4.103 * *2 u * 40 1024 *377 *126.937
> -13.291 *20.243
> +1.pool.ntp.org *69.25.96.11 * * *2 u *948 1024 *377 *128.311
> -4.087 * 0.255
> -2.pool.ntp.org *69.36.224.15 * * 2 u * 54 1024 *377 *149.949
> 11.946 * 0.222
> *3.pool.ntp.org *18.26.4.105 * * *2 u *876 1024 *377 *107.562
> -2.713 * 0.480
> -nihil-a * * * * .GPS. * * * * * *1 u *930 1024 *377 *153.354
> 14.843 *27.568
> +nihil-b * * * * 69.25.106.19 * * 2 u *888 1024 *377 *117.809
> -2.424 * 0.940
>
> However, from the server which monitors it (added as a "noselect"
> server):
>
> * * *remote * * * * * refid * * *st t when poll reach * delay
> offset *jitter
> ===========================================================================*===
> ...
> *nihil * * * * * .GPS. * * * * * *1 u * 88 *256 *377 * 43.086
> -3.273 * 1.211
> *adsl-71-145-171 217.160.254.116 *3 u *968 1024 *377 * 81.478
> -50.927 * 4.942
>
> Note that the delays from my server to its NTP servers are rather
> inflated. *Interestingly enough, pinging its servers, say
> "3.pool.ntp.org", the same 50ms difference shows up between its ICMP
> distance and its NTP distance:
>
> rtt min/avg/max/mdev = 52.745/58.533/84.990/11.841 ms
>
> I suspect that ATT/SBC botches NTP packets in its consumer network,
> making everyone get the time incorrect by 50ms...
>
> HTH[/color]

I am not sure that I understand what you are trying to get across to
us ... but from my own experience and useage or attempts to use the
ATT NTP Servers, ATT NTP Servers offsets are farther off than any of
the other time servers I try to sync to.

All I know for sure is that the servers that ATT provides for its
consumers to utilize consistantly have a ~45 msec offset and thereby
unusable by my time server for syncronization.

Here is the ntpq -c pe output from my time servers:

remote refid st t when poll reach delay
offset jitter
=================================================================
-ntp.okstate.edu .USNO. 1 u 270 1024 377 84.195
-7.471 0.458
-time-A.timefreq .ACTS. 1 u 345 1024 377 64.003
-4.775 1.266
-tick.UH.EDU .GPS. 1 u 786 1024 357 35.769
-2.724 0.688
-clock.xmission. .GPS. 1 u 244 1024 377 60.585
-3.618 1.185
-time.nist.gov .ACTS. 1 u 428 1024 377 60.529
-9.454 0.650
-father-time.t-b .GPS. 1 u 358 1024 377 54.542
-0.672 0.507
+ntp.tmc.edu tick.UH.EDU 2 u 325 1024 377 32.956
0.532 0.724
*ntp.your.org .CDMA. 1 u 378 1024 377 52.390
0.963 0.040
-ntp1.sbcglobal. st1gs-ntp.rcsnt 2 u 471 1024 357 41.126
-46.916 3.608
-ntp2.sbcglobal. st1gs-ntp.rcsnt 2 u 276 1024 377 37.449
-47.089 0.247
-st1gs-ntp.rcsnt .GPS. 1 u 260 1024 377 23.641
-46.478 4.570
-st1gs-ntp3.wlfr .GPS. 1 u 492 1024 377 74.657
-17.711 0.630
+gatekeeper.no-s .GPS. 1 u 386 1024 377 79.037
0.459 0.082

On May 23, 5:16 pm, baffled <turbow...@gmail.com> wrote:[color=blue]
>
> I am not sure that I understand what you are trying to get across to
> us ... but from my own experience and useage or attempts to use the
> ATT NTP Servers, ATT NTP Servers offsets are farther off than any of
> the other time servers I try to sync to.[/color]

My point is that any NTP server on ATT network is 50ms or so off, not
only ATT's. Note that my NTP server on their network is not
synchronizing to their NTP servers, yet it seems to be 50ms off too to
other NTP servers. However, as I showed, everything seems fine and
dandy from its point of view, for it's synchronizing with its NTP
servers pretty closely.

HTH

On 2008-05-23, Evandro Menezes <evandro@mailinator.com> wrote:
[color=blue]
> Here's the output of "ntp -q" from its console:[/color]

slightly reformatted so that it won't wrap on console news-readers...
[color=blue]
> remote refid st t when poll reach delay offset jitter
>=======================================================================
> LOCAL(0) LOCAL(0) 10 l 5 64 377 0.000 0.000 0.061
>+pool.ntp.org 99.150.184.201 2 u 866 1024 377 203.189 -3.074 0.611
>-0.pool.ntp.org 132.163.4.103 2 u 40 1024 377 126.937 -13.291 20.243
>+1.pool.ntp.org 69.25.96.11 2 u 948 1024 377 128.311 -4.087 0.255
>-2.pool.ntp.org 69.36.224.15 2 u 54 1024 377 149.949 11.946 0.222
>*3.pool.ntp.org 18.26.4.105 2 u 876 1024 377 107.562 -2.713 0.480
>-nihil-a .GPS. 1 u 930 1024 377 153.354 14.843 27.568
>+nihil-b 69.25.106.19 2 u 888 1024 377 117.809 -2.424 0.940
>
> However, from the server which monitors it (added as a "noselect"
> server):
>
> remote refid st t when poll reach delay offset jitter
>=======================================================================
>*nihil .GPS. 1 u 88 256 377 43.086 -3.273 1.211
> adsl-71-145-171 217.160... 3 u 968 1024 377 81.478 -50.927 4.942
>
> Note that the delays from my server to its NTP servers are
> rather inflated. Interestingly enough, pinging its servers, say
> "3.pool.ntp.org", the same 50ms difference shows up between its ICMP
> distance and its NTP distance:
>
> rtt min/avg/max/mdev = 52.745/58.533/84.990/11.841 ms
>
> I suspect that ATT/SBC botches NTP packets in its consumer network,
> making everyone get the time incorrect by 50ms...[/color]

--
Steve Kostecke <kostecke@ntp.org>
NTP Public Services Project - [url]http://support.ntp.org/[/url]

On May 23, 8:15 pm, Steve Kostecke <koste...@ntp.org> wrote:[color=blue]
>
> slightly reformatted so that it won't wrap on console news-readers...[/color]

Thank you kindly.
[color=blue][color=green]
> > However, from the server which monitors it (added as a "noselect"
> > server):[/color]
>[color=green]
> > remote refid st t when poll reach delay offset jitter
> >=======================================================================
> >*nihil .GPS. 1 u 88 256 377 43.086 -3.273 1.211
> > adsl-71-145-171 217.160... 3 u 968 1024 377 81.478 -50.927 4.942[/color][/color]

Just want to point out that this server did have other servers
configured whose times were around the one that it was synchronized
to, the one I did not edit out above.

Thanks.

What is your NTP Server and what ATT-SBC time servers are you using?