this is for holding javascript data
Bart van Merriƫnboer edited Queueing.tex
over 10 years ago
Commit id: 7a4dfec8ff57f42f6d160741263dca6c19769039
deletions | additions
diff --git a/Queueing.tex b/Queueing.tex
index cd1bbd2..7bcfe83 100644
--- a/Queueing.tex
+++ b/Queueing.tex
...
The problem is effectively 3 separate \href{http://en.wikipedia.org/wiki/M/G/k_queue}{M/G/c queues}. This makes the problem of calculating the waiting time (given the $\lambda(t)$ we calculated and the distribution $G$ from the data) analytically impossible. However, there are approximations which we could use, but we would have to figure out which ones work best, if at all, (especially considering papers like \href{http://link.springer.com/article/10.1007%2Fs11134-009-9133-x#page-1}{this one} which describe the issues with approximating M/G/c waiting times). Perhaps it's a good idea to check our approximations against simulations.
Perhaps it would also be useful if we can somehow find a (very rough) analytical or numerical approximation of the distribution of waiting times. That way we could integrate this distribution over our penalty function $C(t)$ to calculate the expected penalty we get for a particular waiting time. Maybe we could somehow estimate it by considering each VM independently as a M/G/1 queue and use a numerical Laplace-Stieltjes transform (see \href{http://en.wikipedia.org/wiki/M/G/1_queue}{the M/G/1 Wikipedia page}). Absolutely no idea whether this is possible. Else we could just use simulation again, and fit a function.
The Prezi system automatically sends jobs to the VM which is closest to the end of a billing period, but that still has enough time to run the job, so we don't have to worry about that.