UNIX Socket FAQ

A forum for questions and answers about network programming on Linux and all other Unix-like systems

You are not logged in.

#1 2009-10-15 10:59 AM

jacquesdirac
Member
Registered: 2009-02-06
Posts: 15

Re: Time running behind

Hi,

To get more precise timing, we changed HZ from 100 to 500 in the kernel (2.4.32) source file (include/asm-i386/param.h). This seemed to work perfectly.

Now, we face some problem that the time is running behind about 20 minutes a day. Could this be a side effect of the above?
And if so, are there some other things we have to adjust when changing HZ?

Hope someone could give some advise.

Best regards!

Offline

#2 2009-10-15 06:08 PM

jfriesne
Administrator
From: California
Registered: 2005-07-06
Posts: 348
Website

Re: Time running behind

At the risk of pointing out the obvious... does the problem go away if you change HZ back to 100?

Offline

#3 2009-10-27 08:48 AM

jacquesdirac
Member
Registered: 2009-02-06
Posts: 15

Re: Time running behind

I tested this to be sure and: Yes, it does!

Offline

#4 2009-10-27 10:26 AM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,239

Re: Time running behind

What happens if you change HZ to 1000? Is the 20 minute delay consistent
or does it vary? Are you running ntpd or anything else that might change the
time now and then, like from a cron job?

A HZ of 100 might be hardcoded in some assembly files, probably clock
related ones, so you miht want to grep for anything like that in the asm dir.

Offline

#5 2009-10-28 10:47 AM

jacquesdirac
Member
Registered: 2009-02-06
Posts: 15

Re: Time running behind

Offline

#6 2009-10-28 11:27 AM

jacquesdirac
Member
Registered: 2009-02-06
Posts: 15

Re: Time running behind

In timex.h I found:

#ifdef CONFIG_MELAN
#  define CLOCK_TICK_RATE 1189200 /* AMD Elan has different frequency! */
#else
#  define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
#endif

#define CLOCK_TICK_FACTOR	20	/* Factor of both 1000000 and CLOCK_TICK_RATE */
#define FINETUNE ((((((long)LATCH * HZ - CLOCK_TICK_RATE) << SHIFT_HZ) * \
	(1000000/CLOCK_TICK_FACTOR) / (CLOCK_TICK_RATE/CLOCK_TICK_FACTOR)) \
		<< (SHIFT_SCALE-SHIFT_HZ)) / HZ)

What does 'CLOCK_TICK_FACTOR' do? And could 'CLOCK_TICK_RATE' have some influence?

In param.h I also found:

#ifdef __KERNEL__
# define CLOCKS_PER_SEC	100	/* frequency at which times() counts */
#endif

Do I have to change 'CLOCKS_PER_SEC' when I change HZ?

Offline

#7 2009-10-29 05:51 AM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,239

Re: Time running behind

Offline

#8 2009-11-02 02:53 PM

jacquesdirac
Member
Registered: 2009-02-06
Posts: 15

Re: Time running behind

Thanks for your reply.

Unfortunately this is not for fun and learning...

I applied the HZ kernel patch from Robert Love. Then the CONFIG_HZ worked fine, but the time kept running behind.

Suddenly the idea of changing HZ to 512 came up to me. And, what a surprise, it works great: Time is now perfect in sync :-).
Don't know why this is the solution, but if you do, leave a message (for the sake of learning ;-) ).

Offline

#9 2009-11-04 01:56 AM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,239

Re: Time running behind

Maybe a rounding error that doesn't occur with HZ=100, but does for bigger values?
Perhaps in that monstrous FINETUNE define.

Offline

Board footer

Powered by FluxBB