Re: Re: time is running out

Der Herr Hofrat wrote:
>>Could this also be the cause of CLOCK_GPOS running 150us/s (13 sec in 24h) faster
>>than CLOCK_REALTIME? I have reported this problem before, but no answer/fix yet.
>>
> 
> Hi !
> 
>  just ran 2.4.26 (Slackware 10.0 default config) and compared this to 2.4.27-rtl-3.2-rc1
> (with the fixes from latest CVS) - time drift seems to be the same for both setups (5s/12h
> vs 4s/12h) so I assume that this is a linux inprecision issue and not realy related to
> rtlinux - checked my firewall that has an uptime of 235 days - offset is -216 seconds as
> the box has not ntpd running - linux 2.2.13 (486/75), so I guess drifts in the range of a
> few seconds/day are not that unusual. Does anbody else see any increased drift of ntp with
> older rtlinux versions running ?

So the CLOCK_GPOS is only driven by the linux kernel, untouched by rtlinux? I'm about to test
running a plain linux kernel to see if I get the same drift as before. Unfortunately since
a few days I can't contact a ntp server due to a firewall problem.

I can't believe a drift of a few seconds per day is normal. Even a 3$ watch performs better
than that. The strange thing is that the real-time clocks seems to run at the right pace.
Every night I run ntpdate -su someserver followed by hwclock --systohc. In the logs I always
see the (world) clock being adjusted about 13 seconds. And measuring the difference in clock
speed of CLOCK_GPOS and CLOCK_REALTIME gives 151 us/s (on all our boxes). 151 us/s * 3600 s * 24
is also 13 s! So CLOCK_REALTIME is exacty OK, but CLOCK_GPOS runs away.

>  Also what do you have in /etc/ntp.drift ??

Zero. A assume this is only used when running the ntpd deamon. I don't want to run any
services that touch a clock during day time.


I have tested what happens after fixing the HZ constant.
System: RedHat 2.4.20 rtl3.2-pre2

The test module (below) which retrieves CLOCK_REALTIME and CLOCK_GPOS once every second
and prints the difference between the offsets between the two clock values. If the clocks
run at the same pace this difference should be zero on average.

 From /var/log/messages after loading clktest.o (time differences in ns):

Feb  7 14:02:04 lumen kernel: 0: 150735
Feb  7 14:02:05 lumen kernel: 1: 151000
Feb  7 14:02:06 lumen kernel: 2: 151000
Feb  7 14:02:07 lumen kernel: 3: 151000
Feb  7 14:02:08 lumen kernel: 4: 151000
Feb  7 14:02:09 lumen kernel: 5: 151032
Feb  7 14:02:10 lumen kernel: 6: 151000
Feb  7 14:02:11 lumen kernel: 7: 151119
Feb  7 14:02:12 lumen kernel: 8: 151000
Feb  7 14:02:13 lumen kernel: 9: 151032
Feb  7 14:02:14 lumen kernel: 10: 151640
Feb  7 14:02:15 lumen kernel: 11: 150328
Feb  7 14:02:16 lumen kernel: 12: 151032
Feb  7 14:02:17 lumen kernel: 13: 151000
Feb  7 14:02:18 lumen kernel: 14: 151119

For the linux boxes in my office GPOS runs 151 us/s faster than REALTIME.
I tried this on 7 other client machines and they all show the same numbers
(within 1 us or so).


After setting the HZ parameter in asm-i386/param.h to 100 and rebuilding
the kernel:

Feb  7 15:56:22 lumen kernel: 0: -1376901963963
Feb  7 15:56:23 lumen kernel: 1: -2203056
Feb  7 15:56:24 lumen kernel: 2: -16700
Feb  7 15:56:25 lumen kernel: 3: -16700
Feb  7 15:56:26 lumen kernel: 4: -16668
Feb  7 15:56:27 lumen kernel: 5: -16732
Feb  7 15:56:28 lumen kernel: 6: -16700
Feb  7 15:56:29 lumen kernel: 7: -16700
Feb  7 15:56:30 lumen kernel: 8: -16668
Feb  7 15:56:31 lumen kernel: 9: -16732
Feb  7 15:56:32 lumen kernel: 10: -16668
Feb  7 15:56:33 lumen kernel: 11: -16732
Feb  7 15:56:34 lumen kernel: 12: -16700
Feb  7 15:56:35 lumen kernel: 13: -16700
Feb  7 15:56:36 lumen kernel: 14: -16700
Feb  7 15:56:37 lumen kernel: 15: -16700
Feb  7 15:56:38 lumen kernel: 16: -16668

It's better but stil not good. The two initial high values I can't explain
from my test program. See code below. This shouldn't happen at all!
I'm running 2.4.20-rtl3.2-pre2. Do I need to upgrade?

Theo


This is the test module I used:

#include <rtl.h>
#include <posix/time.h>
#include <pthread.h>

static pthread_t mythread;

#define CLOCK1  CLOCK_REALTIME
#define CLOCK2  CLOCK_GPOS

static void* testTask(void* arg)
{
     hrtime_t realtime, gpostime, offset, prevoffset, diff;
     int n;

     pthread_make_periodic_np(pthread_self(),
	clock_gethrtime(CLOCK_RTL_SCHED), 1000000000);

     realtime = clock_gethrtime(CLOCK1);
     gpostime = clock_gethrtime(CLOCK2);
     prevoffset = offset = gpostime - realtime;
     diff = 0;

     for (n = 0; n < 60; n++) {
     	pthread_wait_np();
     	realtime = clock_gethrtime(CLOCK1);
     	gpostime = clock_gethrtime(CLOCK2);
     	offset = gpostime - realtime;
	diff = offset - prevoffset;
	prevoffset = offset;
	rtl_printf("%d: %lld\n", n, diff);
     }

     return 0;
}

int init_module(void)
{
     pthread_create(&mythread, NULL, testTask, NULL);

     return 0;
}

void cleanup_module(void)
{
     pthread_cancel(mythread);
     pthread_join(mythread, NULL);
}

_______________________________________________
Rtl mailing list
[email protected]
http://www2.fsmlabs.com/mailman/listinfo/rtl