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.
