SMP-system (2xP4)
I noticed a huge cpu usage of xinetd with 2.6.14-rc4
starting with the first ntp request.
12:45:10 xeon2 xinetd[1245]: service dgram_time, recvfrom: Bad address (errno = 14)
12:45:40 xeon2 last message repeated 651771 times
12:46:41 xeon2 last message repeated 1329225 times
12:47:42 xeon2 last message repeated 1308902 times
2.6.13.3 works fine.
--
Klaus
On Wed, 12 Oct 2005 16:36:57 +0200, Klaus Dittrich said:
> I noticed a huge cpu usage of xinetd with 2.6.14-rc4
> starting with the first ntp request.
Umm.. why is xinetd listening for ntp requests at all? I'm pretty sure that
xinetd fighting with xntpd for control of the socket isn't going to work nicely,
although I admit being mystified as to (a) why this ever worked for you and
(b) what specifically changed in -rc4 to cause the CPU spin.
What was the most recent kernel known to work, and what does the xinetd
config file entry for NTP look like?
[email protected] wrote:
>On Wed, 12 Oct 2005 16:36:57 +0200, Klaus Dittrich said:
>
>
>>I noticed a huge cpu usage of xinetd with 2.6.14-rc4
>>starting with the first ntp request.
>>
>>
>
>Umm.. why is xinetd listening for ntp requests at all? I'm pretty sure that
>xinetd fighting with xntpd for control of the socket isn't going to work nicely,
>although I admit being mystified as to (a) why this ever worked for you and
>(b) what specifically changed in -rc4 to cause the CPU spin.
>
>What was the most recent kernel known to work, and what does the xinetd
>config file entry for NTP look like
>
>
2.6.13.3 works. I can compile an try 2.6.14-rc[1,2,3].
service time
{
type = INTERNAL
id = dgram_time
socket_type = dgram
protocol = udp
user = root
wait = yes
only_from = 192.168.168.36 192.168.168.39
}
This setup worked for years now. The machine
(192.168.168.32) is the time-server and I have
chosen this setup to simulate and verify a real
world scenario.
/etc/ntpd.conf
..
driftfile /etc/ntp.drift
logfile /var/log/ntp
#authenticate no
server 127.127.8.0 prefer mode 2 # Meinberg ANZ_14 (Standart Telegramm)
server 127.127.1.1 # Local clock in case of disaster
fudge 127.127.1.1 stratum 10 # Poor stratum for local clock
--
Klaus
On Wed, 12 Oct 2005 20:27:00 +0200, Klaus Dittrich said:
> service time
> {
> type = INTERNAL
> id = dgram_time
That, my friends, is UDP port 37, not UDP port 123 where NTP lives.
[email protected] wrote:
>On Wed, 12 Oct 2005 20:27:00 +0200, Klaus Dittrich said:
>
>
>
>>service time
>>{
>> type = INTERNAL
>> id = dgram_time
>>
>>
>
>That, my friends, is UDP port 37, not UDP port 123 where NTP lives.
>
>
>
The time requester is a router. I looked up
it's configuration and indeed TIME/UDP is the
protocol used.
You are right, I mixed up ntp with time. Sorry.
So, the corretced message is ..
I noticed a huge cpu usage of xinetd with 2.6.14-rc4
starting with the first time/udp request.
I will try older rc's today to narrow the point in time
this problem started.
--
Klaus
This (service dgram_time, recvfrom: Bad address (errno = 14))
behavior of the kernel started with 2.6.14-rc2-git9.
I am not a kernel-guru and the log shows several net changes.
--
Klaus