Home Forums HCL Reviews Tutorials Articles Register Search Today's Posts Mark Forums Read
 LinuxQuestions.org plotting difference equations which are dependent on linear equations
 Programming This forum is for all programming questions. The question does not have to be directly related to Linux and any language is fair game.

Notices

 11-17-2008, 03:01 PM #2 weibullguy ReliaFree Maintainer   Registered: Aug 2004 Location: Kalamazoo, Michigan Distribution: Slackware-current, Cross Linux from Scratch, Gentoo Posts: 2,812 Blog Entries: 1 Rep: What is the model you have developed thus far? Since three of your explanatory variables (time to queue, time to retrieve, and time to remove) can be considered constants for a given server, you have only the one variable left (rate of requests). At this point, you can view your server requests as a nonhomogenous Poisson process (assuming the rate of request varies with time). If you have existing data about the number of requests per unit of time, you can use that to fit a model for the rate of request. Always look for the simplest model that reasonably describes your data. You may find that a piecewise model works depending on the source of the requests. And, take a look at the GSL for functions to calculate integrals.
 11-17-2008, 07:31 PM #3 ta0kira Senior Member   Registered: Sep 2004 Distribution: FreeBSD 9.1, Kubuntu 12.10 Posts: 3,078 Original Poster Rep: Yes, the outcome will only vary based on the rate of requests, which can be described by a nonhomogenous Poisson process. The state of the queue must be discretely calculated, however. Here is my best generalization of the load (i.e. number of queued requests) inherent to the server's design: Code: ```Ln(Δt) = Ln-1 + A(tn) - T(Sn-1) tn A(tn) = ∫ λr(t) dt tn-1 T(Sn) = Ln·δη(Sn, Δt(T)) t ≡ time Ln ≡ queued requests A ≡ added requests λr ≡ request enqueue rate T ≡ removed requests δη ≡ load compensation calculation Sn ≡ instantaneous dynamic queue state (L ⊂ S, S(t[n,n+1)) = Sn)``` The problem I see is that λr can't be expected to symbolically integrate, meaning it will probably involve a rough Σ operation each iteration. Something I'm particularly interested in is if oscillations in Ln will eventually attenuate with a constant λr. Thanks. ta0kira PS λr(t) will be an arbitrary simulation which could possibly consist of a system of equations. Last edited by ta0kira; 11-17-2008 at 08:27 PM.
 11-18-2008, 12:24 PM #4 weibullguy ReliaFree Maintainer   Registered: Aug 2004 Location: Kalamazoo, Michigan Distribution: Slackware-current, Cross Linux from Scratch, Gentoo Posts: 2,812 Blog Entries: 1 Rep: Well, you can't conclude that lambda won't symbolically integrate unless you know the function that lambda represents. Commonly the lambda in NHPP follow a power law model or a loglinear model (at least in the application I use NHPP models). Both are symbolically integrable. Oscillations in Ln will attenuate with a constant lambda as long as T is a constant and T = A. But the problem you've presented prohibits a constant lambda. Ln should attenuate (within a range of values) even with a varying lambda. If it doesn't your system is unoptimized and out of control. My understanding of your problem is to stabilize Ln with a varying lambda. Thus, if Ln is oscillating, you haven't solved your problem. The key is to shoot for an acceptable RANGE of Ln values and only vary T as needed to maintain Ln within that range. Attempting to maintain Ln at a single, constant value will never be stable. Your T will constantly be changing. If lambda is a system of equations, the solution will be a system of solutions. Just use matrices to do the math.
 11-18-2008, 08:43 PM #5 ta0kira Senior Member   Registered: Sep 2004 Distribution: FreeBSD 9.1, Kubuntu 12.10 Posts: 3,078 Original Poster Rep: Yes, I suppose you're right about the λ integration, except if some sort of randomness is included. The overall goal is to prevent queue overflow with the smallest possible Δt despite seemingly-chaotic input. For example, I've been testing the system with a set of 8 client programs each sending off 512 requests in a row with random 10ms intervals thrown in, then a random pause and another 512 requests each. The objective is for the number of requests pulled at once to be relatively uniform, yet conforming to the essential pattern of input. To do this it needs to both recognize the signs of a spike, yet not overreact to a change that might be very short-lived to prevent massive oscillations. ta0kira
 11-21-2008, 06:58 PM #6 weibullguy ReliaFree Maintainer   Registered: Aug 2004 Location: Kalamazoo, Michigan Distribution: Slackware-current, Cross Linux from Scratch, Gentoo Posts: 2,812 Blog Entries: 1 Rep: I'm visualizing from your description a pulse train of requests. Each pulse varies in width because you're breaking up the 512 requests with pseudo-randomly occurring 10ms intervals (and always 10ms). That should be easily integrable as each pulse is a rectangle. In order to "recognize" a spike and not freak out, you could use a moving average which tends to smooth the input. Another approach would be to add negative feedback to the system. Not sure how you would include negative feedback in your system. It would be interesting though.
 11-22-2008, 10:08 PM #7 ta0kira Senior Member   Registered: Sep 2004 Distribution: FreeBSD 9.1, Kubuntu 12.10 Posts: 3,078 Original Poster Rep: Right now the calculation is split into 2 parts. The first is the exponent of a negative ratio where absolute change in queue load, queue capacity, and average execution time increase it and remaining queue capacity, change in time, and last number of executed requests decrease it. After subtracting from 1 and assuming the sign of the change in queue load. this becomes the "differential state" of the queue. The second part is the calculation of the bulk execution percentage. The old percentage is combined with a new one calculated with the value found above, weighted based on elapsed time. The combination of elapsed time increasing the first value and that same elapsed time decreasing the weight when combing the new percentage with the old prevents sharp, but extremely short changes from having as much impact as a sharp, but somewhat short change, while changes over a period of several seconds gets little consideration. I would post the equations but I'm not patient enough to put them into LQ format. I might put them into maxima for that. ta0kira PS Something I have noticed is that the rate of request enqueueing and the rate of request execution will almost always add up to 2k/second; therefore, I need to do some scheduling manipulation, also. Last edited by ta0kira; 11-23-2008 at 03:20 AM.

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is Off HTML code is Off Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post ArthurHuang Programming 14 06-19-2006 02:00 AM bitt_u Linux - Software 1 07-25-2005 02:20 AM akudewan Linux - Software 6 06-08-2004 11:37 AM scyr Linux - Newbie 1 01-02-2004 10:00 AM

All times are GMT -5. The time now is 12:11 AM.

 Contact Us - Advertising Info - Rules - LQ Merchandise - Donations - Contributing Member - LQ Sitemap -