VegasLimit without slow start is unusable

[nvartolomei]

Thank you for bringing this thing to the public.

VegasLimit is almost unusable as of current implementation for any high concurrent workloads (cpu bound with high core count or IO bound) due to very slow ramp up.

I see it removed in #16 because of being too aggressive and overshooting, my experiments with smoothing and exponential growth show good results. Also another thing to note that was not implemented is that Vegas seems to have another parameter, gamma (default 1). When queuing is higher than gamma it stops slow-start (sets new ssthreshold) and enters congestion avoidance. Some papers say to decrease limit by 1/8, linux does something interesting too https://github.com/torvalds/linux/blob/master/net/ipv4/tcp_vegas.c#L219

ymmv

no PRs since I'm experimenting with this idea using Go at the moment

[jonomacd]

I'm also looking at a Go implementation and am a bit worried about the slow start problem.

I've noticed the smoothing function here:
https://github.com/Netflix/concurrency-limits/blob/master/concurrency-limits-core/src/main/java/com/netflix/concurrency/limits/limit/VegasLimit.java#L174

Seems to wash out all changes. The limit is only ever incr or decr by 1 so the int truncation on this smoothing seems to keep it at the same value all the time. trunc(0.8n + 0.2(n+1)) = n. I must be missing something here.

[elandau]

@jonomacd There's is a type casting bug in VegasLimit that's messing with updates to the limit for anything other than smoothing=1.0. I've got a fix for it here #36.

Agreed on not slow start being an issue. I can add that quickly once the Vegas smoothing fix is merged.