Locking memory in ntp - comp.protocols.time.ntp

Gopal wrote in message ... >Ntpd has a mlockall() function call which locks all the current and >future memory. Why do we need to lock the memory. To prevent page faults, which can cause unnecessary variation in the response time to receiving timestamps. Groetjes, Maarten Wiltink

Maarten Wiltink wrote: > Gopal wrote in message ... > > >>Ntpd has a mlockall() function call which locks all the current and >>future memory. Why do we need to lock the memory. > > > > To prevent page faults, which can cause unnecessary variation in > the response time to receiving timestamps. Does it help to point out that mlockall() is a wish and a prayer? There are per-process and per-machine limits on how many pages may be locked in memory... IOW the only guaranteed way of locking all pages in physmem is to run without swap.

Michael Sierchio wrote in message ... <mlockall> >IOW the only guaranteed way of locking all pages in physmem is >to run without swap. And the bulb lit up. Is this standard procedure in real life NTP servers? Groetjes, Maarten Wiltink

"Gopal" <k_gopalakrishnan@hotmail.com> wrote in message news:f6b5173d.0309251325.2a1c99c3@posting.google.com... > Ntpd has a mlockall() function call which locks all the current and > future memory. Why do we need to lock the memory. The whole purpose of NTP is to keep time accurately. If you have unpredictable delays as memory is faulted in, you can't do that. DS

"Michael Sierchio" <kudzu@tenebras.com> wrote in message news:peGdnSIEpemHyemiRVn-iw@speakeasy.net... > Maarten Wiltink wrote: > > Gopal wrote in message ... > >>Ntpd has a mlockall() function call which locks all the current and > >>future memory. Why do we need to lock the memory. > > To prevent page faults, which can cause unnecessary variation in > > the response time to receiving timestamps. > Does it help to point out that mlockall() is a wish and a prayer? > There are per-process and per-machine limits on how many pages > may be locked in memory... > IOW the only guaranteed way of locking all pages in physmem is > to run without swap. Running without swap doesn't guarantee that. In fact, it increases the chances that pages will be discarded because rarely-used modified pages from other programs can't be swapped out. DS

David Schwartz wrote: > "Michael Sierchio" <kudzu@tenebras.com> wrote in message > news:peGdnSIEpemHyemiRVn-iw@speakeasy.net... > > >>Maarten Wiltink wrote: > > >>>Gopal wrote in message ... > > >>>>Ntpd has a mlockall() function call which locks all the current and >>>>future memory. Why do we need to lock the memory. > > >>>To prevent page faults, which can cause unnecessary variation in >>>the response time to receiving timestamps. > > >>Does it help to point out that mlockall() is a wish and a prayer? >>There are per-process and per-machine limits on how many pages >>may be locked in memory... > > >>IOW the only guaranteed way of locking all pages in physmem is >>to run without swap. > > > Running without swap doesn't guarantee that. In fact, it increases the > chances that pages will be discarded because rarely-used modified pages from > other programs can't be swapped out. No, pages will not be discarded, though processes will be selected for termination upon an attempt to access allocated pages that are not mapped to pmem. (at least in the BSD universe) But it's easy enough to set process limits so that this never happens, and that errant daemons get killed and restarted. I have a stratum 1 server based on a net4501, you can't get any more "no swap" than that. You shouldn't be running anything (other than essentials) on an ntp reference server anyway -- and if your desktop machine pages out memory belonging to ntpd? Frankly, my dear, I don't give a damn. [my original point, not fully stated, is that mlock()/munlock() semantics are well-defined, and mlockall's aren't -- the POSIX statement leaves a lot of wiggle room for implementation dependencies]

"Michael Sierchio" <kudzu@tenebras.com> wrote in message news:Y5CdnT3aUt-JLumiRVn-sA@speakeasy.net... > > Running without swap doesn't guarantee that. In fact, it increases the > > chances that pages will be discarded because rarely-used modified pages from > > other programs can't be swapped out. > No, pages will not be discarded, though processes will be selected > for termination upon an attempt to access allocated pages that are > not mapped to pmem. (at least in the BSD universe) Yes, clean pages will be discarded. I'm not sure why you think they won't. It would be rather foolish not to discard clean pages. DS

David Schwartz wrote: > Yes, clean pages will be discarded. I'm not sure why you think they > won't. It would be rather foolish not to discard clean pages. With swap disabled? No. When swapping, the BSD model pages somewhat aggressively, even putting text pages in swap, because it's considerably more efficient to retrieve via the paging mechanism than through the filesystem.

Maarten Wiltink wrote: > Michael Sierchio wrote in message ... > <mlockall> > >>IOW the only guaranteed way of locking all pages in physmem is >>to run without swap. > > > And the bulb lit up. > > Is this standard procedure in real life NTP servers? A stratum-1 server will of course have enough RAM to never swap, a good stratum-2 server ditto. My S-2 servers also use burst mode against its primary inhouse S-1 references, this handles the case where an ARP table entry have aged out, causing the first poll in a burst series to take significantly longer than the rest. Terje -- - <Terje.Mathisen@hda.hydro.com> "almost all programming can be viewed as an exercise in caching"

