re: Throughput and Latency Considerations: Errata

ricom — Tue, 25 Jul 2006 07:50:40 GMT

The fact that the optimal number of threads to run is changing is further complicating things but I'm basically disregarding that for now. I mentioned one of the interactions -- that there might not be enough items in the queue -- but of course another is scheduling overhead which I'm disregarding entirely. Not to mention the presence of critical sections in the code which might prevent us from scaling linearly.

The only real point here is that small computational benefits can actually end up being bigger than they appear at first because of the side-benefits they bring.

I'll post again after I've had someone double check the corrected model for accuracy such as it is.

re: Throughput and Latency Considerations: Errata

ricom — Tue, 25 Jul 2006 21:51:39 GMT

OK I've had a couple people look at this and I'm pretty sure it's right now. Plus or minus the simplification I made in modelling the multi-threading that's going on. Really you could get rid of that and it wouldn't affect the concept I'm trying to illustrate. Just disregard the delay to the back end in my example and it's a straight queue (an M/M/1 queue).

If it's wrong now at least I can say other smart people also got it wrong :)