Re: [ntp:questions] Possible new attack?
On Monday, October 6, 2014 6:50:09 PM UTC-5, William Unruh wrote: > Not only that but they are probably running ntp 3 systems, which does > not have KOD. The suspects are purportedly NTPV4: remote address port local address count m ver rstr avgint lstint wnpgmb1154w-a-b 123 192.168.a.b 18 3 45f8 6 0 a-b.dyn.suddenlink.net 42324 192.168.a.b 1590 3 45f8 14 6 Note that the restriction bits indicate that these clients are being kissed goodbye, yet they remain. Again, they are not numerous on my server, just a pesky few. The bandwidth used by all NTP clients, the good and the bad alike, amounts to just about 1.5Kbps. But, if this is some sort of infection spreading out, it could affect notorious ST1 servers worse and more of them might be placed behind a wall serving only their internal site, as it's happened after to the recent DRDoS attack. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Possible new attack?
I've noticed a couple of NTP clients with the unusual avgint of 16s with hundreds of accesses to my NTP server in the pool. I added a restriction, in addition to the recommended ones already in place, to cope with the suspicious clients bumping the discard average threshold to 32s. Eventually, KoD kicked them out, but they returned again and again, but each time with a different source UDP port. I'd think that were it the case of an improperly configured, though kosher, NTP client, it would not haunt the server again after a KoD. I suspect that it's the case of zombie systems running some sort of DoS bot. If so, is this the behavior of the recent DRDoS attack or a new attack on NTP? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On Saturday, June 14, 2014 9:52:46 PM UTC-5, Harlan Stenn wrote: > Yes, and remember we live in a world of NAT. While there is much to be > said for running "your" NTP servers that talk to outside NTP servers and > having all of your other NTP clients talk to your NTP servers, some > folks don't do this, and that means their clients can send a lot of > queries to external servers and these requests will be coming from > (different ports from) a single IP address (due to NAT). This is a good point. As a matter of fact, IPv4 has been exhausted in many locations around the world (first in Europe, then in Asia and, this month, in Latin America). Many IPv4-starved ISPs, having sit on their hands for years about moving to IPv6, have increasingly resorted to NAT for large swaths of their customers. This is bad in many ways, as the Internet grew out of one address per node. Unfortunately, this is bound to be a problem for years, when packets seem to come from the same address at a high rate. I'd be inclined to reject such likely NAT sources as if they were abusers, but this would just punish the customers of an irresponsible ISP. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] New Stratum-1 at the University of Houston
On Friday, April 25, 2014 1:09:45 AM UTC-5, Evandro Menezes wrote: > The NTP ST1 server at the University of Houston has been offline for about a > month. Any information about its demise? Yet another victim of a DOS attack? Alan Pfeiffer-Traum from UH was kind enough to explain: "tick.uh.edu has been offline to the internet since mid-February. About that time we saw a sudden sharp increase in traffic from many sources. The high level of traffic overwhelmed tick and made it unusable. We hope that this event will eventually fade away so we can allow access to the service again." ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] New Stratum-1 at the University of Houston
On Friday, April 25, 2014 2:15:34 PM UTC-5, Jason wrote: > 'ntppub.tamu.edu' usually has 'clepsydra.dec.com' as its selected time > source. I just use that server instead of tamu's... I realize this, but I prefer to have a reference nearby, even if ST2 just to validate an ST1. It has happened that the ST2 servers ejected a ST1 one that drifted away. > 'ntp.rice.edu' is their ntp server that is publically accessible. I contacted > them a while back to let them know to update their NTP > version and also see if they would lower their maxpoll for their local S1 > servers since they appear to have both an internal GPS & CDMA source, but no > such luck. Of course, ntp.rice.edu. I should've guessed it. > For what it is worth, my server often selects 'utcnist.colorado.edu' as the > primary choice even though it is further away than most of the other S1 & > S2's in my ntp list. ntp.okstate.edu is not as close as time.uh.edu, but as close as ntp.rice.edu and much closer to my site than colorado.edu. Thanks. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] New Stratum-1 at the University of Houston
On Friday, April 25, 2014 9:40:47 AM UTC-5, Jason wrote: > I don't know, it seemed kind of flaky at first then it stopped responding > altogether. I finally gave up and removed it from my list a while ago. It > used to be stable for ages, maybe they just removed public access? > > Even ntp.tmc.edu seems to be a little flaky at times. (Located in the Medical > Center I guess.) > > Rice has a good publicly accessible S2 server, on Level-3 network, I get less > than 2ms delay to it from my server. >From my site, both uh.edu and tmc.edu are pretty close, latency-wise. And >uh.edu's being ST1 was certainly a plus. Anyway, it's still in my list, >hoping that it comes back alive. FWIW, the ST2 server at tamu.edu is pretty >close to me too. Adding another nearby server, even ST2 would be good. But what rice.edu server do you use? libra has become obsolete apparently. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] New Stratum-1 at the University of Houston
The NTP ST1 server at the University of Houston has been offline for about a month. Any information about its demise? Yet another victim of a DOS attack? TIA ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] serialPPS+gpsd+ntpd large offset & jitter
On Jan 14, 3:14 pm, Evandro Menezes wrote: > On Jan 13, 7:38 pm, mi...@flatsurface.com (Mike S) wrote: > > > > > I was able to force the kernel to use the 8259 by adding > > "clocksource=acpi_pm" to the boot options. The available clock sources > > can be found with "cat > > /sys/devices/system/clocksource/clocksource0/available_clocksource". > > FWIW, the 8259 is the PIT, not the ACPI timer. Ahem, the 8254 is the PIT, not the ACPI timer. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] serialPPS+gpsd+ntpd large offset & jitter
On Jan 13, 7:38 pm, mi...@flatsurface.com (Mike S) wrote: > > I was able to force the kernel to use the 8259 by adding > "clocksource=acpi_pm" to the boot options. The available clock sources > can be found with "cat > /sys/devices/system/clocksource/clocksource0/available_clocksource". FWIW, the 8259 is the PIT, not the ACPI timer. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What level of timesynch error is typical onWinXP?
On Nov 5, 11:53 am, "David L. Mills" wrote: > > If linux does not agree with the standard Unix semanitcs, which I know > for a fact has been in BSD Unix since 1986 at least, Linux will not work > properly. However, absent second-order effects, performance will be no > worse than if the training period was not used. However, Miroslav's > experience suggests second order effects do occur due unknown cause. In > that case, the only suggestion I can make is either find the cause, > abandon NTP or abandon Linux. Or how about to condition the Linux-specific code by testing the predefined macro "__linux__"? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What level of timesynch error is typical on Win XP?
On Oct 22, 10:23 am, "David J Taylor" wrote: > That could explain why I see higher NTP jitter on a Windows system running > a USB network source (digital video data stream) than receiving a similar > data stream on a PCI card under either Windows XP or Windows-7. Possibly, but USB, as a polled, token-ring like protocol, will always add jitters in this case. > Having said that, anyone with such time-critical requirements will want to > stop all non-essential and any unpredictable processes such as anti-virus > or system updates and virus scans. On Windows-7 that can be quite a > challenge compared to Windows XP. If one would stop all unpredictable processes in Windows one would have to stop Windows. Can one stop network and disk I/O in Windows? IMHO, if one wants a good, consistent NTP server, it should at least be Linux. HTH ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What level of timesynch error is typical on Win XP?
On Oct 21, 10:00 am, "David J Taylor" wrote: > Windows can run NTP at real-time priority, if you give the NTP user that > right. Normal user processes will not then pre-empt NTP. Yes, except that Windows ends up raising the effective priority of system tasks that supersede NTP's effective priority. Among the worst offenders, network DPCs and some disk DPCs with some anti-virus programs (i.e., Mcafee). Then, even tasks with real-time priority will and do get starved and an algorithm like NTP's, which has hard deadlines, suffers, thus the inherently higher jitter in Windows. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What level of timesynch error is typical on Win XP?
On Oct 20, 10:34 pm, Joseph Gwinn wrote: > In article , > "David J Taylor" wrote: > > In my experience, changing the priority of NTP doesn't help a lot, but > > most of my PCs are not CPU-bound. But I have given the account the rights > > to do that. > > My experience is the same. for average behaviour. But for use in > realtime, running the daemon at high realtime priority greatly reduces > the tails of the probability distribution of response times and/or clock > offsets. Indeed, since Windows allows a process to be starved from running, depending on the load, a higher priority process may block NTP from running. Therefore, although raising the priority for NTP doesn't mean that it cannot be starved, it does decrease the likelihood of that happening. Linux, on the other hand, favors fair process scheduling and strives to not starve any from running at least for a little while. HTH ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] General ntp architecture question
On Aug 2, 7:37 am, konsu wrote:
> Thanks for your answers. Actually I do not know what are the criteria
> to consider in deciding time requirements. This is a bank , we will
> deploy VOIP soon and we have some dealers connected to reuters
> network {I am checking whether they have their own time sync}so
> for the rest, I do not see any reason why synchronization to the
> internet would be an issue.
Because there is no guarantee that the time served by hosts in the
pool is the correct time.
In addition to getting your own time server, you might also use
pool.ustiming.org, which, unlike the public pool, provides auditable
information regularly (see http://ustiming.org/foundation.html ).
HTH
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] local vs Windows Server 2003
On May 14, 1:31 am, David Lord wrote: > Using ntptrace also allows you to select closest and assists > in avoiding sources with same refids (ok those can/do change). > If the ISP has their own ntp server that is also likely to be > a good choice. You might try adding the stratum 1 servers from pool.ustiming.org. Perhaps one of its servers on the E. coast wouldn't be too far from you. HTH ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp not updating the time
I'd suggest soem sanity changes to the configuration file: > 31 # Undisciplined Local Clock. This is a fake driver intended for backup > 32 # and when no outside source of synchronized time is available. > 33 server 127.127.1.0 # local clock > 34 fudge 127.127.1.0 stratum 10 Remove these lines. Using your own host time as time reference for itself doesn't make sense in most situations. > 36 # Drift file. Put this in a directory which the daemon can write to. > 37 # No symbolic links allowed, either, since the daemon updates the file > 38 # by creating a temporary in the same directory and then rename()'ing > 39 # it to the file. > 40 driftfile /var/lib/ntp/drift Sometimes, while playing with NTP configuration, you may end up with a bad driftfile. Stop NTP, delete /var/lib/ntp/drift and start NTP again. HTH ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quick sync between two computers not connected to the internet
On Mar 23, 1:34 pm, "Richard B. Gilbert" wrote: > There is > "orphan mode" which I have never used or needed to. I'm a big fan of orphan mode and, when the DSL goes out, it's pretty fun to see my systems at home settling on one of them to be the ref. It is perhaps the answer to the OP question. HTH ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quick sync between two computers not connected to the internet
On Mar 23, 11:38 am, Chuck Swiger wrote: > > If I really had to solve the latter problem, I would likely connect the > machines to a valid NTP timesource long enough to calibrate each machines' > intrinsic drift from realtime, and then run time in standalone mode against > their local clock. Useless. Clocks may drift wildly due to temperature changes, be it ambient or inside the box. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] splash around with ntp-dev in the pool
On Feb 23, 4:48 am, Dave Hart wrote: > All of this is how manycastclient is implemented today, this is just > an extension of that to a different solicitation mechanism. > manycastclient sends multicast NTP client mode packets and on receipt > of unicast responses, configures a preemptible association. pool now > sends one unicast solicitation at a time, and reacts similarly to > responses. I think that this is a terrific idea! Some pool servers are rather poor and false-tickers are not uncommon, not to mention those that are offline. I'd just suggest that interface disconnections should also provoke a reassessment of the pool sources. I'm thinking primarily of laptops, but servers could also benefit from this in case one interface or router goes dead and the another interface goes trough a quite different route. TIA ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd and database servers
Doesn't NTP know UTC via the root dispersion? If so, then instead of giving out its time, it could give out UTC. I'm sure that there may be more to it, but just a thought. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Timekeeping broken on Windows XP with multimedia timer enabled (-M option)
On Jan 25, 8:15 am, Martin Burnicki wrote: > > Yes, it helps indeed ;-) I'm glad it does. And just for completion, the current generation of AMD processors derive the CPU clock from the memory controller clock instead of the FSB. Moreover, the memory controller clock may also be changed on the fly and is thus subject to power management policies too, effectively making its TSC not invariant if the memory controller power is managed. However, I don't know of any OS that does this yet. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Timekeeping broken on Windows XP with multimedia timer enabled (-M option)
On Jan 21, 10:42 am, Martin Burnicki wrote: > Ah, that's interesting. I did know that new CPU cores may not suffer from > switched CPU clocks anymore, but I didn't know this is because they are > driven by the FSB clock. So I assume the QPC clock frequency reported by > Windows can also correspond to the FSB clock. Only indirectly. You certainly know that the CPU clock is a multiple of the FSB clock. The unit of the result returned by RDTSC is still CPU clock ticks, always. So, when the CPU clock multiplier is changed from, say, 3.5 to 1.0, due to a power management decision, the TSC circuitry is changed accordingly, so that its unit is the same as the CPU's. The result is that when measuring the CPU clock, one will still get it right. However, the precision of the TSC is not 1 CPU clock tick anymore, but the FSB multiplier. So it cannot be used so easily to measure how many CPU clock cycles a sequence of instructions takes anymore. AFAIK, on AMD processors it's still possible to chose between variant and invariant TSC. But I think that the tendency is for BIOS makers to not offer this option and just enable the invariant TSC, since only developers care about its precision (and they can use a performance counter for the same purpose). HTH ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Timekeeping broken on Windows XP with multimedia timer enabled (-M option)
On Jan 21, 2:52 pm, "David J Taylor" wrote: > > BTW: I still have systems running which are older than Core2, on still has > an Intel PIII 550MHz (and keeps good time as a stratum-1 server with > Windows 2000). I guess that it would qualify for a low-power processor these days, so who cares about managing its power and messing with its TSC? ;-) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Timekeeping broken on Windows XP with multimedia timer enabled (-M option)
On Jan 21, 9:51 am, "David J Taylor" wrote: > > Thanks, Martin. I'm beginning to wish I'd never asked, as I have Windows > XP SP3 here and yet the performance counter is running at 2.4GHz (Intel > E6600 dual-core). Or does the PM_Timer only apply to AMD systems? Windows chooses the most precise, invariant frequency source available in the system. As I said before, Intel's Core2 processors have a TSC that doesn't vary with the CPU clock (though its precision is not as good as it seems). Only newer AMD processors sport the same feature and even then it must be enabled by a BIOS option that's not always available. Therefore, the likelihood of an AMD system using the PM timer is greater than new Intel systems. In these days, it's moot to worry about the precision of the QueryPerformanceCounter function. Windows will use the most precise time source in the system and only very old systems would not have at least the PM timer. HTH ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Timekeeping broken on Windows XP with multimedia timer enabled (-M option)
On Jan 21, 4:43 am, Martin Burnicki wrote: > AFAIK this should only affect the TSCs, so the setting should not matter at > all if the PM timer is used. Another detail on RDTSC: newer cores, such as Intel's Core2 and AMD's Phenom, return a constant-rate readout by RDTSC. In actuality, the counter that RDTSC is driven by the FSB clock instead of by the CPU clock and, even if the later changes due to power management, it's adjusted accordingly. But it all boils down to the HAL, which will use whatever's necessary to make sure that what QueryPerformanceCounter returns is independent of the CPU clock. HTH ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Timekeeping broken on Windows XP with multimedia timer enabled (-M option)
On Jan 20, 8:23 am, Martin Burnicki wrote: > > I've written a little tool which can reports clock frequency for the QPC > API:http://www.meinberg.de/download/utils/windows/wclkres-1.2.zip Or just run this Microsoft tool from the command-line: \\live.sysinternals.com\tools\clockres It's also available from http://live.sysinternals.com/Tools/Clockres.exe HTH ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Timekeeping broken on Windows XP with multimedia timer enabled (-M option)
On Jan 20, 8:23 am, Martin Burnicki wrote: > > Also, changes in the CPU clock frequency by AMD's Cool'n'Quiet or Intel's > Speedstep can mess up the QPC results. Actually, on systems running Windows XP or later if the HAL deternines that this is the case, then RDTSC is not used for this function. HTH ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Regarding NTP configuration ntp.conf
On Dec 17, 4:36 pm, ober...@es.net (Kevin Oberman) wrote: > > I will say that having two servers is probably the worst case. You > really want three, five, or seven. Actually, one wants "3x + 1" (Byzantine fault-tolerance) servers in order to out vote "x" bad servers, i.e., 4, 7, 10, etc. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] help with setting up NTP on windows with a USB GPS
On Dec 4, 2:10 pm, "Richard B. Gilbert" wrote: > > unruh wrote: > > > Please, do not use a Windows box as your main server. get a cheap ( your > > local flea market should have one for $50) computer, install linux or > > freebsd, purely for running ntp on it, and use it as your server. > > Elderly computers can frequently be found at curbside. Often, there is > nothing wrong with them, they are just old and/or slow. NTP does not > require a lot of computing power!! If these old wrecks will boot some > form of Windows or Linux they are well suited to not very demanding jobs > like running NTPD. No engineer or analyst or consultant worth its salt would suggest a banged up PC to perform any role in a project. Such suggestion may be fine for one's own garage project, but not anywhere else. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Manycast
On Dec 1, 10:17 am, Evandro Menezes wrote: > > However, I noticed that the manycast servers are usually dropped after > being reached 377 "times" without ever becoming selected, though > they're all a ms away from each other. > > For instance, at one moment a client has: > > remote refid st t when poll reach delay offset jitter > == > *time-server1 .GPS. 1 u 5 64 377 41.583 -2.303 1.886 > NTP.MCAST.NET .ACST. 16 u - 64 0 0.000 0.000 0.002 > foo 10.46.4.151 2 u 2 64 377 0.179 -1.245 0.675 > bar 10.46.4.151 2 u 2 64 3 0.178 -1.832 0.111 I think I got it why: time-server1 and 10.46.4.151 are the same servers, so the client is not bothering associating with either foo or bar when their reference is the same. Is that it? TIA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Manycast
Additionally, it seems that even though the poll is stated to be 1024s, it's actually reached every 64s: remote refid st t when poll reach delay offset jitter == NTP.MCAST.NET .ACST. 16 u- 6400.000 0.000 0.002 +foo 29.46.4.151 2 u 62 1024 3770.202 -2.712 0.249 *bar 29.46.4.151 2 u 62 1024 3770.189 -3.117 0.207 And then, a few seconds later: remote refid st t when poll reach delay offset jitter == NTP.MCAST.NET .ACST. 16 u- 6400.000 0.000 0.002 +foo 29.46.4.151 2 u2 1024 3770.202 -2.712 0.249 *bar 29.46.4.151 2 u2 1024 3770.189 -3.117 0.207 What gives? TIA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Manycast
I got manycast working thanks to your help. However, I noticed that the manycast servers are usually dropped after being reached 377 "times" without ever becoming selected, though they're all a ms away from each other. For instance, at one moment a client has: remote refid st t when poll reach delay offset jitter == *time-server1.GPS.1 u5 64 377 41.583 -2.303 1.886 NTP.MCAST.NET .ACST. 16 u- 6400.000 0.000 0.002 foo 10.46.4.151 2 u2 64 3770.179 -1.245 0.675 bar 10.46.4.151 2 u2 6430.178 -1.832 0.111 At another, merely 7s later: remote refid st t when poll reach delay offset jitter == *time-server1.GPS.1 u 12 64 377 41.583 -2.303 1.886 NTP.MCAST.NET .ACST. 16 u- 6400.000 0.000 0.002 bar 10.46.4.151 2 u9 6430.178 -1.832 0.111 I think that foo was not selected because of the NTP algorithm, but why was it dropped after reaching 377? TIA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] mtp srver load figures?
On Nov 19, 6:09 pm, "Richard B. Gilbert" wrote: > > Have you considered using either Broadcast or Multicast? No, manycast is the way to go. Unlike the two above, the delay between server and client is constantly measured, rather than only once. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest Redux
On Nov 9, 9:21 am, "David J Taylor" wrote: > > Here's the offset: > http://www.satsignal.eu/ntp/2009-11-07-08-09-Narvik_offset-tod.png > > and here's the rate: > http://www.satsignal.eu/ntp/2009-11-07-08-09-Narvik_frequency-tod.png > > where values for the last two and half days have been overlaid against > time-of-day. I think that we can all agree that these charts indicate that the variation is due to temperature variations. Given that, they also indicate that NTP, as is, is too slow to react to temperature variations, taking something like 8 to 10h to compensate for them, even at 64s sampling period, it seems. The reference stratum 1 server, Feenix, seems to suffer from the same temperature-induced daily accuracy variations. Unfortunately, Mills will probably deny that this is an issue and will probably refuse revisions to his algorithm. If this is the case, perhaps it's time to add another algorithm alongside Mill's and let to the user whether he prefers Mill's algorithm or an alternative. Which alternative I have no idea, but I'd sure like to decide what's good for me, not Mills. TIA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Manycast
On Nov 2, 2:51 pm, Steve Kostecke wrote: > > And, before you start, comment out your restrict lines. I will, but here's what I have: restrict localhost restrict default kod limited nomodify > Also ensure that your routing table shows (Linux shown below): Yes, it looks fine. Thanks for your reply. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Manycast
I'm trying to figure out how to get manycast working, so I set up 3 computers to be clients: disable auth enable bclient tos orphan 8 manycastclient 224.0.1.1 manycastserver 224.0.1.1 And one computer to be a server: disable auth manycastclient 224.0.1.1 manycastserver 224.0.1.1 server pool.ntp.org iburst server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org server 3.pool.ntp.org Nevertheless, the clients just never synchronize with the server. Sometimes, if a client is powered on, it does find the server, however sometimes it drops the association to never find the server again. I'm using 4.2.4p7 in all 4 computers. What gives? TIA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Manycast
Sorry, there's a change in the server configuration that i omitted before. So, I'm trying to figure out how to get manycast working, so I set up 3 computers to be clients: disable auth enable bclient tos orphan 8 manycastclient 224.0.1.1 manycastserver 224.0.1.1 And one computer to be a server: disable auth enable bclient tos orphan 8 manycastclient 224.0.1.1 manycastserver 224.0.1.1 server pool.ntp.org iburst server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org server 3.pool.ntp.org Nevertheless, the clients just never synchronize with the server. Sometimes, if a client is powered on, it does find the server, however sometimes it drops the association to never find the server again. I'm using 4.2.4p7 in all 4 computers. What gives? TIA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntp.cs.mu.oz.au going away - 2010-01-01
Or one could get a plug computer like http://www.tonidoplug.com and use a GPS over USB, which works quite well as David proved. I myself am tempted at one such plug computer just for the geek factor! :-) HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 500ppm - is it too small?
On Aug 17, 8:15 am, Steve Kostecke wrote: > > ./config.h:#define PRESET_TICKADJ 500/hz > ./include/ntp_proto.h:#define NTP_MAXFREQ 500e-6 > ./include/ntpsim.h:#define SLEW 500e-6 /* correction rate (PPM) */ In my point of view, limiting the slew to 500PPM is more critical than handling marginal crystals. I now see that although they have the same value, they don't have to. Or is it assumed elsewhere in the code that they do? TIA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 500ppm - is it too small?
It's not so much a question of clock error as the ability of NTP converging too slowly. If it could slew by more than 500PPM, than it could even avoid time steps, especially backwards. It seems that being able to slew more than 500PPM is what makes Chrony perform so much better than NTP in adverse conditions. I'm starting to wonder if NTP actually stands for "standard (normal) temperature and pressure", to hint at its ideal conditions design... :-) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest
> > This is all noise. You want to filter it out, not track it. No, it isn't. Or at least the temperature effect on the crystal frequency should be tracked more closely, because it can vary significantly enough to throw NTP's loop off. Thanks. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest
On Jul 15, 6:22 am, "Richard B. Gilbert" wrote: > > There is no problem unless you insist on shutting down your system > frequently. That's not the only case. In the real world, ambient temperature changes frequently even in air-conditioned environments, system load affect its internal temperature, network load affects packet jitter, etc. And all this also affects a system's peers, compounding the issue of NTP's slow reaction time. It seems to me that NTP can only work well with a PPS source. For the rest of us, it seems to work only in conditions similar to Delaware. :-) > The subject line seems poorly worded. There is no question of honesty > or dishonesty in the usual sense of those words. But I'm sure that you've come across these words as an idiom, haven't you? ;-) Thanks. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest
On Jul 13, 12:04 pm, Unruh wrote: > > Or use the temperature controlled ntp ( reads the temp and uses that to > estimate the clock rate changes due to temp variations) Where can I find this NTP? TIA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest
On Jul 12, 3:21 pm, Unruh wrote: > > The way ntp works, faster polling also means worse rate estimation and > more annoyance of the providers of the time. The current setup is done > that way to try to minimize the rate error, so if your sconnection to > ntp goes down, your system can freewheel with the greatest accuracy. But that's the issue: NTP allows for good freewheeling if it comes to that, provided that the system maintained in STP and in a vacuum. In the real world, ambient temperature changes frequently even in conditioned environments, network load affects packet jitter, etc. And all this also affects a system's peers, compounding the issue of NTP's slow reaction time. Thanks. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest
On Jul 10, 2:40 pm, Unruh wrote: > > And you have at least a 1/5 chance that IT is the bad server. What do > you do then? Well, bar a false ticker, when it's ignored, it would keep NTP in shorter poll periods. IOW, "honest". I wonder though if the right thing would be to configure 6 servers with half of them limited to 64s polling... Thanks. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Keeping NTP Honest
On Jul 10, 4:42 pm, "Richard B. Gilbert" wrote: > > If you have one server out of five that has gone astray, ntpd should > notice it fairly quickly. Actually, it's anything bu quickly. If NTP has settled at 1024s poll intervals, it may take over 30min or even 45min for it to realize the goof up. Thanks. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Keeping NTP Honest
As I mentioned before, in some cases, NTP relies too much on low- stratum servers, even when they're blatantly wrong. For instance, the last leap second event, when many pool servers were poorly configured. Mulling over that, I wondered how I could tip NTP to scale down the poll period in such cases. So I tried this trick and it seems to work fairly well when only one server is kaput: server pool.ntp.org iburst maxpoll 6 server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org server 3.pool.ntp.org By having one server that remains polled every 64s, NTP could realize more quickly that there was something rotten in Denmark. However, if that one server is neither selected nor a candidate, this trick doesn't work. I'd hesitate to make it the preferred server though. Thoughts? TIA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Very rapid polling
On Feb 15, 4:20 am, gary.limanap...@elisys.co.uk wrote: > > How do I upload a JPEG of the CommView Log File showing the rapid > polling to this discussion? tinypic.com is your friend. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Sudden drop in frequency after software update
On Jan 19, 12:28 am, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote: > > The problem is the TSC calibration routine in recent kernels. But this is only a problem when the kernel uses the default boot option "clocksource=tsc". The article at http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.4.2.8. offers solutions. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Question about 2008 leap second
On Jan 3, 1:00 pm, "Richard B. Gilbert" wrote: > > You might complain to Red Hat and ask them to fix their server. Other > than that, your only other remedy is to configure properly working > servers in sufficient number to outvote the bad guys. > > The leap second was a problem last time and I suspect it will be a > problem again in a few years! That's the thing, clock3.redhat.com was one of the five NTP servers configured. Yet, it was NOT outvoted by the other servers, 3 stratum 2 and 1 stratum 3, all handled the leap second correctly. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Question about 2008 leap second
On Jan 1, 2:45 pm, Evandro Menezes wrote: > > I'm happy that the pool can weed these guys out. However, I'm observing something interesting on my laptop, which has clock3.redhat.com, a stratum 1 server which failed to add the leap second, as one of its pool servers. As it returns from standby, because clock3.redhat.com is the only stratum 1 server, NPT selects it as the primary reference, even if other lesser stratum servers indicate that its time is not correct. NTP eventually selects another lesser stratum server whose time is convalidated by that of other servers, but only after several minutes. Here's the sequence of events: t+00min: clock3.redhat.com is selected t+11min: clock is stepped 650ms (curiously, not by a whole 1s) t+29min: a stratum 2 server is selected t+35min: clock is stepped -710ms t+40min: clock3.redhat.com is selected t+41min: a stratum 2 server is selected What this sequence seems to indicate is that NTP was eager to select a stratum 1 server, in spite of its time not being validated by other servers. Perhaps NTP should look to other servers, even lesser strata ones, before pulling the trigger on a higher stratum server just because its stratum is higher. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Question about 2008 leap second
Here's the culprit: http://www.pool.ntp.org/scores/209.132.176.4 I'm happy that the pool can weed these guys out. Now, if only NTP would query the IP periodically at certain events, such as when coming back from stand by, when a server is a frequent false ticker or unreachable... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Question about 2008 leap second
After 30min from the leap second, I checked my NTP client box and found something interesting. It had 5 pool servers configured, but one of them was unreachable, so it effectively had only four to work with. Two of these ran old versions of NTP (4.1.1) and probably were not aware of the leap second, being off by almost 1s. However, one of them was a stratum 1 server to which the client had selected as the primary reference. Since the client was polling only every 1024s, it had not stepped nor slewed the clock either way, but then it started missing a poll on the good stratum 1 server. Within the hour, it had decided that the new NTP servers were correct and selected one of them as the primary reference. Now, were it the other way around, the client might have selected an older NTP server and would thus get the wrong time. I wonder if the client should also consider the NTP server version when selecting a reference, at least around a leap second event. Happy 2009, especially after a long 2008. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Garmin GPS 18LVC Setup but questions on best way
On Dec 31 2008, 8:49 pm, givemeafckingacctyoudou...@gmail.com wrote: > > So, basically I'm manually adjusting the nmea second reading forward > by 1. > > The SHM(0) gps is still fudged to account for normal lag w/ the time > given on qnan. Here's my conf with the modified gpsd: > #Garmin GPS 18x LVC 0 > server 127.127.28.0 minpoll 4 noselect #Local GPS serial > fudge 127.127.28.0 time1 -0.420 refid GPSa How is this different from leaving the source code intact and fudging the reference by +0.580? TIA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Speed of ntp convergence
Could it be a poor crystal being affected by the temperature change? After all, even with a solid PPS, the system time is controlled by its crystals. David showed data for his Sun system and even x86 systems by Sun have pretty good crystals. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] What happens if ntp server unavailable at start up?
On Sep 12, 8:31 am, Unruh <[EMAIL PROTECTED]> wrote: > > Sounds great. So, let me say I have pool.ntp.org as a server. when my > system comes up (a desktop) the network interface is there, but the dns > server is still dead, and the gateway is still dead. Ie, no address for > pool can be gotten from dns. Does the system keep trying or does it give up > on that server? Similarly, if a connection is dropped, will NTP query the DNS server about the IP of a specified server again or will it binds to an IP address and never give it up? TIA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Significant clock skew in cluster environment
On Jun 24, 3:34 pm, David Woolley <[EMAIL PROTECTED]> wrote: > > The TSC is used to interpolate, in some circumstances, and its > calibration will be totally confused by variable clock rates. That's not an issue anymore in the OP's kervel version. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SBC-ATT Time Servers
On May 23, 8:15 pm, Steve Kostecke <[EMAIL PROTECTED]> wrote: > > slightly reformatted so that it won't wrap on console news-readers... Thank you kindly. > > 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 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SBC-ATT Time Servers
On May 23, 5:16 pm, baffled <[EMAIL PROTECTED]> wrote: > > 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. 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 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 l5 64 3770.000 0.000 0.061 +pool.ntp.org99.150.184.201 2 u 866 1024 377 203.189 -3.074 0.611 -0.pool.ntp.org 132.163.4.1032 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
On May 19, 12:53 pm, "David L. Mills" <[EMAIL PROTECTED]> wrote: > > I don't know wwhat CPU you have, but mine doesn't boil 100 W all the > time. You realize that is 30 A at 3.3 V. Worse yet, given that the typical core voltage is 1.5V, that's actually 67A! You read that right. But you're free to check for yourself an example on page 32 of http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/30417.pdf where the CPU core current can be anywhere between 66A under load and 8A in the halted stated. > I feel very stongly that the present discussion is a colossal red > herring and has nothing whatsoever to do with the present ntpd design. I really think that it'll bite you eventually, but if you prefer to ignore it at the moment... Thanks. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
On May 19, 2:32 am, David Woolley <[EMAIL PROTECTED]> wrote: > > HLT instructions are a complete red herring here. They've been available > for over 35 years, to my personal knowledge, and probably a lot more > than that. No mainstream Linux, and probably no Linux has not used > them. Quite the contrary. Linux has been using HLT for over a decade now ans has always sported better power efficiency than Windows until it started to do so too with Windows 2000. > HLT is special in power management terms in that it doesn't require > heuristics on anything better than MSDOS, for any application that is at > all multi-tasking friendly. Mind you, HLT is merely the first line of defense in power management. HLT makes the CPU enter C1-state, but then the OS guides it when to enter the deeper power-saving C2 and C3 states. > But you've already told us that you get a 90% power saving before you go > to the deep state. In my view, a server that is running at a > sufficiently low CPU load that going deeper that HLT is useful is badly > over-dimensioned. Would you deal with an ideal world or with what is out there? > > the duty cycle resulting from the heuristics used by the hardware or > > the OS to decide when to place the CPU in a deep C-state. > > [A] I suspect it is actually single figure nano-seconds on modern machines. No, it's not. And I don't say it out of a vague suspicion, but out of knowledge gained when designing the algorithms at AMD, later used by both Windows and Linux. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
On May 18, 12:39 am, [EMAIL PROTECTED] (Danny Mayer) wrote: > > It's not doing nothing. If the CPU is on standby nothing, including > ntpd, should be running. One thing is the CPU in standby, something else the whole system. In modern x86 systems running Linux, the CPU enters C1 state when there's no task to run. When the CPU is in the C1 state, the internal circuitry is shutdown, reducing the power used by the by about one order of magnitude. Some processors will automatically enter deeper CPU standby states, others require OS intervention. Linux will use all available CPU standby states as often as possible by default. So even after a few fractions of a second in the C1 state, it can put the CPU in C2 (or C3) state, when the processor disconnects the core from the bus interface keeping caches coherent (or not), reducing the power to a fraction of the C1 state. Amazingly enough, servers spend most of the time in a C state, whether waiting for disk access or for network replies. Therefore, it's a critical part of power management in data-center. In data-centers, every W used by equipment will require another W in AC. With several systems, it's not difficult to end up with a few kWh everyday due to NTP, which translates into possibly hundreds of dollars in additional costs. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
On May 16, 6:44 pm, "David L. Mills" <[EMAIL PROTECTED]> wrote: > > With respect, you miss the point. The ntpd does not require a tickle > every second just to scan for polls; it requires that tickle in order to > discipline the clcok frequency. The additional cycles necessary to link > to the next association structure, then increment and test a variable, > are way, way down in the noise. I don't pretend to know NTP innards, but wouldn't it be possible to select the scale of updates? And, please, don't consider the power used by NTP itself, but rather the power used by the CPU idling in a higher power state than before NTP woke it up. Modern processors can draw 100W without doing anything useful, but it falls down to less than 10W it it's allowed run the HALT instruction instead when there's nothing to do. The picture that Red Hat refers to is that the CPU is removed from a deep C-state in order to run NTP for microseconds and then it remains in the running state for a few fractions of a second until it goes back to a deep C-state. So it's not a matter of NTP's duty cycle, but the duty cycle resulting from the heuristics used by the hardware or the OS to decide when to place the CPU in a deep C-state. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
On May 15, 9:28 pm, "David L. Mills" <[EMAIL PROTECTED]> wrote: > > A timer interrupt is required each second to update the clock frequency > no matter what. In addition, a sweep is made through the associations to > see if a poll is pending. It would be in principle posssible to > implement a system of queues to avopid sweeping the associations each > second, but that would save very few cycles, add some more cycles and > additional complexity. NTP could set a reminder for itself not for the next second, in case there's a poll pending, but for the minimum period left among all polled servers. This would be pretty simple and power-friendly. Mind you, a CPU uses orders of magnitude less power in a stand-by state, even a simple halt-instruction, than running. See page 3 of http://download.intel.com/technology/itj/2006/volume10issue02/vol10_art03.pdf for more info. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
On May 16, 12:29 pm, "David L. Mills" <[EMAIL PROTECTED]> wrote: > > In modern machines a timer interupt takes about one microsecond and to > scan through the one-second code is really quick. So, we are talking > about an overhead in the order of .1 percent. In terms of performance, yes, but in terms of power, no. If NTP gets the CPU out of a deep stand-by state, then it may take hundreds of milliseconds for the CPU to go back to that state. Moreover, NTP 1s- timer may prevent the CPU from going to even deeper stand-by states. With this in mind, if NTP wakes the CPU up in order to do nothing, it's not doing the right thing, IMHO. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] frequency adjusting only
On May 4, 2:37 pm, "David L. Mills" <[EMAIL PROTECTED]> wrote: > > On symmetry, etc. There are both gravitational and velocity corrections > relative to both Earth and solar system barycentric time amounting to > some 15 ms, but current space missions don't worry much about that. The > mission times are relative to a clock onboard the spacecraft; nothing > else matters. Our Earth-Mars simulations didn't worry about these > effects either. I suspect disciplining an orbiter/rover clock to these > corrections will be dominated by the frequency noise of affordable > oscillators. Maybe not. Just curious, but did you have to deal with relativistic effects of relative time dilation as the craft speed increased? TIA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Time reset
On another note, I wish that NTP had an option to disable backward jumps in time. Is it something that has been considered before? TIA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Galileo's atomic clocks
On Apr 24, 11:55 am, [EMAIL PROTECTED] (Danny Mayer) wrote: > Here's an interesting article on the Giove-B satellite's atomic clocks > being tested when it launches: IF it launches AND remains in reliable operation... :-/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Linux 11-minute mode (RTC update)
On Apr 10, 7:50 am, Serge Bets <[EMAIL PROTECTED]> wrote: > > I'm not aware of any tool using this method. What are those PIE-timer > platforms? Do you have one? Why not go straight to the horse's mouth at http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2680/t/do ? HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Time slew doesn't seem to work
The 15-minute correction is due to the default configuration for "stepout". In my experience, it's either due to another piece of software to discipline the clock or a bad drift file, when just erasing it and restarting NTP should help. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Linux 11-minute mode (RTC update)
It shouldn't be forgot that the RTC can only be set and read with a granularity of seconds only. The 11-minute scheme doesn't synchronize the RTC to the exact second and when read, even waiting for up to a second for the read to change, it lacks accuracy. All this in addition to thermal drifting of the reference crystal frequency. The bottom line is that the RTC is just a little better than inputing the time manually whenever the system comes up. Of course, this is fine if time synchronization and discipline is soon taken over by NTP. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Windows Time with NTPv4
On Mar 17, 5:17 am, David Woolley <[EMAIL PROTECTED]> wrote: > > My impression was that the Windows workaround didn't allow one to create > peers without authentication, but rather treated such an attempt as > actually creating a simple client relationship. Yes, this seems to be what I've observed in my case (NTP 4.2.0). ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Windows Time with NTPv4
On Mar 13, 3:56 am, Martin Burnicki <[EMAIL PROTECTED]> wrote: > > Do the Windows system run ntpd or w32time? If they run ntpd then > authentication could be configured correctly. I don't know how any version > of w32time could be configured to support NTP's symmetric keys or even > autokey. They run w32time. > This seems to indicate that ntpd is running on the XP machines and has been > configured correctly with authentication. Actually not. I had this in ntp.conf: restrict default kod limited nopeer tos orphan 4 enable bclient disable auth Then, the w32time systems appeared as servers in the output of "ntpq - p" and "ntpdc -c listpeers" confirmed their status as peers. When I removed the last line above, as w32time doesn't support authentication keys, the w32time systems stopped showing up as servers, even though their association mode remained 1. So w32time was happy, believing it was a peer (if it indeed behaves as a peer is left to be demonstrated), and NTP kept on working without the interference of w32time in its choice of servers. > Of course the admin of a NTP server does not want his NTP server's time be > changed just because some dumb client sends some packet asking to do so. But I think that with the proper restrictions NTP will do the right thing. > This is what happens with w32time which under certain conditions sends > "peer" requests instead of "client" requests. Since those w32time clients > have neither been configured nor authenticated as peers, the question is > how they should be handled by ntpd. I think that they're being handled just fine by NTP. NTP does what ntp.conf tells it to do and it can handle w32time stupidity just fine as in my case above. Thanks. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Windows Time with NTPv4
But doesn't symmetric association require authorization or is it only true when there's a keys file? I ask because after following this thread, I noticed that NTP running on our NAS had three Windows XP systems as peers. Luckily, their jitter sucked and being themselves synchronized to the NAS they were never selected as references. Anyways, I removed the line disabling authorization and NTP didn't accept those systems as peers anymore, even though they still connect to the NAS using mode 1. Thanks. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Success with NTP
I recently bought a ReadyNAS to work as a server in a small-office environment. The neat thing about this NAS is that it runs Linux on a customized SPARC processor and provides SSH access. I figured that it would make an interesting NTP server to the dozen or so computers in the network, but it did not support NTP out of the box. So I did the usual stuff, downloading the source and building it. After a couple of days it had disciplined the NAS time quite well, as it can be seen at http://www.readynas.com/forum/viewtopic.php?f=35&t=14984. Kudos to all who've contributed to making it so easy to get NTP up and running even in an embedded environment, especially to David Mills. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SBC-ATT Time Servers
I noticed that too. I guess that keeping the routers in sync is good enough when they're not in the NTP serving business... I just stopped using them at home. But at work I use Road Runner's NTP servers which quite usable ones. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Issues with w32tm on AD network
On Feb 27, 7:06 am, Ryan Malayter <[EMAIL PROTECTED]> wrote: > > This is not true. Windows time service uses UDP/123, just like every > other NTP or SNTP implmentation. All of Microsoft's documentation that > I have read (and I think I have read everything concerning w32time) > agrees on that point. That's true. But W32TIME also registers the time service to the domain or AD hierarchy, allowing the workstations to synchronize with it. But when the workstations contact the DC, I think that NTP will reply instead. > If you disable both client and server aspects of w32time, it does > nothting whatsoever, I would think. Isn't it the idea, to take W32TIME out of the clock discipline business and just let it take care of DC stuff while NTP handles all the timekeeping on the server and on the workstations? After all, NTP is a much better package to not only discipline the clock as well as to monitor and administer. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Issues with w32tm on AD network
On Feb 26, 2:57 am, Martin Burnicki <[EMAIL PROTECTED]> wrote: > > Of course they still can't both open port 123, so the result should be what > David Wooley has mentioned in his reply. No, but the workstations use an RPC to UDP port 445 or 137, not 123. W32TIME only uses the UDP port 123 when it's configured to be an NTP client or server, both disabled in my post above. All that W32TIME would do in the configuration above would be to serve domain workstations the system time, which is itself then disciplined by NTP. It may not be the ideal configuration, but it works. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Issues with w32tm on AD network
I'm pretty sure that it's possible to run both NTP and W32TIME at the same time on the same Windows system provided that only NTP is used to keep the clock under discipline and W32TIME is used solely to provide the time for the domain workstations. In order to do this, the NTP service is added to the dependency list of the W32TIME service through the Platform SDK utility SC: sc config w32time depend= NTP It's also necessary to disable W32TIME from trying to discipline the clock using the registry editor (REGEDIT) under HKLM\CurrentControlSet \Services\w32time: [TimeProviders\NtpClient] InputProvider=DWORD:0 [TimeProviders\NtpServer] InputProvider=DWORD:0 This will cause NTP to start before W32TIME and thus NTP will take over disciplining the Windows DC clock and the domain workstations will still communicate with W32TIME. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Leap second functional question
On Feb 19, 10:52 am, Unruh <[EMAIL PROTECTED]> wrote: > > No, in UTC all years are 86400 seconds, even if during that year a second > was added or subtracted. Ie, utc retains no memory of leap seconds. Aren't you confusing UTC and GMT? Or maybe I'm the one confusing both... Thanks. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] no ntp synchronisation: 2s to 6s time shift !
On Feb 12, 4:40 pm, David Woolley <[EMAIL PROTECTED]> wrote: > > tsc refers to the counter in recent Intel Architecture chips that counts > the processor clock cycles. It is somewhat vulnerable to power management. Not only PM, but also differences between processor cores. Some models of multi-core processors from AMD or Intel provide one TSC per core, which may cause discrepancies when the TSC is read on one core at a time tick and on another core at the next time tick. This is also true for multi-processor systems: TSCs are not guaranteed to be correlated among processors, not even their relative monotonicity. The Linux kernel goes through hoops to account for such discrepancies among the several TSC instances, but it's never 100% successful neither 100% accurate. Using the TSC as a time reference is tempting because reading it takes just a few CPU cycles to read it. Other time references, such as ACPI- PM and HPET, take much longer to read, even 1000X longer, though they provide consistent reads and accuracy no matter from which processor or core. The speed to get the time-of-day from the kernel may be important when running some applications, such as data-base servers, when every transaction is time-tagged and the time it takes to get the time-of- day can contribute significantly to its performance. Therefore, for time-keeping purposes, it's better to avoid the kernel from using the TSC as its time-reference, in favor of other timers available in the system, unless running an application whose performance may be gated by getting the time-of-day. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] GPS with PPS without any soldering requirements?
On Feb 11, 8:16 am, "Richard B. Gilbert" <[EMAIL PROTECTED]> wrote: > > Forget the USB. USB has unpredictable latencies that make it a poor > choice for timing. Doesn't the USB protocol have an isochronous mode that guarantees real- time, predictable communication? I'm not an USB expert, just wondering whether it could actually be used for timing purposes, even if the NMEA message itself is not used, but rather its mere delivery as a proxy for the timing pulse. TIA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Dual-core systems - AMD - Windows Vista
On Dec 3, 2:28 pm, "David L. Mills" <[EMAIL PROTECTED]> wrote: > Yes, the nanocode is aware that individual CPU clock rates can differ > and vary over time. Since the only purpose is to interpolate between > timer interrupts (Alpha) or second overflows (FreeBSD), all the code > does is count the number of PCC cycles since the last interrupt to > construct a divisor to scale the PCC accordinly. It does this once each > second for every CPU. Forgive me for my persistence, but on some OS'es, such as Windows and Linux, the CPU frequency of a certain core can vary by more than 2x, depending on system load and the power savings profile. for example, I had one such server with 2 dual-core processors and its frequency could vary between 1GHz when the system was idling to 2.2GHz under heavy load. The CPU clock governor could go between both extremes within the same second. Can the code handle such situation? Thanks for your reply. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Dual-core systems - AMD - Windows Vista
On Dec 1, 10:42 am, "David L. Mills" <[EMAIL PROTECTED]> wrote: > The multiple-CPU nanokernel code that left here and is in the Alpha > kernel assumes each CPU has an individual cycle counter and the timer > interupts are vectored to a designated CPU. There is a data structure > associated with each CPU that holds the measured current cycle counter > scaling and offset, which is updated once each second by interprocessor > interrrupt. A call to read the system clock lands on a j-random CPU, > which reads the global time maintained by timer interrupts and > interpolates according to the current CPU values. Just curious, but is it aware that the CPU clock frequency may change on the fly and differently for each processor for power-management purposes? As a result, the rate of the count by RDTSC may vary. For example, all multi-core AMD Opteron processors, both Barcelona generation and the previous one. Thanks. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Can a clock drift be too big for ntpd?
On Oct 25, 2:40 pm, Evandro Menezes <[EMAIL PROTECTED]> wrote: > - power management with dynamic CPU clock control may confuse some > kernels on some systems, when using the kernel boot option helps. Ahem, "when using the kernel boot option NOTSC helps." ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Can a clock drift be too big for ntpd?
Having had my share of bad HW and poorly configured SW leading to haywire in NTP, I'd add a couple of suggestions to what others have already said: - power management with dynamic CPU clock control may confuse some kernels on some systems, when using the kernel boot option helps. - some patches tackle buggy chipsets, when the best is to copy the original config file, as others suggested, and just changing the option you're interested in. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time.windows.com
On Oct 9, 6:42 pm, "David L. Mills" <[EMAIL PROTECTED]> wrote: > Goaded by an earlier comment that the Windows default time server > time.windows.com was flawed, I cranked up an association and here's what > happened. First, it now does the client/server protocol correctly. > Second, the packet drop rate is over 50 percent(!). Third, it is not a > primary serer; it chimes a primary server at MIT synchronized by CDMA. > Fourth, the roundtrip delay from Delaware is over 150 ms, which as the > net flies is further than Alaska. The time is not too bad, about +-7 ms > with jitter occasionally over 200 ms(!). I myself gave up using it. It often ends being tagged as a false ticker: State Remote Refid Stratum TypeWhenPollReach Delay Offset Jitter x time.windows.combonehed.lcs.mit.edu 2 Unicast server 182 64 134 114.799 48.332 4.480 Pathetic. It beats me why NIST even lists it. Thanks. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Home Time Server
On Oct 9, 2:42 pm, "David L. Mills" <[EMAIL PROTECTED]> wrote: > In regards to how the clocks work, all the above WWV clocks use the > munutes and seconds pulses as well as he 100-Hz subcarrier modulation. I was referring to WALL clocks sync'ed via WWV. ;-) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] More Aggressive Pruning
This server, http://www.pool.ntp.org/scores/63.240.161.99, is often off significantly and unreachable most of the time. Yet, because it's probably listed with a high bandwidth, it often makes to the top of the pool (0.us.pool.ntp.org). I wonder if it would make sense to make the points deducted from the server proportional to the declared bandwidth. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Home Time Server
On Oct 9, 12:38 am, "David J Taylor" <[EMAIL PROTECTED] bit.nor-this-bit.co.uk> wrote: > A nice idea, but I would not - as the radio clocks I have seen can be out > by 500ms and are not that reliable. My GPS is far better. If I didn't > have GPS, or I wanted a backup though, I might bet one. That's because the clocks use only the minute "chime" in the WWV signal. They might as well use the PPS "chime" in WWV. > By the way, I don't see why Internet-connected PCs should be that far out, > as Microsoft now runs its own NTP server, and most recent versions of > Windows include at least an SNTP client. Should really be pre-configured. Microsoft's time server is a joke, both in terms of accuracy and reachability. It definitely cannot keep up with its clients, even though they are configured to sync up only weekly, which in and of itself is another joke. Cheers. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Home Time Server
With accurate time references freely available in the ether (WWV, GPS, TV and CDMA), no clock in existance should have to be set manually, ever. Yet, even in this day and age, car clocks, VCRs, DVRs and stereos blink 12:00. And with virtually all PCs connected at least part-time to the Internet, it's unacceptable that many of them display the time of by many minutes, if not even the wrong century. Now, there are many fine time servers available for networks. However, I wonder if with the increasing popularity of the NTP pool if some home units wold make sense. For instance, there are many wall clocks synchronized by WWV. If they had a WiFi interface, they could be a poorman's S1 NTP server (hello, La Crosse?). At least some NTP pool aficionados would consider getting one, yes? ;-) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Refreshing IP Addresses
On Sep 28, 4:39 pm, [EMAIL PROTECTED] (Danny Mayer) wrote: > Check out the pool configuration option: > pool us.pool.ntp.org > > for example. That's in the right direction, IMHO. And then, refreshing the IP addresses in some situations is a must when only one pool name is specified, as servers come and go in the pool. Thanks. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Refreshing IP Addresses
On Sep 28, 4:15 pm, [EMAIL PROTECTED] (Danny Mayer) wrote: > This is the next item on my worklist but requires a lot of work. > Seehttp://support.ntp.org/bin/view/Dev/DNSServerFailoverfor details. I would add that a server/peer option should be added to enable/ disable this feature. > ... so there won't be immediate relief for the pool even > when implemented. Indeed, it'll probably be years before a new release catches on. However, with the fact that some Linux distro's now use the pool by default and the impressive growth of servers in the pool, the sooner this is done, the better. Thanks. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Refreshing IP Addresses
On Sep 28, 3:03 pm, [EMAIL PROTECTED] (Hal Murray) wrote: > One good time would be when the server stops responding. > Or sends you a kiss-of-death packet. It might take > some special DNS hacking to answer the question "Is this > server still in the pool?" It seems to me that it doesn't make sense to keep tied to IP addresses when certain events occur, and KOD or unreachable are certainly good opportunities to resolve names again, with perhaps beneficial side- effects to the NTP pool. It would work pretty well too if an option such as openNTP's "servers" were added. I find that if one day all someone has to do is to specify "ntp" for the "servers" options and thus get a bunch of the ISP's NTP servers, it's going to be a better day than today. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP Third party client on Windows OS ?
On Sep 26, 12:11 pm, Evandro Menezes <[EMAIL PROTECTED]> wrote: > The fact remains that W32TIME is doing a "better" (your definition may > vary) job than NTP to keep my system time in "lock-step" (your > definition may vary) with a reference. I think I found out why NTP couldn't manage. I figured that as it was stepping every 20min by 0.45s, approximately, it would be the equivalent of an error of roughly 350PPM, or well within the capabilities of NTP. So I checked out the contents of the drift file: 450PPM. In other words, NTP was over compensating! I deleted the drift file and fired up NTP after stopping W32TIME. It's now keeping the time in sync pretty well: http://img218.imageshack.us/img218/3609/peerstatscf6.png (never mind the spike, when the system lost network connection). The only reason I can think of how NTP got such a huge drift was during installation. Although the package states that its stopping W32TIME, somehow it didn't, as I noticed a few hours later. A short time, yet it seems to have done damage enough. Thanks. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Refreshing IP Addresses
Many former participants of the NTP pool have stated that they continue with lingering NTP clients after they left the pool. The reason for this is that ntpd never tries to resolve an IP address (assuming that *.pool.ntp.org was used) ever again. Therefore, clients which are seldom rebooted, will stick to the same NTP servers for a long time. I was wondering if it would make sense to open some windows when ntpd could resolve the addresses again. One such window would be when ntpd steps the time, which puts it into a state perhaps similar to when it's started. I imagine that such a new resolution of addresses for the NTP servers in the pool would also help distributing the load among them more fairly. Thoughts? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP Third party client on Windows OS ?
On Sep 25, 10:48 pm, [EMAIL PROTECTED] (Danny Mayer) wrote: > Huh? What accuracy? All it's telling you is how close the local clock is > to the expected clock. It tells you nothing about how accurate it is. If > the remote clock is off by 5 minutes then so will your clock be, but it > will track that inaccuracy. Is that what you want? That's true, but W32TM is the only tool that works for both W32TIME and NTP. Besides, I used this W32TM trick when both NTP and W32TIME were running, so it woould be as bad for both time synchronization facilities. And the results by W32TM for NTP confirm its peerstats, so it's not that far off. The fact remains that W32TIME is doing a "better" (your definition may vary) job than NTP to keep my system time in "lock-step" (your definition may vary) with a reference. I don't mean by this that W32TIME has better algorithms than NTP. I wouldn't be able to state that. But I suspect that Microsoft knows its kernel better, if not using a back-door that only they know about, as it's happened in the past, and that for a lousy clock as the one in my system it manages to do well. Besides, I think that NTP is proven to do a good jon on Windows too. Hey, it does a fine job on my personal laptop! ;-) Thanks. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP Third party client on Windows OS ?
On Sep 24, 12:04 pm, Ryan Malayter <[EMAIL PROTECTED]> wrote: > Actually, there's no need for the batch file, w32tm has the > "stripchart" functionality built-in: > C:\>w32tm /stripchart /computer:1.us.pool.ntp.org /period:5 /dataonly Thanks for the tip. Here are the results running solely NTP: U:\>w32tm /stripchart /computer:... /period:60 /dataonly Tracking ... [de.ad.be.ef]. The current time is 09/24/07 12:32:45 (local time). 12:32:45, -00.0194939s 12:33:45, -00.0436869s 12:34:45, -00.0625716s 12:35:45, -00.0783218s 12:36:45, -00.0947555s 12:37:45, -00.1187566s 12:38:45, -00.1410585s 12:39:45, -00.1569414s 12:40:45, -00.1779342s 12:41:45, -00.1936857s 12:42:46, -00.2148667s 12:43:46, -00.2302365s 12:44:46, -00.2465449s 12:45:46, -00.2663136s 12:46:46, -00.2836268s 12:47:46, -00.3044920s 12:48:46, -00.3239726s 12:49:46, -00.3446843s 12:50:46, -00.3580108s 12:51:47, -00.3824622s 12:52:46, -00.0349870s 12:53:46, -00.0580199s 12:54:47, -00.0743980s 12:55:47, -00.0908707s 12:56:47, -00.1102019s 12:57:47, -00.1303569s 12:58:47, -00.1475506s 12:59:47, -00.1749632s 13:01:14, -00.1892795s 13:02:14, -00.2051528s 13:03:14, -00.2101208s Pretty much the same as the chart I sent before. Now, stopping NTP and starting W32TIME using the same NTP servers as above and MinPoll and MaxPoll set to 6 and 10, respectively: U:\>w32tm /stripchart /computer:... /period:60 /dataonly Tracking ... [de.ad.be.ef]. The current time is 09/24/07 13:03:17 (local time). 13:03:17, -00.2172203s 13:04:17, -00.1805773s 13:05:17, -00.1506772s 13:06:17, -00.1295513s 13:07:17, -00.1050171s 13:08:17, -00.0753630s 13:09:17, -00.0661526s 13:10:17, -00.0579732s 13:11:17, -00.0491729s 13:12:17, -00.0348759s 13:13:17, -00.0285594s 13:14:17, -00.0207110s 13:15:17, -00.0175595s 13:16:17, -00.0142039s 13:17:18, -00.0131223s 13:18:18, -00.0060913s 13:19:18, -00.0028175s 13:20:18, -00.0032156s 13:21:18, -00.0015146s 13:22:18, -00.0065485s Note how W32TIME smoothly brought the time back in sync. I guess that for such a lousy clock as the one in my system, W32TIME, perhaps because it knows the Windows kernel better, I hate to say it, works better better than NTP. Thanks. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP Third party client on Windows OS ?
On Sep 23, 1:37 pm, Evandro Menezes <[EMAIL PROTECTED]> wrote: > Here's what I mean:http://img250.imageshack.us/img250/8264/peerstatsde3.png > (the flat line is for the time that the system was shutdown). And, for completeness sake: http://img259.imageshack.us/img259/7841/loopstatsfh7.png. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
