vividcortex / ebooks Goto Github PK

Vlad suggested that I remove the R code and the Cisco sample data, and put it into a Gist or similar for the curious.

The bit.ly links in the footnote on page 14 have spurious slashes after "kernel" that break them.

The context around these is also confusing -- it's unclear that they are meant to be about rising costs of queues. As I wrote to someone:

Thanks. I'll clarify the wording around that; they are not supposed to be about Little's Law, but about the service time inflation's cause. Those blog posts illustrate what's more likely the cause in a lot of single-server systems: longer queues increase costs, e.g. lots of threads queued on a mutex causes the cost of waking up the threads to increase in InnoDB's non-native mutex implementation.

This book uses the terms blacklist/whitelist which are better expressed as blocklist/safelist

I had a conversation with Stefan Möding, the author of the USL R package about the shortcomings I mentioned:

Me:

My memory is a little vague on the details now, but as I recall, a few things happened when I was working with it, which made me prefer to work without an abstraction:

1. A lot of the data I work with has things like negative coefficients after regression, and that caused an error if I remember correctly.
2. The "lambda" parameter is not present -- it assumes everything is normalized relative to C(1) perhaps?
3. It requires a measurement at N=1 perhaps? Much of the data I work with doesn't have that.

For the cases where it worked I thought it was very nice, but I am not much of an R programmer so I couldn't immediately see how to work around the spots where I had trouble. In addition I thought it more valuable to demonstrate to readers how to work with the equations directly, rather than using an abstraction.

Stefan Möding:

I see your points. For your second & third point: yes, that is correct for the default setting. The implementation follows the algorithm presented by Dr. Gunther in his book and therefore expects the data for N=1 / C(1) to be available.

But there are two alternative implementations available by setting the „method“ parameter of the „usl“ function to either the value „nls“ or „nlxb“. Both methods use nonlinear regression without the need for N=1 / C(1) to be available in the data. They estimate your lambda - I named it scale factor - in addition to sigma and kappa.

Unfortunately the „nls“ method often fails to provide an answer since the internal algorithm does not converge. But the „nlxb“ method - an alternative implementation imported from a different package - is pretty good. It also considers parameter bounds, so sigma and kappa will not be negative with this algorithm.

Rather than describing how a queue works, I had the idea to describe its results.

A queue is a mechanism that can improve throughput, but only at the expense of latency.

That seems complete to me.