Date: Thu, 28 Jan 1999 14:03:23 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Duncan Barclay <dmlb@ragnet.demon.co.uk> Cc: dyson@iquest.net, hackers@FreeBSD.ORG Subject: Re: High Load cron patches - comments? Message-ID: <199901282203.OAA11295@apollo.backplane.com> References: <XFMail.990128212616.dmlb@computer.my.domain>
next in thread | previous in thread | raw e-mail | index | archive | help
:>:changing time constants.
:>:
:>:Duncan
:>
:> Think of it as the current-sense (aka limiting) resistor in a switching
:> power supply.
:>
:> -Matt
:
:One but the resistor is a linear element in the power supply (V=IR), if there
:is a trip sensing the V however things can go loopy. A couple of years back the
:West coast power grid under went a chatoic episode which took out most of it.
:Have a look at Chua's diode, a simple non-linear resistor:
: I = Vin / R1 for -x <= V <= x
: = Vin / R2 for V > +- x
:when put in a resonant circuit (i.e. a second order feedback loop with the
:poles too close together) chaotic oscillations can occur.
Now this is getting interesting. I was thinking of the current limiting
resistor going between pins 7 and 8 of the trusty LM3578A ( with pin 7
tied to pin 6 ). Basically, the oscillator is running at an order of
magnitude higher frequency then any possible feedback because there is
a huge capacitor sitting on the output stage of the regulator. So the
worst you'll see from hitting the current limit is a little jitter
( < 0.1% ) on the output, assuming no further regulation.
The case that matters here is, of course, the case where one actually
runs into the limit. The power curve basically goes up linearly until
it hits the limit, then flattens out --- but doesn't go down much ( P=IV,
so when it hits the current limit V will start to go down as I goes up
in the power output stage. The current limit is associated with the
power input to the regulator, of course, and since the voltage input is
steady the current limit is effectively a power limit ).
The jitter due to the limiting function of actually shutting down the
oscillator and bringing it back up is too small to worry about.
The rate limiting in this paradigm is dealing with the situation where,
say, you have 8 hard drives that eat 1.5A each on spinup and rather then
turn them on all at once you stagger-start them. However, *I* prefer
turning them on all at once, which maxes the power supply at its max
power output for a short period of time. In the stagger-start case,
the power supply is NOT maxed out. i.e. you aren't utilizing 100% of
your resources.
Assuming a direct transfer of power to momemtum, my way will get all
the drives spun up more quickly while the staggered start case will
get a few drives spun up every MORE quickly, but the rest of the drives
quite a bit LESS quickly.
This is why I prefer allowing bursts, like allowing a lot of sendmails
to fork at once rather then rate limit them. I don't mind hitting
the current-limit ( max power output of the power supply ). My hard
limit would be the 'number of drives' in the system.
Now, the more quickly verses less quickly case is classic scheduling
theory. You have N people each with job J(n). Each job takes T(n)
time ( different for each job). How do you schedule the jobs such
that you get the fewest complaints? This certainly applies to what
John is talking about.
-Matt
Matthew Dillon
<dillon@backplane.com>
:It appeared to me that John, was tlaking about controlling the fork
:rate in a loop and you wanted to limit the number of processes (I may have got
:this wrong). This system would have two feedback loops, contain two poles
:(the integral of the fork rate and the filter constant) and a non-linearity. Any
:feedback system is potentially unstable, those with two poles are very easy to
:get hooting and non-linearities will break the control.
:
:I'm more of an analogue/continious time man and the fork rate
:is sampled/discrete time.
:
:Duncan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901282203.OAA11295>