I have been running ntp 4.1.1 under Reliant UNIX successfully for a long
time. It stabilized pretty fast with drift around 50.

Recently I tried 4.2.0 just to discover that it does not work for me. It
claims my clock is too buggy and I know it is not :)

bor@itsrm2% ntpdc -c loop
offset:               -0.365980 s
frequency:            -500.000 ppm
poll adjust:          -30
watchdog timer:       246 s

First suspect was adjtime resolution. Reliant has 10ms adjtime resolution
and 4.1.1 contains special code to account for that (it rounds adjustments
to nearest 10ms multiple and saves the remainder as residual; on get it
fakes better resolution by adding residual back). Patch was originally
written by me and used the same technique as for SCO and then was cleaned up
and unified with SCO case by Kamal A Mostafa.

Then I noticed "tick" config file variable that is supposed to set
resolution for sys_adjtime (not documented anywhere); but setting it to
10000e-6 (this *is* 10ms is not it?) did not actually changed anything.

I am somewhat out of ideas. Of course it may be that it needs *very* long
time now but then again, it looks as regression to me.

Oh, and I cannot step time due to buggy settimeofday call so I am forced to
use slew all the time. Still clock must be pretty much in sync as I started
4.2.0 immediately after killing 4.1.1

Any help appreciated. Ideas how to debug it too :)

-andrey

PS when I write it frequency error as reported in syslog went from -502PPM
to -501PPM. Now, it may be good sign but it took almost three hours. With
this pace it will need half a year to climb back to 50PPM :)

-andrey,

I see the problem. Some time ago the scheme you suggested was
generalized for an value of quantum specified in sys_tick in the
systime.c library routine. This was done so that the kernel adjtime()
routine would work with both microsecond and nanosecond kernels, as well
as 10-ms kernels. However, the #ifdefs needed to invoke 10 ms for those
kernels that deserve it were not implemented. Sorry about that; the code
has been corrected in the development version.

I haven't been closely following the current release process details,
but there is a good chance you might soon see the development stuff in a
snapshot.

Dave 

Borzenkov Andrey wrote:
> 
> I have been running ntp 4.1.1 under Reliant UNIX successfully for a long
> time. It stabilized pretty fast with drift around 50.
> 
> Recently I tried 4.2.0 just to discover that it does not work for me. It
> claims my clock is too buggy and I know it is not :)
> 
> bor@itsrm2% ntpdc -c loop
> offset:               -0.365980 s
> frequency:            -500.000 ppm
> poll adjust:          -30
> watchdog timer:       246 s
> 
> First suspect was adjtime resolution. Reliant has 10ms adjtime resolution
> and 4.1.1 contains special code to account for that (it rounds adjustments
> to nearest 10ms multiple and saves the remainder as residual; on get it
> fakes better resolution by adding residual back). Patch was originally
> written by me and used the same technique as for SCO and then was cleaned up
> and unified with SCO case by Kamal A Mostafa.
> 
> Then I noticed "tick" config file variable that is supposed to set
> resolution for sys_adjtime (not documented anywhere); but setting it to
> 10000e-6 (this *is* 10ms is not it?) did not actually changed anything.
> 
> I am somewhat out of ideas. Of course it may be that it needs *very* long
> time now but then again, it looks as regression to me.
> 
> Oh, and I cannot step time due to buggy settimeofday call so I am forced to
> use slew all the time. Still clock must be pretty much in sync as I started
> 4.2.0 immediately after killing 4.1.1
> 
> Any help appreciated. Ideas how to debug it too :)
> 
> -andrey
> 
> PS when I write it frequency error as reported in syslog went from -502PPM
> to -501PPM. Now, it may be good sign but it took almost three hours. With
> this pace it will need half a year to climb back to 50PPM :)

Dave,

which #ifdefs do you mean? What I see in current code is

libntp/systime.c:sys_adjtime()

        ticks = (long)(dtemp / sys_tick + .5);
        adjtv.tv_usec = (long)(ticks * sys_tick * 1e6);
        dtemp -= adjtv.tv_usec / 1e6;
        sys_residual = dtemp;

(of course it was sys_tick, not sys_adjtime, sorry). There are no #ifdefs
around it.

ntpd/ntp_config.c:

        { "tick",               CONFIG_ADJ },

