NTP, and gccadmin's crontab about to be activated

NTP, and gccadmin's crontab about to be activated

[Phil Edwards]

After a bit more poking and prodding, I'm going to reinstall the contrab
unchanged -- which means that the version bump will now happen "a few
minutes after midnight" GMT, instead of "a few minutes after midnight" PST.

That should arguably make more sense.  I think.  Maybe.  It's gonna feel
weird when the output date bumps at 7pm my time, though.  :-)

Looking around, it doesn't appear that the new system has any NTP settings
keeping the clock on track.  Did the old system?  Does the new system have
something else that I'm just not thinking of?

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: NTP, and gccadmin's crontab about to be activated

[Christopher Faylor]

On Mon, Jan 20, 2003 at 01:26:47AM -0500, Phil Edwards wrote:
>Looking around, it doesn't appear that the new system has any NTP settings
>keeping the clock on track.  Did the old system?  Does the new system have
>something else that I'm just not thinking of?

There is a ntpd running and an /etc/ntpd.conf file controlling it, just
like the old system.

cgf

Re: NTP, and gccadmin's crontab about to be activated

[Andrew Cagney]

> After a bit more poking and prodding, I'm going to reinstall the contrab
> unchanged -- which means that the version bump will now happen "a few
> minutes after midnight" GMT, instead of "a few minutes after midnight" PST.

Er, GDB's stuff is running a `few minutes after midnight', well ok 01:47.

> That should arguably make more sense.  I think.  Maybe.  It's gonna feel
> weird when the output date bumps at 7pm my time, though.  :-)

To the contrary.  It will cause GDB and GCC's jobs to fight with each 
other!   Just add 8 to all the crontab times and that way GCC ontinues 
to run at that same old time.

Andrew

Re: NTP, and gccadmin's crontab about to be activated

[Phil Edwards]

On Mon, Jan 20, 2003 at 02:01:44PM -0500, Andrew Cagney wrote:
> >After a bit more poking and prodding, I'm going to reinstall the contrab
> >unchanged -- which means that the version bump will now happen "a few
> >minutes after midnight" GMT, instead of "a few minutes after midnight" PST.
> 
> Er, GDB's stuff is running a `few minutes after midnight', well ok 01:47.
> 
> >That should arguably make more sense.  I think.  Maybe.  It's gonna feel
> >weird when the output date bumps at 7pm my time, though.  :-)
> 
> To the contrary.  It will cause GDB and GCC's jobs to fight with each 
> other!   Just add 8 to all the crontab times and that way GCC ontinues 
> to run at that same old time.

The only thing that GCC's crontab is doing is the nightly version bump.
Shouldn't affect GDB at all.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: NTP, and gccadmin's crontab about to be activated

[Joseph S. Myers]

On Mon, 20 Jan 2003, Phil Edwards wrote:

> The only thing that GCC's crontab is doing is the nightly version bump.
> Shouldn't affect GDB at all.

And update_web_docs, but that should be much faster on the new machine,
and be finished long before GDB's crontab starts.  (The weekly snapshots
run at 16:40, meaning they now actually happen during the UTC day they
relate to rather than after midnight UTC.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: NTP, and gccadmin's crontab about to be activated

[Andrew Cagney]

> On Mon, 20 Jan 2003, Phil Edwards wrote:
> 
> 
>> The only thing that GCC's crontab is doing is the nightly version bump.
>> Shouldn't affect GDB at all.
> 
> 
> And update_web_docs, but that should be much faster on the new machine,
> and be finished long before GDB's crontab starts.

The current schedule was carefully arranged and for good a reason.  It 
balanced the system load.  GCC's task (the longest running and heavest) 
at the time when the system had the lightest load (the middle of the 
apec day when europe and america were in bed).

Now is not the time to review that schedule.

Rather, the schedule should be reviewed in a few weeks when the system 
has settled and we've hard data on how long each job is taking. 
Hopefully, at that time, it will be possible to do things like move 
GDB's start time out so that it isn't so close to that peak 1am (5pm US 
pacific) time slot.  The last thing people should be considering is 
trying to schedule things at 00:00 gmt and, consequently, totally 
overload that period.

Andrew

Re: NTP, and gccadmin's crontab about to be activated

[Joseph S. Myers]

On Mon, 20 Jan 2003, Andrew Cagney wrote:

> > And update_web_docs, but that should be much faster on the new machine,
> > and be finished long before GDB's crontab starts.
> 
> The current schedule was carefully arranged and for good a reason.  It 
> balanced the system load.  GCC's task (the longest running and heavest) 
> at the time when the system had the lightest load (the middle of the 
> apec day when europe and america were in bed).

The timing of update_web_docs, if carefully arranged, was arranged when
update_web_docs was a rather smaller job (only generating HTMl manuals,
not running TeX).  But the current update_web_docs still consistently ran
in under 3 minutes on the old system, and is of course quicker on the new
one.

The only one of GCC's jobs that takes a significant amount of time is the
weekly snapshot run, at 16:40 on Mondays.  That's the only one for which
scheduling the time not to clash with other jobs is important.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: NTP, and gccadmin's crontab about to be activated

[Andrew Cagney]

> On Mon, 20 Jan 2003, Andrew Cagney wrote:
> 
> 
>> > And update_web_docs, but that should be much faster on the new machine,
>> > and be finished long before GDB's crontab starts.
> 
>> 
>> The current schedule was carefully arranged and for good a reason.  It 
>> balanced the system load.  GCC's task (the longest running and heavest) 
>> at the time when the system had the lightest load (the middle of the 
>> apec day when europe and america were in bed).
> 
> 
> The timing of update_web_docs, if carefully arranged, was arranged when
> update_web_docs was a rather smaller job (only generating HTMl manuals,
> not running TeX).  But the current update_web_docs still consistently ran
> in under 3 minutes on the old system, and is of course quicker on the new
> one.

Ah!  Ok, ignore me then :-)

> The only one of GCC's jobs that takes a significant amount of time is the
> weekly snapshot run, at 16:40 on Mondays.  That's the only one for which
> scheduling the time not to clash with other jobs is important.

Andrew

Re: NTP, and gccadmin's crontab about to be activated

[Andrew Cagney]

>> To the contrary.  It will cause GDB and GCC's jobs to fight with each 
>> other!   Just add 8 to all the crontab times and that way GCC ontinues 
>> to run at that same old time.
> 
> 
> The only thing that GCC's crontab is doing is the nightly version bump.
> Shouldn't affect GDB at all.

Yes, that definitly won't affect GDB.  In fact, like GDB, you should run 
it hourly.  That way, if the machine is down for a few hours, it fixes 
itself.

Andrew