NTP for HPVM guest

[Gilles Allard]

This is a subject for discussion, not a request for help.
When configuring an HPVM guest, HP documents the classical approach where the guest polls a NTP server.
ref:http://docs.hp.com/en/T2767-90180/T2767-90180.pdf
There is, however, another approach that is potentially better. I'm talking about the broadcast NTP where a server sends a broadcast message to all VM hosts and guests on the same subnet.
I can't find any comparison about the two approaches. What do you think about it? Any practical experience?

[Steven E. Protter · Accepted solution]

Shalom,

Most organizations only permit one system to access the outside Internet and get ntp data.

The best approach for large numbers of host is to use that server to get the ntp information to many hosts.

I've seen many approaches. This is not a lot of data, and either approach will work just fine.

SEP

[Michal Kapalka (mikap)]

hi,

its a discusion betveen Unix Administrators and Network Administrators, in our company we have one NTP servers for all servers, and all clients sync the time from the central NTP server, the network team don't permited any broadcast on our lan. In my opinion its for me better that each server request the NTP server, i don't need any network admin.

mikap

[rick jones]

Having only one NTP server is probably "better" than having two - there is an old saying about having two clocks meaning never knowing what time it is :) - but it isn't as good as having three - giving an ntpd a choice among multiple, ostinsibly independent sources of time is goodness.

My take on broadcast vs polling is one that may only serve to show my ignorance, and is not based on practical experience, but with polling, one has a direct measured estimate of the latency between the client and the server. With broadcast mode, IIRC that has to be specified by hand and may not track queueing delays in the switches etc under load.

[Michael Steele_2]

Most broadcasts over an entire subnet are prevented because they add to the traffic. NTP syncs up at what interval? minpoll 4 seconds max poll 12 seconds? Any you want to broadcast to 253 ips every 4 to 12 seconds?

I think your network could be used more reliably than spraying it every 4 seconds.

[Gilles Allard]

Replying to Michael:
"you want to broadcast to 253 ips every 4 to 12 seconds? "
The virtue of a broadcast message is that you send a single packet to many recipients. It's more efficient than unicast messages for this application (NTP).

Replying to Rick:
"with polling, one has a direct measured estimate of the latency between the client and the server"
In my case, all the recipients are in a server room so latency is very low.

The real question of this topic is about virtual machines. Two of my VM hosts contain 11 VM guests. Should I care about the latency of the VM host (and VM switch)?

[Michael Steele_2]

"...The virtue of a broadcast message is that you send a single packet to many recipients. It's more efficient than unicast messages for this application (NTP)..."

I could not disagree with you more. I have never seen a common O/S utility, like NTP, set up to spray the network intrusively every 4 to 12 seconds.

Consider this, in the list of business priorities, money making applications are given higher priority and should be allowed all the bandwidth needed. Money making application users have a greater priority than O/S administrators. Admins are there only to make things easier for the making of money and not to set themselves above users. And NTP just doesn't make you money. And UNIX admins, just don't make you money.

If you have a cost accounting setup, Unix admins and other techies are either in administrative cost centers, or service based cost centers, AKA expense based cost centers. Billing, is an profit based cost center. Sales, is a profit based cost center.

In this format, NTP also falls into an expensed based cost center.

[Steven E. Protter]

Shalom again,

Your network administrator will come and bother you about the broadcast. It will annoy, upset and perturb you.

Peaceful relations with network admins can not be overrated.

I recommend the server NOT broadcast and the clients ask the server for updates when they need them. Which will use network bandwidth but you'll be able to tell the network administrators is necessary and efficient.

As opposed to broadcasting when you have no proof anyone is listening.

SEP

[rick jones]

I suspect that network latency getting to/from a VM is probably not that difficult for NTP to deal with. If you are intensely curious to measure it, I would suggest a netperf TCP_RR test comparing a VM guest with bare iron.

IIRC the minpoll and maxpoll settings are shift counts not actual second values, and my experience with NTP on HP-UX and Linux is that once it has synced with a server the polling interval will back-off to as many asn 1024 seconds between polls. It may not back-off as far if the sync with the server(s) isn't as good but it will still back-off rather far. So, I don't think that volume of NTP traffic should be a concern.

[Bill Hassell]

As mentioned, broadcast is limited to a single subnet by virtually every network setup. And as Rick mentions, broadcast will not result in the same accuracy as the standard query.

xntpd will poll the NTP server once every 64 seconds -- that at full speed. When accuracy is good, the poll backs off to as much as 1024 seconds (17 minutes). NTP is so slow with very small messages, that you can take the slowest HP-UX box you can find (25-50 Mhz), put it on a 10 Mbit LAN and it will sync THOUSANDS of servers without breathing hard. If you login to one of your clients, run ps -ef and then exit, you will have created more network traffic than xntpd would use during the entire day.

NTP is a protocol that requires no network load analysis -- it is almost too small to measure.