Re: [ntp:questions] time delta between clients
In article [EMAIL PROTECTED] [EMAIL PROTECTED] (Danny Mayer) writes: Per Hedeland wrote: In article [EMAIL PROTECTED] Tom Smith [EMAIL PROTECTED] writes: Rick Jones wrote: Rick Jones [EMAIL PROTECTED] wrote: Here is what I have now that I've dropped the minpoll from the server and dropped LOCAL: peer bl480c2 minpoll 3 maxpoll 4 iburst server 10.208.0.1 iburst server 10.0.0.1 server 10.202.1.1 Scratch that - I commented-out the last two servers. rick jones I think you may have problems, even in the mythical zero-latency network, getting the skew consistently below double the clock tick of the system with the largest clock tick interval. Hm, if you were a newbie here, I'd assume that you simply don't know what you're talking about, but since you aren't, I must be misunderstanding you as you appear to be saying that two Unix hosts with the traditional 100 Hz clock (on the same LAN) couldn't achieve a skew consistently below 20 ms - while (at least) sub-millisecond offsets in such setups are commonplace and discussed here every other day. Apparently not even Windows has the kind of problem you suggest anymore. While Rick may be a relative newbie to NTP he has had years of conducting performance analysis of applications and systems. His performance testing of BIND9 is probably *the* seminal reference on DNS testing. Uh, your point being? I'm sure your description is correct even though I have no knowledge of that subject (which doesn't seem to be relevant here), and I specifically said that I *didn't* consider Rick a newbie to NTP - based on the very limited knowledge of *that* subject that I have, namely past postings in this forum. Which is why I found his statement surprising, and assumed that I must be misunderstanding it. Are you saying that you agree with that statement? Or maybe you can explain how I'm misunderstanding it? --Per Hedeland [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP server Dimensioning process
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (T Manikandan-Q3926C) wrote: NTP to be implemented on the Server running RHEL [Red hat Enterprise Linux] To handle at least 10 clients in a network. I've not had any experience of actually running such a size of server, so you had maybe better wait to see if anyone challenges the following: How the RAM, CPU and the HDD need to be dimensioned? RAM: significantly less than the minimum spec for RHEL and negligible compared with that on the minimum specification machine acceptable as a donation to a UK charity. Kernel buffer space for IP packets might be the main issue, which may depend on your network drivers. (ntpd locks down the whole of libc, so can appear large, but most of that locked down code is shared with other applications; if you are concerned about RAM, don't use RHEL, use an embedded environment with just what is needed in the libraries.) HDD: negligible compared with RHEL and the above charity spec; CPU: (this is more speculative) negligible compared with the charity specification and small compared with that needed to run RHEL in graphical mode. The main source of uncertainty is likely to be the network driver. You do need hardware floating point, but that has been satisfied by the charity requirements for almost ten years. Basically, I'd suggest that your decision to use RHEL indicates that you are not working anywhere near the limits. PS Never start a new thread by replying to an existing article. People ignoring the existing thread will not have seen your thread. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP server Dimensioning process
T Manikandan-Q3926C wrote: Can anyone brief how will be the dimensioning process for the NTP server in the following scenario? NTP to be implemented on the Server running RHEL [Red hat Enterprise Linux] To handle at least 10 clients in a network. How the RAM, CPU and the HDD need to be dimensioned? If the clients are running the reference implementation of ntpd then every single client will send maximum 1 request every 64 seconds, i.e. 10 client produce a mean load of 10/64~1560 req/s. Even a AMD Geode CPU running at 500 MHz with 128 MB RAM here can handle more than 15000 req/sec, i.e. 10 times as much as you need. The relevant HDD space you need for ntpd depends only on the amount of log files you want to keep, e.g. the loopstats file and its history. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Danny Mayer wrote: Harlan Stenn wrote: This is becoming more and more common - people assign 1 IP per 'service' so the service can be easily put on an arbitrary machine, or they use several IPs for the service on different subnets/vlans for network architecture and security reasons. This sounds like laziness. Instead of updating the DNS to change the IP address of a name, they add move the IP address to a different machine. It doesn't make much sense to me. Really? Consider: The service is administered locally to a system and although the IP address may be administered by someone else, it will usually be fairly close (i.e. the local sub-net) and doesn't require any further administration once assigned. The DNS may be administered non-locally or even globally, with potentially two separate organizations required to change it (one for forward lookups and one for reverse lookups). Once the DNS is changed, it takes some time to propagate the change due to caching, and already running applications may never see the change unless they re-resolve. Having one service per IP address also makes the job of load-balancing software much simpler. Brian Utterback ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Brian Utterback wrote: Danny Mayer wrote: Harlan Stenn wrote: This is becoming more and more common - people assign 1 IP per 'service' so the service can be easily put on an arbitrary machine, or they use several IPs for the service on different subnets/vlans for network architecture and security reasons. This sounds like laziness. Instead of updating the DNS to change the IP address of a name, they add move the IP address to a different machine. It doesn't make much sense to me. Really? Consider: The service is administered locally to a system and although the IP address may be administered by someone else, it will usually be fairly close (i.e. the local sub-net) and doesn't require any further administration once assigned. The DNS may be administered non-locally or even globally, with potentially two separate organizations required to change it (one for forward lookups and one for reverse lookups). Once the DNS is changed, it takes some time to propagate the change due to caching, and already running applications may never see the change unless they re-resolve. Having one service per IP address also makes the job of load-balancing software much simpler. Brian Utterback I believe that there is a solution to the DNS caching problem. Each DNS record can be given a Time To Live or TTL. If you are planning to change the record, set the TTL to seven days, then six, five, four, three, two, one. . . . All of those cached records should expire at more or less the same time. It's not perfect but it works. If you time it just right, you can minimize the amount of disruption. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Richard B. Gilbert wrote: I believe that there is a solution to the DNS caching problem. Each DNS record can be given a Time To Live or TTL. If you are planning to change the record, set the TTL to seven days, then six, five, four, three, two, one. . . . All of those cached records should expire at more or less the same time. It's not perfect but it works. If you time it just right, you can minimize the amount of disruption. Still requires the clients to re-resolve the server address (something ntpd famously does not do currently; desparate attempt at getting back on-topic ;-) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Jan Ceuleers wrote: Richard B. Gilbert wrote: I believe that there is a solution to the DNS caching problem. Each DNS record can be given a Time To Live or TTL. If you are planning to change the record, set the TTL to seven days, then six, five, four, three, two, one. . . . All of those cached records should expire at more or less the same time. It's not perfect but it works. If you time it just right, you can minimize the amount of disruption. Still requires the clients to re-resolve the server address (something ntpd famously does not do currently; desparate attempt at getting back on-topic ;-) Well, how often does a typical NTP server change it's address? Any server with a dynamic address is going to create problems. AFAIK it's not a common situation. ISTR that you can use ntpdc or ntpq (I'm too lazy to look up which one) to drop or add servers without needing to restart ntpd. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Using a PPS source without a GPS receiver?
The setup: O(10) FreeBSD 6.2 machines in a rack, a PPS source, and an NTP server somewhere on the same network. Is it possible (and if so, how?) to configure ntpd on these machines so they get the rough time over NTP from the network's NTP server, and use the PPS source so they stay better synchronized to each other (with less than a foot of coax between each machine, I'm not worried about the extra nanosecond!) Thanks, /ji ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
