[c-nsp] no scheduler max-sched-time

Rodney Dunn rodunn at cisco.com
Tue Nov 30 08:52:43 EST 2004


On Mon, Nov 29, 2004 at 05:34:43PM -0500, Jeff Chambers wrote:
> Thanks for this excellent info.

> 
> Should I assume that "no scheduler max-sched-time" is
> configured by default on routers running 12.2(25)S1
> and that the configuration of "service internal"
> simply causes it to show up in the running configuration?

It's default to 120 seconds on any IOS device that
has the improvement.  See below.

> 
> 
> Also, is the following interpretation correct?
> "no scheduler max-sched-time" should only affect
> the reporting of a CPU Hog via log/syslog messages
> and not actually increase the chance that a CPU
> will hang due to a CPU Hog.

Actually no.  There are two different things that
come in to play here.  a) CPUHOG messages when
a process holds the CPU for too long which just
generates a warning message and b) a watchdog fires
which triggers a watchdog crash

The watchdog timer is designed to prevent the system
from hanging when a loop happens.  It's better for
the system to reload and come back under that condition.

Now what happened was we saw a couple of examples where
the loop was in the scheduling mechanism and those would
result in a hang because the watchdog timer didn't work
there.  So we implemented a watchdog concept for the
scheduler too.  We could just have easily made the
value static and provided no CLI to it.  We chose
to make it configurable just in case we needed to
tune it to debug some future problem.  That's what
"scheduler max-sched-time" does. For things like
this the comments about not being on by default don't
apply because if they did we'd never change anything
to improve the OS.  This is an example command where
it shouldn't be touched unless told to by Cisco to
help debug a problem.

It should not NVGEN as you see it.  I have filed:

CSCeg42871
Externally found moderate defect: New (N)
max sched time does not NVGEN correctly

to get it fixed.

Rodney

 
> 
> Jeff Chambers
> 
> 
> -----Original Message-----
> From: Bruce Pinsky [mailto:bep at whack.org]
> Sent: Monday, November 29, 2004 3:47 PM
> To: Jeff Chambers
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] no scheduler max-sched-time
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jeff Chambers wrote:
> | I noticed the following command configured on a Cisco
> | 7206VXR router that was recently upgraded to 12.2(25)S1.
> |
> | "no scheduler max-sched-time"
> |
> |
> | The CLI gives me the following help information.
> |
> | Router(config)#scheduler ?
> |   max-sched-time    Maximum time scheduler can run without flagging an
> error
> |
> 
> There is no formal public documentation that I can find.  However, this
> command comes from the introduction of a new CPU HOG (scheduler watchdog)
> reporting mechanism that was introduced into 12.2S (as well as 12.0S and
> 12.2T).  Prior to this new mechanism, CPU HOG's were only reported after a
> process would suspend. This is less useful because it does not indicate
> where most of the time is being spent to cause the CPU HOG. With the
> introduction of the enhancement, a CPU HOG is reported at the moment it
> crosses the defined threshold.  The command is used to changed the default
> maximum threshold.  Setting the maximum to zero or using the explicit "no"
> version of the command disables the capability.
> 
> |
> | This command only shows up in the configuration if
> | "service internal" is configured.  I can't find any
> | documentation for the "no scheduler max-sched-time"
> | command.  Can anyone point me in the right direction?
> |
> | I'm mainly curious if this command is harmless or not.
> | After reading bug ID CSCdw61805, it appears leaving
> | "service internal" configured on a production router
> | might be a bad idea by itself.
> |
> 
> "service internal" does expose a number of commands that can have negative
> effects on system operation if used improperly.  This is usually the
> motivation for obscuring them with this mode of the parser.  The fact that
> most are undocumented is unfortunate because it leaves people to guess at
> both what the command does and how detrimental it may or may not be.  There
> is a push inside of cisco to eliminate and prevent undocumented commands
> going forward, but I can't say when or if the old ones might get done.
> 
> - --
> =========
> bep
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (MingW32)
> 
> iD8DBQFBq4rNE1XcgMgrtyYRAouWAJwIuMOu38HtjtBdb9FCfVyOdwgn6wCgry05
> TiqF+fCUzCINGaAqbflDr4I=
> =+Hwq
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


More information about the cisco-nsp mailing list