....
getconfig(
....
                    case CONFIG_ADJ: {
                            double ftemp;

                            sscanf(tokens[1], "%lf", &ftemp);
                            proto_config(PROTO_ADJ, 0, ftemp, NULL);
                        }
                        break;


ndpt/ntp_proto.c:proto_config()
        /*
         * Set the adjtime() resolution (s).
         */
        case PROTO_ADJ:
                sys_tick = dvalue;
                break;


I do not see any #ifdefs and the code in sys_adjtime() in principle does the
same as old one from 4.1.1. There is a bug in get_systime (trivial patch
follows) but it should not change anything in this case because ntpd does
not even _tries_ to correct time so it does not have any residual. I do have
tick in ntp.conf:

bor@itsrm2% head /etc/ntp.conf
# ntp 4.2.0
# tick 10ms
tick 10000e-6

Could you point to corr. patches (changeset number or whatever) that you
mean?

Thank you

Patch for get_systime:

--- ntp-4.2.0/libntp/systime.c.adjtime        Thu Jul 17 14:27:23 2003
+++ ntp-4.2.0/libntp/systime.c  Tue Mar  2 19:10:37 2004
@@ -85,7 +85,7 @@ get_systime(
        if (dtemp >= 1) {
                dtemp -= 1;
                now->l_i++;
-       } else if (dtemp < -1) {
+       } else if (dtemp < 0) {
                dtemp += 1;
                now->l_i--;
        }


"David L. Mills" <mills@udel.edu> wrote in message
news:4044D195.CA74DF58@udel.edu...
> -andrey,
>
> I see the problem. Some time ago the scheme you suggested was
> generalized for an value of quantum specified in sys_tick in the
> systime.c library routine. This was done so that the kernel adjtime()
> routine would work with both microsecond and nanosecond kernels, as well
> as 10-ms kernels. However, the #ifdefs needed to invoke 10 ms for those
> kernels that deserve it were not implemented. Sorry about that; the code
> has been corrected in the development version.
>
> I haven't been closely following the current release process details,
> but there is a good chance you might soon see the development stuff in a
> snapshot.
>
> Dave
>
> Borzenkov Andrey wrote:
> >
> > I have been running ntp 4.1.1 under Reliant UNIX successfully for a long
> > time. It stabilized pretty fast with drift around 50.
> >
> > Recently I tried 4.2.0 just to discover that it does not work for me. It
> > claims my clock is too buggy and I know it is not :)
> >
> > bor@itsrm2% ntpdc -c loop
> > offset:               -0.365980 s
> > frequency:            -500.000 ppm
> > poll adjust:          -30
> > watchdog timer:       246 s
> >
> > First suspect was adjtime resolution. Reliant has 10ms adjtime
resolution
> > and 4.1.1 contains special code to account for that (it rounds
adjustments
> > to nearest 10ms multiple and saves the remainder as residual; on get it
> > fakes better resolution by adding residual back). Patch was originally
> > written by me and used the same technique as for SCO and then was
cleaned up
> > and unified with SCO case by Kamal A Mostafa.
> >
> > Then I noticed "tick" config file variable that is supposed to set
> > resolution for sys_adjtime (not documented anywhere); but setting it to
> > 10000e-6 (this *is* 10ms is not it?) did not actually changed anything.
> >
> > I am somewhat out of ideas. Of course it may be that it needs *very*
long
> > time now but then again, it looks as regression to me.
> >
> > Oh, and I cannot step time due to buggy settimeofday call so I am forced
to
> > use slew all the time. Still clock must be pretty much in sync as I
started
> > 4.2.0 immediately after killing 4.1.1
> >
> > Any help appreciated. Ideas how to debug it too :)
> >
> > -andrey
> >
> > PS when I write it frequency error as reported in syslog went
from -502PPM
> > to -501PPM. Now, it may be good sign but it took almost three hours.
With
> > this pace it will need half a year to climb back to 50PPM :)

Andrey,

As I said, I made the changes in the current ntp-dev at the development
site. The changes should appear in a snapshot sometime soon, but
production of the snapshots and releases is handled by other sturdy
hands.

Dave

