C(N) = 
N


I have yet to see an equation expressing response time as a function of throughput. I believe this is fundamentally wrong  it is not actually a function. The reverse is true instead: throughput can be expressed as a function of latency.
Here's some real data from a system, charted as usual for the USL, with throughput as a function of concurrency/load (threads, in this case)Notice that this system has gone past the inflection point of Nmax and is in retrograde scalability. Now using Little's Law, plot latency as a function of throughput.
Oops. That ain't a function.
If you disagree, please show me the equation you arrive at if you use Little's Law to solve the USL for response time as a function of throughput.Of course this is just as easy to demonstrate with the USL itself instead of benchmark data, but there's been a bunch of discussion about how "think time" changes things somehow. I don't agree with that. Little's Law is Little's Law. I can measure this stuff directly in the field, and my empirical observations agree exactly with the results I compute from Little's Law.Here is what I believe is the correct relationship: throughput as a function of latency.I haven't taken the time to rearrange the USL to find the equation for this but I intend to at some point... algebra is my weak point.
Oops. That ain't a function.Whaddya mean, it's not a function?
Oops. That ain't a function.Whaddya mean, it's not a function?It's a function,
but not of the value represented on the horizontal axis. A single tputvalue can produce multiple latencyvalues.
The horizontal axis is showing the dependent variable in this plot.
The horizontal axis is showing the dependent variable in this plot.As you've plotted it, the throughput is the independent variable.
You're making my point for me. We're in agreement. X is a function of N, not the inverse

You received this message because you are subscribed to the Google Groups "Guerrilla Capacity Planning" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guerrillacapacity...@googlegroups.com.
To post to this group, send email to guerrillacap...@googlegroups.com.
Visit this group at http://groups.google.com/group/guerrillacapacityplanning.
For more options, visit https://groups.google.com/d/optout.
Not being pedantic, and just speaking in generalities: the throughput is identical and the concurrency is higher, so the latency (residence time) must be higher. The service time can be assumed to remain constant. Therefore the queue length and the queue wait time is higher at N=32 than at N=25.
It seems like this is a case of offered load (N) vs. active load (XR).Above 25 any extra load is queued hence not contributing to increased throughput and this queueing causes increased response time, when measured from the system offering the load.
To unsubscribe from this group and stop receiving emails from it, send an email to guerrillacapacityplanning+unsub...@googlegroups.com.
To post to this group, send email to guerrillacapacityplanning@googlegroups.com.
Alex. Hopefully, my more remarks above will also provide you with an explanation.
On Wednesday, October 28, 2015 at 8:23:08 PM UTC7, ceeaspb wrote:
It seems like this is a case of offered load (N) vs. active load (XR).Above 25 any extra load is queued hence not contributing to increased throughput and this queueing causes increased response time, when measured from the system offering the load.
To unsubscribe from this group and stop receiving emails from it, send an email to guerrillacapacity...@googlegroups.com.
To post to this group, send email to guerrillacap...@googlegroups.com.
Visit this group at http://groups.google.com/group/guerrillacapacityplanning.
For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups "Guerrilla Capacity Planning" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guerrillacapacity...@googlegroups.com.
To post to this group, send email to guerrillacap...@googlegroups.com.

Interesting thanks.
Looks Similar to the section in Perl PDQ "Adding overdriven throughput in PDQ".
On Thursday, October 29, 2015, 'DrQ' via Guerrilla Capacity Planning <guerrillacapacityplanning@googlegroups.com> wrote:
Alex. Hopefully, my more remarks above will also provide you with an explanation.
On Wednesday, October 28, 2015 at 8:23:08 PM UTC7, ceeaspb wrote:
It seems like this is a case of offered load (N) vs. active load (XR).Above 25 any extra load is queued hence not contributing to increased throughput and this queueing causes increased response time, when measured from the system offering the load.
To unsubscribe from this group and stop receiving emails from it, send an email to guerrillacapacityplanning+unsub...@googlegroups.com.
To post to this group, send email to guerrillacapacityplanning@googlegroups.com.
Visit this group at http://groups.google.com/group/guerrillacapacityplanning.
For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups "Guerrilla Capacity Planning" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guerrillacapacityplanning+unsub...@googlegroups.com.
To post to this group, send email to guerrillacapacityplanning@googlegroups.com.
Here's an XR plot of response time "as a function of" throughput using that table of data.Please refer to my previous comments. It's not a hockey stick. It's not even "lifted away from the hockey stick." It is lifted away, then folded back on itself (i.e. clearly not a function of the variable on the horizontal axis). I am in full agreement with many of your remarks.Excellent. I think we're almost there. All these plots look correct now. The 'hockeystick' metaphor applies only to the R v N plot, since only it has the diagonal asymptote. The 'nose' metaphor only applies to the R v X plot. That's exactly what you have.

You received this message because you are subscribed to the Google Groups "Guerrilla Capacity Planning" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guerrillacapacity...@googlegroups.com.
To post to this group, send email to guerrillacap...@googlegroups.com.

You received this message because you are subscribed to the Google Groups "Guerrilla Capacity Planning" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guerrillacapacity...@googlegroups.com.
To post to this group, send email to guerrillacap...@googlegroups.com.
Visit this group at http://groups.google.com/group/guerrillacapacityplanning.
For more options, visit https://groups.google.com/d/optout.
 David CollierBrown,  Always do right. This will gratify System Programmer and Author  some people and astonish the rest dav...@spamcop.net   Mark Twain
When Neil pointed out to me that the coherency penalty is due to service times increasing, it changed my world. It was there in front of me all these years.
Nobody's arguing against Little's Law and the USL doesn't negate it; it is still valid. But it's not enough to explain everything that happens in systems under stress because it doesn't model service time inflation.
I have used the USL to analyze, what, probably hundreds of systems by now? It works.
The papers you referenced also point out this phenomenon. You could analyze the measurements they present to convince yourself.I do not recall anyone in this thread saying that there's no relationship between R and X. (Correlation is not the best term to use, though.) My own claim is that response time is not a _function of_ throughput.
There are three very clear relationships that can be represented as a single function, in the mathematical sense, in the USL:X = f(N)R = f(N)X = f(R)
The relationship R = f(X) is a combination of two functions because there are two solutions over the domain that is physically valid (i.e. X strictly positive).
1. An engineer benchmarks a database server's throughput under increasing amounts of load by varying the number of worker threads issuing queries, with think time set to zero. The engineer uses regression to estimate the USL parameters and finds that X(1) = 996, sigma = 0.0267, and kappa = 0.000769. The engineer wants to compute the database's query response time at various levels of throughput. What is the response time at X = 12,000?
Hi,
In the "Bandwidth and Latency are Related Like Overclocked Chocolates" post, the throughput and response time relation is expressed by the following equation:
R(N)=NX(N)
According to USL:
X(N) = X(1) * C(N)So, is it correct to define response time as:
C(N) = N 1 + α (N − 1) + β N (N − 1)
R(N) = N / X(1) * C(N)
I tried to plot it in gnuplot and the response time follows a curve that's similar to the one from the original article.
Is this a correct assumption or did you use a different equation for the hockey stick response time graph?
Vlad