* Lukas Straub (lukasstra...@web.de) wrote: > On Sat, 11 Apr 2020 19:16:54 +0200 > Lukas Straub <lukasstra...@web.de> wrote: > > > Hello Everyone, > > I did some Benchmarking with iperf3 and memtester (to dirty some guest > > memory) > > of colo performance in qemu 4.2.0 and in qemu 5.0.0-rc2 > > with my bugfixes on top.( > > https://lists.nongnu.org/archive/html/qemu-devel/2020-04/msg01432.html ) > > > > I have taken the average over 4 runs. > > Client-to-server tcp bandwidth rose slightly from ~83.98 Mbit/s to ~89.40 > > Mbits. > > Server-to-client tcp bandwidth fell from ~9.73 Mbit/s to ~1.79 Mbit/s. > > Client-to-server udp bandwidth stayed the same at 1.05 Mbit/s > > and jitter rose from ~5.12 ms to ~10.77 ms. > > Server-to-client udp bandwidth fell from ~380.5 Kbit/s to ~33.6 Kbit/s > > and jitter rose from ~41.74 ms to ~83976.15 ms (!). > > > > I haven't looked closely into it, but i think > > 0393031a16735835a441b6d6e0495a1bd14adb90 "COLO: Optimize memory back-up > > process" > > is the culprint as it reduces vm downtime for the checkpoints but increases > > the overall checkpoint time and we can only release miscompared primary > > packets > > after the checkpoint is completely finished. > > > > Another thing that I noticed: With 4.2.0, the secondary qemu uses thrice > > the amount of gest memory. With 5.0.0-rc2 it's just double the amount of > > guest memory. So maybe the ram cache isn't working properly? > > > > Regards, > > Lukas Straub > > Hmm, > I looked at my test again and saw that the results where very noisy, so qemu > 5.0.0-rc2 > being slower was just a coincidence. I did increase the test time and the > results are > more meaningful now. Now qemu 5.0.0-rc2 is around the same speed and still > faster > in the client-to-server tcp case. > > Sorry for the noise.
Is it back to using 3x RAM in the secondary? Dave > > Regards, > Lukas Straub -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK