ADSM-L

Re: Scheduled event takes 2-3 minutes to start. Why?

2000-04-05 10:32:33
Subject: Re: Scheduled event takes 2-3 minutes to start. Why?
From: Lindsay Morris <lmorris AT OPENMIC DOT COM>
Date: Wed, 5 Apr 2000 10:32:33 -0400
Thanks, Mark.  But no, I have randomization set to 0.  Just for kicks, I
set it to 1% - it still takes a few minutes to start.

I enabled "sched" tracing and poked around - apparently the scheduler
thread checks for new stuff every 30 seconds, which explains a LITTLE
bit of the delay.

After some experimenting, I find that after the server has contacted the
client scheduler the first time, then events start up within 30
seconds.  The slowness occurs when the client scheduler first wakes up.
Even though it instantly (upon starting) runs the scheduled event which
was waiting for it, the NEXT event has a 2-3 minute delay - but then the
NEXT event is fast.

So I guess it has to do with how the server gets in touch with the
client.  I'm using a non-standard TCPPORT number: 30001, and
TCPCLIENTPORT is 30002.  Why would that make it slow at first?


>  It sounds like the   "Execution interval for randomization of start
>  times" is set to
>  something other than 0(zero).
>
>  By default ADSM sets it to 25%. This means all clients will start
>  randomly in the
>  first 1/4 of the startup window. If you set it to 0 then all nodes will
>  start at the
>  right time.
>
>  Lindsay Morris wrote:
> >
> > There's this annoying behavior ....
> >
> > When you change the start time of a schedule in TSM to NOW,
> > it doesn't kick off then.  It kicks off maybe 3 minutes later.
> >
> > I tried a couple of things - none of these had any effect:
> >
> >     define clientaction (ie, create a schedule name @1, startt=now)
> >
> >     upd sched .... duration=1 durunits=minutes (in this case, the
> >     schedule NEVER kicks off - but after a minute "query events" says
> >     "MISSED")
> >
> >     upd sched .... perunits=onetime duration=indefinite
> >
> > One thing that DOES work is bouncing the scheduler.  i guess
> > that's because the scheduler, waking up, contacts the server.
> > But that's a pretty graceless solution.
> >
> > I checked to see if the clocks are set the same - they are.
> > In fact the client is on the same machine as the server, so the
> > clocks are identical.
> >
> > So, has anybody figured out a way to make the scheduler
> > more responsive?
> >
> > Vital stats: AIX 4.3, TSM server 3.7.2.0, TSM client 3.7.0.0,
> > schedmode prompted, commmethod tcpip.
> >
> > Thanks!
> > --
> > Mr. Lindsay Morris
> > Gresham Enterprise Storage
> > lmorris AT openmic DOT com
> > 606-253-8000
>
> --
> Thank You,>
>
> Mark Brown
>
> =======================================
> Operations Supervisor
> McGill University
> Computing Centre Operations>
>
> E-Mail :    mbrown AT po-box.mcgill DOT ca
> Phone  :    514-398-2321
> WWW    :    http://mbrown.cc.mcgill.ca
> =======================================
--
Mr. Lindsay Morris
Mr. Lindsay Morris
Gresham Enterprise Storage
lmorris AT openmic DOT com
606-253-8000
<Prev in Thread] Current Thread [Next in Thread>