Running with the last diff for about an hour... Some pedantry fix to please -Werror (probably not useful): --- imsg.c Sun May 17 12:51:51 2009 +++ imsg.c.new Sun May 17 13:00:20 2009 @@ -110,7 +110,8 @@ } struct buf * -imsg_create(struct imsgbuf *ibuf, enum imsg_type type, u_int32_t peerid, +imsg_create(struct imsgbuf *ibuf __attribute__((__unused__)), + enum imsg_type type, u_int32_t peerid, pid_t pid, u_int16_t datalen) { struct buf *wbuf; --- ntp_msg.c Sun May 17 12:51:51 2009 +++ ntp_msg.c.new Sun May 17 12:33:31 2009 @@ -39,8 +39,9 @@ } int -ntp_sendmsg(int fd, struct sockaddr *sa, struct ntp_msg *msg, ssize_t len, - int auth) +ntp_sendmsg(int fd, struct sockaddr *sa, struct ntp_msg *msg, + ssize_t len __attribute__((__unused__)), + int auth __attribute__((__unused__)) ) { socklen_t sa_len; ssize_t n;
On Sun, 2009-05-17 at 10:10 +0000, Mike Belopuhov wrote: > On Sat, May 16, 2009 at 20:41 +0000, Michael Shalayeff wrote: > > re > > suddenly bugs started to popup (: > > looks like i hit this bug also. > > ntpd[7676]: Lost child: child terminated; signal 8 (Floating point exception) > > > there was a division by zero in poll scaling. > > i guess the offset never been small enough (: > > i would really appreciate if somebody actually > > read through the diff for possibly more tiny little > > stupid mistakes that might've crept in (: > > cu > > > > On Fri, May 15, 2009 at 04:13:29PM +0000, Michael Shalayeff wrote: > > > re > > > we've found a real bug behind the buffer sizes. > > > dns resolver was not limiting the response (ip list) > > > to any maximum number which is even defined already > > > as MAX_SERVERS_DNS. thus check that now. > > > now we can get away w/ much smaller buffers and > > > correct (non-overflowing) behaviour (; > > > cu > > > > > > On Fri, May 15, 2009 at 03:19:02PM +0000, Michael Shalayeff wrote: > > > > re > > > > first try out of the zoo shown that we need to keep MAX_IMSGSIZE > > > > at 8k for more dns addresses (: > > > > diff updated > > > > cu > > > > > > > > On Fri, May 15, 2009 at 02:58:36PM +0000, Michael Shalayeff wrote: > > > > > re > > > > > forgot to mention that while there touching structs > > > > > also rearrange fields for optimal alignment (save memory) > > > > > and shrink io buffers to a half K from 8k since we will > > > > > never have a valid packet larger than that. > > > > > cu > > > > > > > > > > On Fri, May 15, 2009 at 02:39:29PM +0000, Michael Shalayeff wrote: > > > > > > re > > > > > > using floating point for ntpd math is not a good idea. > > > > > > this comes from the fact that mixing small and large numbers > > > > > > in one fp expression leads to a huge loss of precision. > > > > > > besides the fact that there is no need to change representation > > > > > > from fixed point (ntp timestamps) to floating point and > > > > > > back all the time. plus to that using fpu in daemons is > > > > > > not polite and eats even more cpu time (: > > > > > > > > > > > > this diff converts internal math to fixed point (64bit) > > > > > > except for one place -- local clock frequency drift. > > > > > > this part is still broken as one can see by constantly > > > > > > flipping frequency adjucements in the logs since math > > > > > > currently used performs computation on very large > > > > > > numbers (products of time stamps) and very small > > > > > > ones (products of time offsets) and thus totally useless. > > > > > > i have figured a better way to follow frequency drift > > > > > > but that can be done in the next step. > > > > > > > > > > > > this has ran on both i386 and sparc64 for months now > > > > > > and only has shown massive improvement in precision > > > > > > (decrease of deviation). thus local clock offset still > > > > > > flips every few hours from positive to negative and back > > > > > > due to broken frequency adjucements. > > > > > > > > > > > > please read and try.