[ntp:questions] UK GPS jamming - February 2012
UK GPS jamming - February 2012 I have received the following: ___ NOTIFICATION OF GPS JAMMING EXERCISES RAF SCULTHORPE AIRFIELD, EAST ANGLIA, FEBRUARY 2012 Dates: Between 6 and 10 February 2012 inclusive. Times: between 0700 and 1700 GMT. Location of SINGLE jammer: Land based within 2km of 52° 50' 54? N, 0° 45' 38? E. Frequency: A 20 MHz band centred around 1575.42MHz (GPS L1). Total Power: Up to 0.1 Watts EIRP (100mW). It is stressed that, as in previous exercises, Safety of Life operations will at all times take precedence over exercise activities. ___ Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Offset Jumps with Motorola Oncore UT+
Hi! This morning my FreeBSD 7.4 Oncore UT+ NTP server exhibited a strange behaviour... Note the huge jump in offset from 854 ns to 596 us and then the highest offset at 159 ms. loop stats file: 55904 33539.225 0.01728 -1.282 0.00742 0.002620 4 55904 33555.225 0.01447 -1.282 0.00632 0.002450 4 55904 33571.224 0.00366 -1.282 0.02034 0.002292 4 55904 33587.224 0.01388 -1.282 0.00884 0.002144 4 55904 33603.224 0.01050 -1.282 0.00932 0.002006 4 55904 33619.224 0.00703 -1.282 0.00945 0.001876 4 55904 33635.224 0.01230 -1.282 0.00888 0.001755 4 55904 33651.224 0.00854 -1.282 0.00807 0.001642 4 55904 33667.224 -0.000596143 98.718 0.000167778 35.355334 4 55904 33683.227 -0.002127304 98.718 0.000187390 33.071886 4 55904 33699.227 -0.003561445 98.718 0.000176065 30.935917 4 55904 33715.228 -0.004910077 98.718 0.000165214 28.937901 4 55904 33731.231 -0.006175330 98.718 0.000155121 27.068927 4 55904 33747.230 -0.007362986 98.718 0.000145378 25.320663 4 55904 33763.231 -0.008479146 98.718 0.000136915 23.685311 4 55904 33779.232 -0.009525378 98.718 0.000128152 22.155580 4 55904 33795.233 -0.010508291 98.718 0.000120356 20.724648 4 55904 33811.233 -0.011431854 98.718 0.000113179 19.386133 4 55904 33827.236 -0.012298303 98.718 0.000106061 18.134067 4 55904 33843.235 -0.013111000 98.718 0.99472 16.962866 4 55904 33859.235 -0.013875647 98.718 0.93789 15.867308 4 55904 33875.246 -0.014592572 98.718 0.87576 14.842508 4 55904 33891.236 -0.015265789 98.718 0.82514 13.883895 4 55904 33907.237 -0.015897754 98.718 0.77516 12.987194 4 55904 33923.237 -0.015990842 -1.281 0.000113346 37.383905 4 55904 33939.235 -0.015012221 -1.281 0.000119575 34.969441 4 55904 33955.234 -0.014094512 -1.281 0.000112345 32.710917 4 55904 33971.243 -0.013232154 -1.281 0.000105387 30.598261 4 55904 33987.232 -0.012421534 -1.281 0.99284 28.622052 4 55904 34003.231 -0.011661964 -1.281 0.93166 26.773478 4 55904 34019.230 -0.010947573 -1.281 0.87707 25.044296 4 55904 34035.230 -0.010277662 -1.281 0.82635 23.426793 4 55904 34051.229 -0.009648911 -1.281 0.77225 21.913759 4 55904 34067.228 -0.009057791 -1.281 0.72765 20.498444 4 55904 34083.227 -0.008504199 -1.281 0.68014 19.174539 4 55904 34099.227 -0.007983831 -1.281 0.63681 17.936139 4 55904 34115.226 -0.007496061 -1.281 0.60174 16.22 4 55904 34131.225 -0.007036640 -1.281 0.56171 15.694121 4 55904 34147.225 -0.006606707 -1.281 0.52284 14.680506 4 55904 34163.224 -0.006201998 -1.281 0.49677 13.732356 4 55904 34179.226 -0.005822956 -1.264 0.46369 12.845444 4 55904 34195.233 -0.005465685 -1.264 0.44013 12.015813 4 55904 34211.223 -0.005131220 -1.264 0.41511 11.239764 4 55904 34227.222 -0.004817873 -1.264 0.38552 10.513836 4 55904 34243.222 -0.004523210 -1.264 0.36498 9.834793 4 55904 34259.221 -0.004246913 -1.264 0.33719 9.199607 4 55904 34275.231 -0.003987183 -1.264 0.31993 8.605444 4 55904 34291.220 -0.003743065 -1.264 0.29697 8.049656 4 55904 34307.230 -0.003514376 -1.264 0.27880 7.529764 4 55904 34323.222 -0.003298931 -1.264 0.26333 7.043449 4 55904 34339.221 -0.003096792 -1.264 0.24754 6.588543 4 55904 34355.221 -0.002907638 -1.264 0.23095 6.163018 4 55904 34371.220 -0.002729417 -1.264 0.21787 5.764975 4 55904 34387.228 -0.002563198 -1.264 0.20346 5.392641 4 55904 34403.228 -0.002406053 -1.264 0.17527 5.044353 4 55904 34419.220 -0.002257555 -1.264 0.18040 4.718561 4 55904 34435.219 -0.002119874 -1.256 0.16961 4.413810 4 55904 34451.219 -0.001991339 -1.256 0.15502 4.128741 4 55904 34467.227 -0.001869185 -1.256 0.14937 3.862084 4 55904 34483.218 -0.001754266 -1.256 0.14158 3.612649 4 55904 34499.218 -0.001647838 -1.256 0.13225 3.379323 4 55904 34515.226 -0.001546689 -1.256 0.12383 3.161068 4 55904 34531.225 -0.001451757 -1.256 0.11624 2.956908 4 55904 34547.217 -0.001362358 -1.256 0.11175 2.765934 4 55904 34563.225 -0.001279629 -1.256 0.10660 2.587295 4 55904 34579.231 -0.001201223 -1.256 0.09548 2.420192 4 55904 34595.224 -0.001127201 -1.256 0.09196 2.263883 4 55904 34611.224 -0.001058954 -1.256 0.08748 2.117668 4 55904 34627.230 -0.000994413 -1.256 0.07793 1.980897 4 55904 34643.224 -0.000932846 -1.256 0.07396 1.852960 4 55904 34659.224 -0.000875963 -1.256 0.07294 1.733285 4 55904 34675.229 -0.000820427 -1.256 0.06332 1.621340 4 55904 34691.223 -0.000772522 -1.259 0.06094 1.516625 4 55904 34707.223 -0.000726061 -1.259 0.05963 1.418673 4 55904 34723.229 -0.000680259 -1.259 0.05171 1.327047 4 55904 34739.222 -0.000637991 -1.259 0.05395 1.241339 4 55904 34755.222 -0.000598258 -1.259 0.04470 1.161166 4 55904 34771.228 -0.000560403 -1.259 0.04695 1.086171 4 55904 34787.222 -0.000527566 -1.259 0.04391 1.016020 4 55904 34803.222 -0.000496636 -1.259 0.06224 0.950400 4 55904 34819.221 -0.000463671 -1.259 0.03755
Re: [ntp:questions] ntp broadcast not working with IPv6
On 12/8/2011 11:18 PM, rakesh v wrote: Hi Danny, Have you got a chance to go through the code for this? Here though the socket bind is failing the multicast registration is happening successfully (which are shown by the debug traces here.) Does that have anything to infer here? Sorry, no. I've been at a conference almost all week and I've only been dealing with work related issues outside of the conference. Danny On Thu, Dec 8, 2011 at 9:58 AM, Danny Mayer ma...@ntp.org wrote: On 12/7/2011 11:15 PM, rakesh v wrote: Thanks for your inputs Danny. Hi Dave, Can you give your inputs on this below issue? Is the socket bind failing due to the reuse of the udp port 123. But I assume for ntp multicast client also we use the same port for listening. Or Is it due to some other issue? I think it is trying to bind to the incorrect address but I'd have to look carefully at the code to figure out exactly what is going on. Danny On Wed, Dec 7, 2011 at 6:34 PM, Danny Mayer ma...@ntp.org mailto:ma...@ntp.org wrote: On 12/7/2011 4:53 AM, rakesh v wrote: Hi Danny, Actually I ran the ntpd with Debug option before with a downloaded source code (ntp-4.26p4). These are the logs Iam seeing on the client side... /6 Dec 06:11:52 ntpd[2884]: set_process_priority: Leave priority alone: priority_done is 2/ / 6 Dec 06:11:52 ntpd[2884]: proto: precision = 0.208 usec/ / 6 Dec 06:11:52 ntpd[2884]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16/ / 6 Dec 06:11:52 ntpd[2884]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123/ / 6 Dec 06:11:52 ntpd[2884]: Listen and drop on 1 v6wildcard :: UDP 123/ / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 2 lo 127.0.0.1 UDP 123/ / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 3 eth1 10.16.34.6 UDP 123/ / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 4 lo ::1 UDP 123/ / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 5 eth2 2000::2 UDP 123/ / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 6 eth1 fe80::a00:27ff:fe68:7b4c UDP 123/ / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 7 eth2 fe80::a00:27ff:fe38:605 UDP 123/ / 6 Dec 06:11:52 ntpd[2884]: peers refreshed/ / 6 Dec 06:11:52 ntpd[2884]: Listening on routing socket on fd #24 for interface updates/ / *6 Dec 06:11:52 ntpd[2884]: bind(25) AF_INET6 ff02::101#123 (multicast) flags 0x0 failed: Invalid argument*/ / 6 Dec 06:11:52 ntpd[2884]: multicast address ff02::101 using wildcard interface #1 v6wildcard/ / 6 Dec 06:11:52 ntpd[2884]: Joined :: socket to multicast group ff02::101/ / / Actually Iam able to see only one Broadcast packet being received on client side in wireshark. Packets are not received. Here Iam not sure why the socket bind is failing for ntpd? Any inputs on this? That sounds like a bug. I haven't looked at that area of the code recently but being unable to bind to the socket would prevent it receiving packets. Dave Hart has touched this area recently may will likely know more. I do remember some issues with multicast but I don't remember this one. Danny -- Thanks Regs, Rakesh -- -- Regs, Rakesh Vanam +91 9900 024 002 -- ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpdate removal is coming
On 2011-12-08, Bruce Lilly bruce.li...@gmail.com wrote: On Thu, 08 Dec 2011 20:14:28 +, Harlan Stenn wrote: Bruce wrote: On Wed, 07 Dec 2011 23:56:08 +, Harlan Stenn wrote: Short of that, getting close to the right offset before starting ntpd means: 1) processes that depend on reasonably-close time synchronization (rsync, etc.) can proceed Again, the BCP I described earlier addresses this too... There is nothing common about the use of ntp-wait. So I don't understand why it is being referred to as a BCP. 2) ntpd converges to a stable point that much faster (i.e. it has less of an initial offset to remove) At the moment, the worst case for this is an offset that is just under 128ms, which will take under 5 minutes to apply at the standard slew rate of 500ppm. (64ms will take about 2.5 minutes' time to apply, etc.) functional equivalentfunctional equivalent Those times apply *after* enough samples have been gathered for an offset estimate, which happens *after* a system peer has been selected. That can take many minutes. With ntp-wait, the boot sequence would be effectively stalled for the duration. There is no need to use ntp-wait. Use sntp. Use a seperate 'ntpd -gq' invocation. I use sntp (rather than ntpd -q or ntp-wait) because it's much faster than the alternatives (life is too short for thumb-twiddling). 'ntpd -gq' exits after either stepping the clock or initiaing a slew. I've observed this happen in as little as 11 seconds. The bottom line is that you have not communicated any information to me that indicates you have a *need* to set the time before NTP starts. Need is a strong term; it's true that the world as we know it won't come to an abrupt end if booting is stalled for ten minutes, but it is rather inconvenient. In any event, my initial response was to point out two issues: 1. your reference to a good drift file presumes that all systems have a frequency offset which is stable across a reboot; that is an invalid assumption for most machines that I have in service here. Please bear in mind the fact that many systems do not have a stable frequency offset around a reboot and therefore cannot make practical use of a drift file at system startup (stop/restart of ntpd while the system is running is of course another matter). Why is it acceptable to initially set the clock to approximately the correct time with ntpdate but not with ntpd? You're so busy looking at the trees that you don't see the forest. 2. your estimate of fully sync'd in 11 seconds' time seemed overly optimistic (and still does, even with minimum polling times and maximum slew rate). The 11 second figure applies to the initial setting of the clock with 'ntpd -gq' (which is analogous to the use of ntpdate for the same purpose) and not to disciplining the clock to maximum stability. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Offset Jumps with Motorola Oncore UT+
On 2011-12-09, Miguel Gon?alves m...@miguelgoncalves.com wrote: Hi! This morning my FreeBSD 7.4 Oncore UT+ NTP server exhibited a strange behaviour... Note the huge jump in offset from 854 ns to 596 us and then the highest offset at 159 ms. loop stats file: 55904 33635.224 0.01230 -1.282 0.00888 0.001755 4 55904 33651.224 0.00854 -1.282 0.00807 0.001642 4 55904 33667.224 -0.000596143 98.718 0.000167778 35.355334 4 55904 33683.227 -0.002127304 98.718 0.000187390 33.071886 4 55904 33699.227 -0.003561445 98.718 0.000176065 30.935917 4 55904 33715.228 -0.004910077 98.718 0.000165214 28.937901 4 55904 33731.231 -0.006175330 98.718 0.000155121 27.068927 4 55904 33747.230 -0.007362986 98.718 0.000145378 25.320663 4 55904 33763.231 -0.008479146 98.718 0.000136915 23.685311 4 55904 33779.232 -0.009525378 98.718 0.000128152 22.155580 4 55904 33795.233 -0.010508291 98.718 0.000120356 20.724648 4 55904 33811.233 -0.011431854 98.718 0.000113179 19.386133 4 55904 33827.236 -0.012298303 98.718 0.000106061 18.134067 4 55904 33843.235 -0.013111000 98.718 0.99472 16.962866 4 55904 33859.235 -0.013875647 98.718 0.93789 15.867308 4 55904 33875.246 -0.014592572 98.718 0.87576 14.842508 4 55904 33891.236 -0.015265789 98.718 0.82514 13.883895 4 55904 33907.237 -0.015897754 98.718 0.77516 12.987194 4 55904 33923.237 -0.015990842 -1.281 0.000113346 37.383905 4 55904 33939.235 -0.015012221 -1.281 0.000119575 34.969441 4 clock stats file: 55904 33650.223 127.127.30.0 3532411249.99141 2011 343 9 20 50 49 rstat 08 dop 0.0 nsat 9,7 traim 1,0,0 sigma 41 neg-sawtooth -34 sat 3888 55904 33651.223 127.127.30.0 3532411250.99704 2011 343 9 20 51 50 rstat 08 dop 0.0 nsat 9,7 traim 1,0,0 sigma 41 neg-sawtooth -49 sat 3888 The machine is running 4.2.6p4. What might have caused this? This machine does nothing else providing NTP to the network. The most likely cause for the offset change that you observed was related to the satellite position relationship taking a bad track. This is minimized by setting a higher mask angle in your Oncore configuration and not use satellites below 10 degrees above the horizon. If you have trees or other obstuctions in the area, use an even higher angle. GPS satellites have their maximum accuracy when their path to you is 'high in the sky' and without obstructions. It is unfortunate that you chopped off the portion of your clockstats file that coincided with 'something interesting' being recorded in your loopstats file. This occurred at 55904 33667.224 in the log. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp broadcast not working with IPv6
On Wed, Dec 7, 2011 at 09:53, rakesh v rakeshva...@gmail.com wrote: Hi Danny, Actually I ran the ntpd with Debug option before with a downloaded source code (ntp-4.26p4). These are the logs Iam seeing on the client side... * 6 Dec 06:11:52 ntpd[2884]: bind(25) AF_INET6 ff02::101#123 (multicast) flags 0x0 failed: Invalid argument* This is unexpected. ntpd expects non-Windows systems to listen for multicast by binding a socket to each multicast group address. * 6 Dec 06:11:52 ntpd[2884]: multicast address ff02::101 using wildcard interface #1 v6wildcard* * 6 Dec 06:11:52 ntpd[2884]: Joined :: socket to multicast group ff02::101* As you can see, there's fallback code to attempt to use the wildcard interface, but I doubt that will work out for you, even if you add interface listen :: to override the default behavior of dropping all traffic received via the wildcard interface. This is because ntpd typically depends on determining the destination address based on the socket on which the packet was received. I note the following paragraph in man ipv6 on a Debian stable system: Linux 2.4 will break binary compatibility for the sockaddr_in6 for 64-bit hosts by changing the alignment of in6_addr and adding an addi- tional sin6_scope_id field. The kernel interfaces stay compatible, but a program including sockaddr_in6 or in6_addr into other structures may not be. This is not a problem for 32-bit hosts like i386. Since you saw the problem even when building ntpd from source, this seems unlikely to be the cause of your problem, but it seemed worth mentioning. I'd suggest trying to determine what is causing the bind() to ff02::101 to fail on your system. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpdate removal is coming
On 2011-12-09, Steve Kostecke koste...@ntp.org wrote: On 2011-12-08, Bruce Lilly bruce.li...@gmail.com wrote: On Thu, 08 Dec 2011 20:14:28 +, Harlan Stenn wrote: Bruce wrote: 2) ntpd converges to a stable point that much faster (i.e. it has less of an initial offset to remove) At the moment, the worst case for this is an offset that is just under 128ms, which will take under 5 minutes to apply at the standard slew rate of 500ppm. (64ms will take about 2.5 minutes' time to apply, etc.) functional equivalentfunctional equivalent Ooops ... missed a botched edit. What I had intended to write was: This seems out of place in a discussion about replacing ntpdate. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Symmetric Key samples
The key types A,S,N and M are defined in the NTP 4.1.2 ntp-keygen document: http://doc.ntp.org/4.1.2/genkeys.htm. They have been removed in NTP 4.2.0. There is nothing in the release note about removing those keys. So it seems that only MD5, SHA and SHA1 symmetric key types are supported in 4.2.6p3; right? My understanding of the Authentication document is that the crypto digest name in the ntp.conf specifies the digest algorithm only for Autokey authentication, not for symmetric authentication. Is that right? Should the digest name in the crypto digest name match with the type of certificate scheme used when generating keys with ntp-keygen -c? Thanks Joe. On Thu, Dec 8, 2011 at 2:01 PM, Steve Kostecke koste...@ntp.org wrote: On 2011-12-08, Joe Smithian joe.smith...@gmail.com wrote: A,N,S, and M keys are defined in the man ntp.keys http://www.gsp.com/cgi-bin/man.cgi?section=5topic=ntp.keys I have the current ntp-dev installed and: $ man ntp.keys No manual entry for ntp.keys -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] New ntp Server
On Thu, Dec 08, 2011 at 12:50:12PM +, Dave Hart wrote: The results are worse than FreeBSD or Linux I suspect the difference is mostly due to the interpolation code having to guess at when, on the counter timescale, the system clock ticked up to the present value. Some ugly busy-looping logic might help refine that and also overcome the incompatibility with newer Windows versions' clocks. It's a pity the system doesn't provide a function for precise clock reading. What resolution has the clock frequency adjustment? I'm reading about the SetSystemTimeAdjustment function and the adjustment is in 100-ns units applied over an lpTimeIncrement interval. If the interval is too short I suspect this could also limit the time and frequency accuracy of the system clock. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] New ntp Server
On Fri, Dec 9, 2011 at 17:27, Miroslav Lichvar mlich...@redhat.com wrote: What resolution has the clock frequency adjustment? I'm reading about the SetSystemTimeAdjustment function and the adjustment is in 100-ns units applied over an lpTimeIncrement interval. If the interval is too short I suspect this could also limit the time and frequency accuracy of the system clock. Clock interrupt period 15.600 msec (startup slew 19.5 usec/period) Windows clock precision 1.001 msec, min. slew 6.410 ppm/s That's from typical ntpd startup on Vista and later. SetSystemTimeAdjustment operates here in 100ns units per 15.600 msec fictional tick. The result is a unit adjustment to the SetSystemTimeAdjustment argument results in a 6.4 PPM rate change. sys_residual carry allows finer adjustments over multiple seconds. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Offset Jumps with Motorola Oncore UT+
Hi Tom! Many thanks for your suggestion! I added MASK 30 to my ntp.oncore.0 file. By the way... mine is MODE 1 LAT 40 55 13.1082 LONG -8 29 36.7247 HT 319.03 M TRAIM YES DELAY 25 NS CLEAR MASK 30 HARDPPS SHMEM /etc/oncore.0 Do you suggest any other change? I clipped it by mistake. My intention was to show both at the time that strange thing occurred. My clock stats file at that moment showed: 55904 33657.223 127.127.30.0 3532411256.99443 2011 343 9 20 57 56 rstat 08 dop 0.0 nsat 9,7 traim 1,0,0 sigma 41 neg-sawtooth -21 sat 3888 55904 33658.223 127.127.30.0 3532411257.98648 2011 343 9 20 58 57 rstat 08 dop 0.0 nsat 9,7 traim 1,0,0 sigma 41 neg-sawtooth -32 sat 3888 55904 33659.225 127.127.30.0 3532411258.98420 2011 343 9 20 59 58 rstat 08 dop 0.0 nsat 9,7 traim 1,0,0 sigma 41 neg-sawtooth -42 sat 3888 55904 33660.223 127.127.30.0 3532411259.97894 2011 343 9 21 0 59 rstat 08 dop 0.0 nsat 9,7 traim 1,0,0 sigma 41 neg-sawtooth -52 sat 3888 55904 33661.223 127.127.30.0 3532411261.99284 2011 343 9 21 1 1 rstat 08 dop 0.0 nsat 9,7 traim 1,0,0 sigma 41 neg-sawtooth 40 sat 3888 55904 33662.223 127.127.30.0 3532411262.000200112 2011 343 9 21 2 2 rstat 08 dop 0.0 nsat 9,7 traim 1,0,0 sigma 41 neg-sawtooth 29 sat 3888 55904 33663.224 127.127.30.0 3532411263.000299488 2011 343 9 21 3 3 rstat 08 dop 0.0 nsat 9,7 traim 1,0,0 sigma 41 neg-sawtooth 16 sat 3888 55904 33664.224 127.127.30.0 3532411264.000399050 2011 343 9 21 4 4 rstat 08 dop 0.0 nsat 9,7 traim 1,0,0 sigma 41 neg-sawtooth 2 sat 3888 55904 33665.224 127.127.30.0 3532411265.000497312 2011 343 9 21 5 5 rstat 08 dop 0.0 nsat 9,8 traim 1,0,0 sigma 41 neg-sawtooth -10 sat 5888 55904 33666.224 127.127.30.0 3532411266.000596142 2011 343 9 21 6 6 rstat 08 dop 0.0 nsat 9,8 traim 1,0,0 sigma 41 neg-sawtooth -23 sat 5888 55904 33667.224 127.127.30.0 3532411267.000695546 2011 343 9 21 7 7 rstat 08 dop 0.0 nsat 9,8 traim 1,0,0 sigma 41 neg-sawtooth -37 sat 5888 55904 33668.226 127.127.30.0 3532411268.000794635 2011 343 9 21 8 8 rstat 08 dop 0.0 nsat 9,8 traim 1,0,0 sigma 41 neg-sawtooth -49 sat 5888 55904 33669.224 127.127.30.0 3532411269.000891144 2011 343 9 21 9 9 rstat 08 dop 0.0 nsat 9,8 traim 1,0,0 sigma 41 neg-sawtooth 43 sat 5588 55904 33670.224 127.127.30.0 3532411270.000989030 2011 343 9 21 10 10 rstat 08 dop 0.0 nsat 9,8 traim 1,0,0 sigma 41 neg-sawtooth 32 sat 5588 55904 33671.224 127.127.30.0 3532411271.001085565 2011 343 9 21 11 11 rstat 08 dop 0.0 nsat 9,8 traim 1,0,0 sigma 41 neg-sawtooth 21 sat 5588 55904 33672.224 127.127.30.0 3532411272.001181597 2011 343 9 21 12 12 rstat 08 dop 0.0 nsat 9,8 traim 1,0,0 sigma 41 neg-sawtooth 10 sat 5888 55904 33673.226 127.127.30.0 3532411273.001277993 2011 343 9 21 13 13 rstat 08 dop 0.0 nsat 9,8 traim 1,0,0 sigma 41 neg-sawtooth -1 sat 5888 55904 33674.224 127.127.30.0 3532411274.001372357 2011 343 9 21 14 14 rstat 08 dop 0.0 nsat 9,8 traim 1,0,0 sigma 41 neg-sawtooth -14 sat 5888 55904 33675.225 127.127.30.0 3532411275.001469208 2011 343 9 21 15 15 rstat 08 dop 0.0 nsat 9,8 traim 1,0,0 sigma 41 neg-sawtooth -27 sat 5885 55904 33676.225 127.127.30.0 3532411276.001563913 2011 343 9 21 16 16 rstat 08 dop 0.0 nsat 9,8 traim 1,0,0 sigma 41 neg-sawtooth -40 sat 5885 55904 33677.225 127.127.30.0 3532411277.001658965 2011 343 9 21 17 17 rstat 08 dop 0.0 nsat 9,7 traim 1,0,0 sigma 41 neg-sawtooth 51 sat 0885 55904 33678.227 127.127.30.0 3532411278.001752142 2011 343 9 21 18 18 rstat 08 dop 0.0 nsat 9,7 traim 1,0,0 sigma 41 neg-sawtooth 38 sat 0885 55904 33679.225 127.127.30.0 3532411279.001845688 2011 343 9 21 19 19 rstat 08 dop 0.0 nsat 9,7 traim 1,0,0 sigma 41 neg-sawtooth 26 sat 0885 By the way: can you explain the traim, sigma and neg-sawtooth values please? Cheers, Miguel On 9 December 2011 14:39, Thomas Laus lau...@acm.org wrote: On 2011-12-09, Miguel Gon?alves m...@miguelgoncalves.com wrote: Hi! This morning my FreeBSD 7.4 Oncore UT+ NTP server exhibited a strange behaviour... Note the huge jump in offset from 854 ns to 596 us and then the highest offset at 159 ms. loop stats file: 55904 33635.224 0.01230 -1.282 0.00888 0.001755 4 55904 33651.224 0.00854 -1.282 0.00807 0.001642 4 55904 33667.224 -0.000596143 98.718 0.000167778 35.355334 4 55904 33683.227 -0.002127304 98.718 0.000187390 33.071886 4 55904 33699.227 -0.003561445 98.718 0.000176065 30.935917 4 55904 33715.228 -0.004910077 98.718 0.000165214 28.937901 4 55904 33731.231 -0.006175330 98.718 0.000155121 27.068927 4 55904 33747.230 -0.007362986 98.718 0.000145378 25.320663 4 55904 33763.231 -0.008479146 98.718 0.000136915 23.685311 4 55904 33779.232 -0.009525378 98.718 0.000128152 22.155580 4 55904 33795.233 -0.010508291 98.718 0.000120356
