Hi, Everyone:

You've helped me a bunch in the recent past.  I now have a time server runn=
ing on a PI3 that is stable and using a pool to get its time.  No more hass=
ling the stratum 1 time servers for the time of day.  :D

I like the option to generate new stats every time I restart the server, bu=
t there will obviously be loooong periods in between restarts, so is there =
a way to specify that they also be split into days?  Or is it as simple as =
renaming the file at day's end and letting it create a new file?

Thanks so much!!!

On 15/08/2016 05:13, Bill Ko wrote:
> Hi, Everyone:
>
> You've helped me a bunch in the recent past.  I now have a time server running on a PI3 that is stable and using a pool to get its time.  No more hassling the stratum 1 time servers for the time of day.  :D
>
> I like the option to generate new stats every time I restart the server, but there will obviously be loooong periods in between restarts, so is there a way to specify that they also be split into days?  Or is it as simple as renaming the file at day's end and letting it create a new file?
>
> Thanks so much!!!

The default install of NTP on the Raspberry Pi automatically rotates the 
loopstats and peerstats files, so there are never more than a certain 
number, and each one covers a single 24 hour UTC period.

On restarting the server, the statistics are simply added to the current 
day.
-- 
Cheers,
David
Web: http://www.satsignal.eu

On Monday, August 15, 2016 at 7:17:37 AM UTC-4, David Taylor wrote:
> On 15/08/2016 05:13, Bill Ko wrote:
> > Hi, Everyone:
> >
> > You've helped me a bunch in the recent past.  I now have a time server =
running on a PI3 that is stable and using a pool to get its time.  No more =
hassling the stratum 1 time servers for the time of day.  :D
> >
> > I like the option to generate new stats every time I restart the server=
, but there will obviously be loooong periods in between restarts, so is th=
ere a way to specify that they also be split into days?  Or is it as simple=
 as renaming the file at day's end and letting it create a new file?
> >
> > Thanks so much!!!
>=20
> The default install of NTP on the Raspberry Pi automatically rotates the=
=20
> loopstats and peerstats files, so there are never more than a certain=20
> number, and each one covers a single 24 hour UTC period.
>=20
> On restarting the server, the statistics are simply added to the current=
=20
> day.
> --=20
> Cheers,
> David
> Web: http://www.satsignal.eu

Yes, I've noticed that it does a great job at managing the statistic files.=
  I just found it convenient to save them with the pid type because I could=
 quickly determine if/when a reboot occurred.  (Which, because NTP is so ro=
bust, the only times it ever restarts is because I caused it.)  I didn't se=
e an option to use a pid/day combo, and judging by your answer, there proba=
bly isn't a way.  I'm fine with that.

On Monday, August 15, 2016 at 7:17:37 AM UTC-4, David Taylor wrote:
> On 15/08/2016 05:13, Bill Ko wrote:
> > Hi, Everyone:
> >
> > You've helped me a bunch in the recent past.  I now have a time server =
running on a PI3 that is stable and using a pool to get its time.  No more =
hassling the stratum 1 time servers for the time of day.  :D
> >
> > I like the option to generate new stats every time I restart the server=
, but there will obviously be loooong periods in between restarts, so is th=
ere a way to specify that they also be split into days?  Or is it as simple=
 as renaming the file at day's end and letting it create a new file?
> >
> > Thanks so much!!!
>=20
> The default install of NTP on the Raspberry Pi automatically rotates the=
=20
> loopstats and peerstats files, so there are never more than a certain=20
> number, and each one covers a single 24 hour UTC period.
>=20
> On restarting the server, the statistics are simply added to the current=
=20
> day.
> --=20
> Cheers,
> David
> Web: http://www.satsignal.eu

Oh, let me tell you what I am planning on doing, just so you know WHY I wan=
ted this feature.

I am currently developing, for my own educational purposes, an application =
that will use the PI3 GPIO to drive some LEDs, depending on the NTP server =
status.  I figured the least intrusive method would be to monitor the stati=
stics files - the protostats file - in particular.  If I used the pid type,=
 it would be simple to monitor changes in the file, rather than keeping the=
 server occupied with periodic NTPQ queries.

I'm surprised I didn't post this before, given that, whenever I do forum su=
pport with an unusual request, my first question is always, "why", so maybe=
 I can help them do it in a simpler fashion.

On 15/08/2016 15:58, Bill Ko wrote:
[]
> Oh, let me tell you what I am planning on doing, just so you know WHY I wanted this feature.
>
> I am currently developing, for my own educational purposes, an application that will use the PI3 GPIO to drive some LEDs, depending on the NTP server status.  I figured the least intrusive method would be to monitor the statistics files - the protostats file - in particular.  If I used the pid type, it would be simple to monitor changes in the file, rather than keeping the server occupied with periodic NTPQ queries.
>
> I'm surprised I didn't post this before, given that, whenever I do forum support with an unusual request, my first question is always, "why", so maybe I can help them do it in a simpler fashion.

An "ntpq -crv" once a second isn't going to load the server 
significantly, so just parse the output from that command.  Can be 
cross-platform and even cross-device that way.  Remote monitoring if you 
need it.

-- 
Cheers,
David
Web: http://www.satsignal.eu

On Monday, August 15, 2016 at 12:41:36 PM UTC-4, David Taylor wrote:
> On 15/08/2016 15:58, Bill Ko wrote:
> []
> > Oh, let me tell you what I am planning on doing, just so you know WHY I=
 wanted this feature.
> >
> > I am currently developing, for my own educational purposes, an applicat=
ion that will use the PI3 GPIO to drive some LEDs, depending on the NTP ser=
ver status.  I figured the least intrusive method would be to monitor the s=
tatistics files - the protostats file - in particular.  If I used the pid t=
ype, it would be simple to monitor changes in the file, rather than keeping=
 the server occupied with periodic NTPQ queries.
> >
> > I'm surprised I didn't post this before, given that, whenever I do foru=
m support with an unusual request, my first question is always, "why", so m=
aybe I can help them do it in a simpler fashion.
>=20
> An "ntpq -crv" once a second isn't going to load the server=20
> significantly, so just parse the output from that command.  Can be=20
> cross-platform and even cross-device that way.  Remote monitoring if you=
=20
> need it.
>=20
> --=20
> Cheers,
> David
> Web: http://www.satsignal.eu

I've already created a library to parse the results of the various ntpq com=
mands, so I should be in good shape.

Thanks - I'm glad I posted this!