Terje, One of the reasons the original burst mode was implemented in the first place was the nasty surprise when the poll interval exceeded the router ARP timeout. This happened with early Proteon routers which clobbered the first NTP packet received in order to construct an ARP request in the same buffer and then forgot about the NTP packet. Apparently, everything old is new again. Dave Terje Mathisen wrote: > > Maarten Wiltink wrote: > > > Michael Sierchio wrote in message ... > > <mlockall> > > > >>IOW the only guaranteed way of locking all pages in physmem is > >>to run without swap. > > > > > > And the bulb lit up. > > > > Is this standard procedure in real life NTP servers? > > A stratum-1 server will of course have enough RAM to never swap, a good > stratum-2 server ditto. > > My S-2 servers also use burst mode against its primary inhouse S-1 > references, this handles the case where an ARP table entry have aged > out, causing the first poll in a burst series to take significantly > longer than the rest. > > Terje > > -- > - <Terje.Mathisen@hda.hydro.com> > "almost all programming can be viewed as an exercise in caching"

Terje Mathisen wrote: > My S-2 servers also use burst mode against its primary inhouse S-1 > references, this handles the case where an ARP table entry have aged > out, causing the first poll in a burst series to take significantly > longer than the rest. I have posted the following in this newsgroup before. It works quite well to solve ARP timeout problems in FreeBSD 4.8. I run a cron job every 15 minutes. All it does is: arp -d 123.123.123.123 (your IP address) ping -n -c 1 -q 123.123.123.001 (ping your gateway or similar) I found that it was necessary to use the -d switch to actually delete the route. Otherwise it would expire every 20 minutes whether or not there was any traffic on the interface. With this technique the ARP entry NEVER expires, because it is deleted before it can. This allows much more predictable polls, since the first isn't delayed by an ARP request.

Bohdan Tashchuk wrote: > I have posted the following in this newsgroup before. It works > quite well to solve ARP timeout problems in FreeBSD 4.8. > > I run a cron job every 15 minutes. All it does is: > > arp -d 123.123.123.123 (your IP address) > ping -n -c 1 -q 123.123.123.001 (ping your gateway or similar) Admittedly repulsive but strangely beautiful ;-) A well-calibrated torque hammer is indispensible.

>I run a cron job every 15 minutes. All it does is: > arp -d 123.123.123.123 (your IP address) >I found that it was necessary to use the -d switch to actually delete >the route. Otherwise it would expire every 20 minutes whether or not >there was any traffic on the interface. I'm missing someting and it might be interesting. Why is a system sending itself packets over an (Ethernet?) interface? Or why do they matter for time keeping accuracy? Does NTP do that? I just checked my Linux box and arp -a doesn't show an entry for itself. (Yes, NTP is running.) > ping -n -c 1 -q 123.123.123.001 (ping your gateway or similar) Pinging the gateway is a good first step, but that may not solve the problem if the NTP servers you want to talk to are on the other side of the gateway. Burst mode sounds better and better. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.

hmurray@suespammers.org (Hal Murray) wrote in news:vncsa32ln8552d@corp.supernews.com: > >> ping -n -c 1 -q 123.123.123.001 (ping your gateway or similar) > > Pinging the gateway is a good first step, but that may not solve > the problem if the NTP servers you want to talk to are on the other > side of the gateway. > It shouldn't be a problem unless the NTP traffic through the gateway takes a different path than all the other traffic through the gateway. My border router always has the MAC of its default gateway (in this case, the cable company) cached. > Burst mode sounds better and better. > If the gateway is under your control, wouldn't it just be easier to add a static ARP entry?

>It shouldn't be a problem unless the NTP traffic through the gateway takes >a different path than all the other traffic through the gateway. My border >router always has the MAC of its default gateway (in this case, the cable >company) cached. The NTP server may be several hops past your gateway. You have to make sure all those arp caches are loaded with the appropraite info. Usually arp cache problems are on the first or last hop, but that just makes it all the more obscure when it isn't. There can also be the same sort of problems with routing caches. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.

"David Schwartz" <davids@webmaster.com> wrote in message news:<bl1t5t$ii4$1@nntp.webmaster.com>... > "Gopal" <k_gopalakrishnan@hotmail.com> wrote in message > news:f6b5173d.0309251325.2a1c99c3@posting.google.com... > > > Ntpd has a mlockall() function call which locks all the current and > > future memory. Why do we need to lock the memory. > > The whole purpose of NTP is to keep time accurately. If you have > unpredictable delays as memory is faulted in, you can't do that. > > DS So, If you dont do paging then you need not lock the memory. Is that right? Gopal

"Gopal" <k_gopalakrishnan@hotmail.com> wrote in message news:f6b5173d.0309291140.473f004b@posting.google.com... > > The whole purpose of NTP is to keep time accurately. If you have > > unpredictable delays as memory is faulted in, you can't do that. > > > > DS > > So, If you dont do paging then you need not lock the memory. Is that right? It depends upon whether your OS discards clean pages. If it does, locking the memory would still be needed. DS

k_gopalakrishnan@hotmail.com (Gopal) writes: > "David Schwartz" <davids@webmaster.com> wrote in message news:<bl1t5t$ii4$1@nntp.webmaster.com>... > > "Gopal" <k_gopalakrishnan@hotmail.com> wrote in message > > news:f6b5173d.0309251325.2a1c99c3@posting.google.com... > > > > > Ntpd has a mlockall() function call which locks all the current and > > > future memory. Why do we need to lock the memory. > > > > The whole purpose of NTP is to keep time accurately. If you have > > unpredictable delays as memory is faulted in, you can't do that. > > > > DS > > So, If you dont do paging then you need not lock the memory. Is that right? Yes, but if you don't do paging, you don't have to worry about the RAM ntpd needs as well, or did I miss something? Regards, Ulrich