Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Aside: notes on playing with "erl +T {n}" values to adjust the Erlang…
… scheduler Experimentation using: eqc:quickcheck(eqc:numtests(200, slf_msgsim_qc:prop_mc_simulate(distrib_counter_bad1_sim, []))). Using `erl +T 0`, the output of the per-client-process counters usually looks something like a zig-zag, starting with the 1st client process first line. And it's like this very consistently. For example: [[{counter,0},{counter,2}], [{counter,1},{counter,4},{counter,6}], [{counter,3},{counter,5}], [], [{counter,7},{counter,8},{counter,9}]] Using `erl +T 5`, the same zig-zag pattern usually appears, but occasionally something different happens, like this almost-top-to-bottom-left-to-right pattern: [[{counter,0}], [{counter,1},{counter,4},{counter,7}], [], [{counter,2},{counter,6},{counter,8}], [{counter,3},{counter,5},{counter,9}]] Using `erl +T 6`, things appear to get *much* slower. (The "man" page wasn't lying when it said that higher `+T` values can hurt performance.) Now, we almost always see each process being as greedy as possible, running seemingly to completion before allowing another client to run, for example: [[{counter,0},{counter,1}], [{counter,2},{counter,3},{counter,4}], [{counter,5}], [{counter,6},{counter,7},{counter,8},{counter,9}]] At `+T 8` and `+T 9`, things are noticibly slower than the slow `+T 6` or `+T 7`. But the same greedy-like client behavior as described above for `+T 6` is the same.
- Loading branch information