From owner-freebsd-hackers Thu Jan 28 14:03:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA23846 for freebsd-hackers-outgoing; Thu, 28 Jan 1999 14:03:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA23841 for ; Thu, 28 Jan 1999 14:03:30 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id OAA11295; Thu, 28 Jan 1999 14:03:23 -0800 (PST) (envelope-from dillon) Date: Thu, 28 Jan 1999 14:03:23 -0800 (PST) From: Matthew Dillon Message-Id: <199901282203.OAA11295@apollo.backplane.com> To: Duncan Barclay Cc: dyson@iquest.net, hackers@FreeBSD.ORG Subject: Re: High Load cron patches - comments? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :>: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 :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