Andrey Borzenkov wrote:
> 
> Dave,
> 
> which #ifdefs do you mean? What I see in current code is
> 
> libntp/systime.c:sys_adjtime()
> 
>         ticks = (long)(dtemp / sys_tick + .5);
>         adjtv.tv_usec = (long)(ticks * sys_tick * 1e6);
>         dtemp -= adjtv.tv_usec / 1e6;
>         sys_residual = dtemp;
> 
> (of course it was sys_tick, not sys_adjtime, sorry). There are no #ifdefs
> around it.
> 
> ntpd/ntp_config.c:
> 
>         { "tick",               CONFIG_ADJ },
> 
> ...
> getconfig(
> ...
>                     case CONFIG_ADJ: {
>                             double ftemp;
> 
>                             sscanf(tokens[1], "%lf", &ftemp);
>                             proto_config(PROTO_ADJ, 0, ftemp, NULL);
>                         }
>                         break;
> 
> ndpt/ntp_proto.c:proto_config()
>         /*
>          * Set the adjtime() resolution (s).
>          */
>         case PROTO_ADJ:
>                 sys_tick = dvalue;
>                 break;
> 
> I do not see any #ifdefs and the code in sys_adjtime() in principle does the
> same as old one from 4.1.1. There is a bug in get_systime (trivial patch
> follows) but it should not change anything in this case because ntpd does
> not even _tries_ to correct time so it does not have any residual. I do have
> tick in ntp.conf:
> 
> bor@itsrm2% head /etc/ntp.conf
> # ntp 4.2.0
> # tick 10ms
> tick 10000e-6
> 
> Could you point to corr. patches (changeset number or whatever) that you
> mean?
> 
> Thank you
> 
> Patch for get_systime:
> 
> --- ntp-4.2.0/libntp/systime.c.adjtime        Thu Jul 17 14:27:23 2003
> +++ ntp-4.2.0/libntp/systime.c  Tue Mar  2 19:10:37 2004
> @@ -85,7 +85,7 @@ get_systime(
>         if (dtemp >= 1) {
>                 dtemp -= 1;
>                 now->l_i++;
> -       } else if (dtemp < -1) {
> +       } else if (dtemp < 0) {
>                 dtemp += 1;
>                 now->l_i--;
>         }
> 
> "David L. Mills" <mills@udel.edu> wrote in message
> news:4044D195.CA74DF58@udel.edu...
> > -andrey,
> >
> > I see the problem. Some time ago the scheme you suggested was
> > generalized for an value of quantum specified in sys_tick in the
> > systime.c library routine. This was done so that the kernel adjtime()
> > routine would work with both microsecond and nanosecond kernels, as well
> > as 10-ms kernels. However, the #ifdefs needed to invoke 10 ms for those
> > kernels that deserve it were not implemented. Sorry about that; the code
> > has been corrected in the development version.
> >
> > I haven't been closely following the current release process details,
> > but there is a good chance you might soon see the development stuff in a
> > snapshot.
> >
> > Dave
> >
> > Borzenkov Andrey wrote:
> > >
> > > I have been running ntp 4.1.1 under Reliant UNIX successfully for a long
> > > time. It stabilized pretty fast with drift around 50.
> > >
> > > Recently I tried 4.2.0 just to discover that it does not work for me. It
> > > claims my clock is too buggy and I know it is not :)
> > >
> > > bor@itsrm2% ntpdc -c loop
> > > offset:               -0.365980 s
> > > frequency:            -500.000 ppm
> > > poll adjust:          -30
> > > watchdog timer:       246 s
> > >
> > > First suspect was adjtime resolution. Reliant has 10ms adjtime
> resolution
> > > and 4.1.1 contains special code to account for that (it rounds
> adjustments
> > > to nearest 10ms multiple and saves the remainder as residual; on get it
> > > fakes better resolution by adding residual back). Patch was originally
> > > written by me and used the same technique as for SCO and then was
> cleaned up
> > > and unified with SCO case by Kamal A Mostafa.
> > >
> > > Then I noticed "tick" config file variable that is supposed to set
> > > resolution for sys_adjtime (not documented anywhere); but setting it to
> > > 10000e-6 (this *is* 10ms is not it?) did not actually changed anything.
> > >
> > > I am somewhat out of ideas. Of course it may be that it needs *very*
> long
> > > time now but then again, it looks as regression to me.
> > >
> > > Oh, and I cannot step time due to buggy settimeofday call so I am forced
> to
> > > use slew all the time. Still clock must be pretty much in sync as I
> started
> > > 4.2.0 immediately after killing 4.1.1
> > >
> > > Any help appreciated. Ideas how to debug it too :)
> > >
> > > -andrey
> > >
> > > PS when I write it frequency error as reported in syslog went
> from -502PPM
> > > to -501PPM. Now, it may be good sign but it took almost three hours.
> With
> > > this pace it will need half a year to climb back to 50PPM :)

The snapshot was rolled last night.  It is in the download area.

