Date: Thu, 31 Jul 1997 05:00:01 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, jhay@mikom.csir.co.za Cc: freebsd-bugs@hub.freebsd.org Subject: Re: kern/4112: Re: PPSCLOCK kernel diffs Message-ID: <199707301900.FAA28271@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> Do you want the whole LBL copyright on the merged version? > >We should not take the decision to move it to ttycom.h lightly. The >xntpd code check for ppsclock.h, so if we change that we will have >to teach xntpd about it. Not that it is impossible, it's not too Let's keep pppsclock.h. I'm still concerned about ambiguous ioctl numbers. We already have several. They work because they go to different line disciplines, but kdump gets confused. kdump wouldn't compile if its case statement actually covered all the numbers. >> John Hay tried calling hardpps() from siointr1(). I don't like this, >> because hardpps() is probably too slow on slow machines. > >I have code where I change the original hardpps() function to softpps() >and then create a new hardpps() that only store the timestamp and usec >values and set a flag. Then I call hardpps() from hardclock() if the >flag is set. I have tried to put it inside the 1 second if, but it did >not work too well. Outside of it it seemed to work much the same as calling >hardpps() directly from sio. Will that help Bruce? Perhaps the 1 second version fails because 2 samples occasionally arrive in the same 1+epsilon seconds interval. I think the call from inside hardclock() is OK for a machine dedicated to timekeeping (you won't want to run things like pcaudio or profiling that depend on a low latency and/or high frequency clock interrupt). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707301900.FAA28271>