H
--
In article <4045FF39.94252B35@udel.edu>, David L. Mills <mills@udel.edu> wrote:
>Andrey,
>
>As I said, I made the changes in the current ntp-dev at the development
>site. The changes should appear in a snapshot sometime soon, but
>production of the snapshots and releases is handled by other sturdy
>hands.
>
>Dave
>
>Andrey Borzenkov wrote:
>> 
>> Dave,
>> 
>> which #ifdefs do you mean? What I see in current code is
>> 
>> libntp/systime.c:sys_adjtime()
>> 
>>         ticks = (long)(dtemp / sys_tick + .5);
>>         adjtv.tv_usec = (long)(ticks * sys_tick * 1e6);
>>         dtemp -= adjtv.tv_usec / 1e6;
>>         sys_residual = dtemp;
>> 
>> (of course it was sys_tick, not sys_adjtime, sorry). There are no #ifdefs
>> around it.
>> 
>> ntpd/ntp_config.c:
>> 
>>         { "tick",               CONFIG_ADJ },
>> 
>> ...
>> getconfig(
>> ...
>>                     case CONFIG_ADJ: {
>>                             double ftemp;
>> 
>>                             sscanf(tokens[1], "%lf", &ftemp);
>>                             proto_config(PROTO_ADJ, 0, ftemp, NULL);
>>                         }
>>                         break;
>> 
>> ndpt/ntp_proto.c:proto_config()
>>         /*
>>          * Set the adjtime() resolution (s).
>>          */
>>         case PROTO_ADJ:
>>                 sys_tick = dvalue;
>>                 break;
>> 
>> I do not see any #ifdefs and the code in sys_adjtime() in principle does the
>> same as old one from 4.1.1. There is a bug in get_systime (trivial patch
>> follows) but it should not change anything in this case because ntpd does
>> not even _tries_ to correct time so it does not have any residual. I do have
>> tick in ntp.conf:
>> 
>> bor@itsrm2% head /etc/ntp.conf
>> # ntp 4.2.0
>> # tick 10ms
>> tick 10000e-6
>> 
>> Could you point to corr. patches (changeset number or whatever) that you
>> mean?
>> 
>> Thank you
>> 
>> Patch for get_systime:
>> 
>> --- ntp-4.2.0/libntp/systime.c.adjtime        Thu Jul 17 14:27:23 2003
>> +++ ntp-4.2.0/libntp/systime.c  Tue Mar  2 19:10:37 2004
>> @@ -85,7 +85,7 @@ get_systime(
>>         if (dtemp >= 1) {
>>                 dtemp -= 1;
>>                 now->l_i++;
>> -       } else if (dtemp < -1) {
>> +       } else if (dtemp < 0) {
>>                 dtemp += 1;
>>                 now->l_i--;
>>         }
>> 
>> "David L. Mills" <mills@udel.edu> wrote in message
>> news:4044D195.CA74DF58@udel.edu...
>> > -andrey,
>> >
>> > I see the problem. Some time ago the scheme you suggested was
>> > generalized for an value of quantum specified in sys_tick in the
>> > systime.c library routine. This was done so that the kernel adjtime()
>> > routine would work with both microsecond and nanosecond kernels, as well
>> > as 10-ms kernels. However, the #ifdefs needed to invoke 10 ms for those
>> > kernels that deserve it were not implemented. Sorry about that; the code
>> > has been corrected in the development version.
>> >
>> > I haven't been closely following the current release process details,
>> > but there is a good chance you might soon see the development stuff in a
>> > snapshot.
>> >
>> > Dave
>> >
>> > Borzenkov Andrey wrote:
>> > >
>> > > I have been running ntp 4.1.1 under Reliant UNIX successfully for a long
>> > > time. It stabilized pretty fast with drift around 50.
>> > >
>> > > Recently I tried 4.2.0 just to discover that it does not work for me. It
>> > > claims my clock is too buggy and I know it is not :)
>> > >
>> > > bor@itsrm2% ntpdc -c loop
>> > > offset:               -0.365980 s
>> > > frequency:            -500.000 ppm
>> > > poll adjust:          -30
>> > > watchdog timer:       246 s
>> > >
>> > > First suspect was adjtime resolution. Reliant has 10ms adjtime
>> resolution
>> > > and 4.1.1 contains special code to account for that (it rounds
>> adjustments
>> > > to nearest 10ms multiple and saves the remainder as residual; on get it
>> > > fakes better resolution by adding residual back). Patch was originally
>> > > written by me and used the same technique as for SCO and then was
>> cleaned up
>> > > and unified with SCO case by Kamal A Mostafa.
>> > >
>> > > Then I noticed "tick" config file variable that is supposed to set
>> > > resolution for sys_adjtime (not documented anywhere); but setting it to
>> > > 10000e-6 (this *is* 10ms is not it?) did not actually changed anything.
>> > >
>> > > I am somewhat out of ideas. Of course it may be that it needs *very*
>> long
>> > > time now but then again, it looks as regression to me.
>> > >
>> > > Oh, and I cannot step time due to buggy settimeofday call so I am forced
>> to
>> > > use slew all the time. Still clock must be pretty much in sync as I
>> started
>> > > 4.2.0 immediately after killing 4.1.1
>> > >
>> > > Any help appreciated. Ideas how to debug it too :)
>> > >
>> > > -andrey
>> > >
>> > > PS when I write it frequency error as reported in syslog went
>> from -502PPM
>> > > to -501PPM. Now, it may be good sign but it took almost three hours.
>> With
>> > > this pace it will need half a year to climb back to 50PPM :)