<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Perhaps the mail didn't arrive properly, but the fq performance is okay now. I don't know why it was completely out for a couple of tests. It was most likely my mistake or some very bad timing for testing.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I see that on my physical hosts tsc is also the default with hpet in the list of available clocksources, just as in the VM (where kvm-clock is a paravirtualized version of the host tsc) so the same behaviour is probably to be expected in the VM as on the physical hosts. As far as I know I have not seen that it is a requirement to actually run:</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default"><font face="verdana, sans-serif">echo hpet > /sys/devices/system/clocksource/clocksource0/current_clocksource</font><br></div><div class="gmail_default"><font face="verdana, sans-serif"><br></font></div><div class="gmail_default"><font face="verdana, sans-serif">... before using fq as most (physical) linux hosts use tsc as the default clock source today unless the kernel detects unreliabilities. </font></div><div class="gmail_default" style="font-family:verdana,sans-serif"></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 25 January 2017 at 22:48, Eric Dumazet <span dir="ltr"><<a href="mailto:eric.dumazet@gmail.com" target="_blank">eric.dumazet@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I do not know any particular issues with FQ in VM<br>
<br>
If you have a recent tc binary (iproute2 package) you can get some<br>
infos, as mentioned in this commit changelog :<br>
<br>
<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fefa569a9d4bc4b7758c0fddd75bb0382c95da77" rel="noreferrer" target="_blank">https://git.kernel.org/cgit/<wbr>linux/kernel/git/torvalds/<wbr>linux.git/commit/?id=<wbr>fefa569a9d4bc4b7758c0fddd75bb0<wbr>382c95da77</a><br>
<br>
<br>
$ tc -s qd sh dev eth0 | grep latency<br>
0 gc, 0 highprio, <a href="tel:32490767" value="+4732490767">32490767</a> throttled, 2382 ns latency<br>
<div><div class="h5"><br>
<br>
On Wed, 2017-01-25 at 22:31 +0100, Hans-Kristian Bakke wrote:<br>
> kvm-clock is a paravirtualized clock that seems to use the CPUs TSC<br>
> capabilities if they exist. But it may not be perfect:<br>
><br>
><br>
> <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Host_Configuration_and_Guest_Installation_Guide/chap-Virtualization_Host_Configuration_and_Guest_Installation_Guide-KVM_guest_timing_management.html" rel="noreferrer" target="_blank">https://access.redhat.com/<wbr>documentation/en-US/Red_Hat_<wbr>Enterprise_Linux/6/html/<wbr>Virtualization_Host_<wbr>Configuration_and_Guest_<wbr>Installation_Guide/chap-<wbr>Virtualization_Host_<wbr>Configuration_and_Guest_<wbr>Installation_Guide-KVM_guest_<wbr>timing_management.html</a><br>
><br>
><br>
> On 25 January 2017 at 22:29, Hans-Kristian Bakke <<a href="mailto:hkbakke@gmail.com">hkbakke@gmail.com</a>><br>
> wrote:<br>
> Actually I think that is because it may be using the newer<br>
> TSC:<br>
> dmesg | grep clocksource<br>
> [ 0.000000] clocksource: kvm-clock: mask:<br>
> 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns:<br>
> 881590591483 ns<br>
> [ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff<br>
> max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns<br>
> [ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles:<br>
> 0xffffffff, max_idle_ns: 19112604467 ns<br>
> [ 0.092665] clocksource: jiffies: mask: 0xffffffff<br>
> max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns<br>
> [ 0.366429] clocksource: Switched to clocksource kvm-clock<br>
> [ 0.378974] clocksource: acpi_pm: mask: 0xffffff<br>
> max_cycles: 0xffffff, max_idle_ns: 2085701024 ns<br>
> [ 1.666474] tsc: Refined TSC clocksource calibration:<br>
> 3200.013 MHz<br>
> [ 1.666479] clocksource: tsc: mask: 0xffffffffffffffff<br>
> max_cycles: 0x2e20562a1bb, max_idle_ns: 440795285529 ns<br>
><br>
><br>
><br>
> On 25 January 2017 at 22:26, Jonathan Morton<br>
> <<a href="mailto:chromatix99@gmail.com">chromatix99@gmail.com</a>> wrote:<br>
><br>
> > On 25 Jan, 2017, at 23:20, Hans-Kristian Bakke<br>
> <<a href="mailto:hkbakke@gmail.com">hkbakke@gmail.com</a>> wrote:<br>
> ><br>
> > [ 0.000000] ACPI: HPET 0x00000000BFFE274F 000038<br>
> (v01 BOCHS BXPCHPET 00000001 BXPC 00000001)<br>
> > [ 0.000000] ACPI: HPET id: 0x8086a201 base:<br>
> 0xfed00000<br>
> > [ 0.000000] clocksource: hpet: mask: 0xffffffff<br>
> max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns<br>
> > [ 0.000000] hpet clockevent registered<br>
> > [ 0.362335] hpet0: at MMIO 0xfed00000, IRQs 2, 8,<br>
> 0<br>
> > [ 0.362339] hpet0: 3 comparators, 64-bit<br>
> 100.000000 MHz counter<br>
> > [ 0.661731] rtc_cmos 00:00: alarms up to one day,<br>
> y3k, 114 bytes nvram, hpet irqs<br>
><br>
> Conspicuously absent here is a line saying<br>
> “clocksource: Switched to clocksource hpet”. That may<br>
> be worth examining in more detail.<br>
><br>
> - Jonathan Morton<br>
><br>
><br>
><br>
><br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> Bloat mailing list<br>
> <a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/bloat</a><br>
<br>
<br>
</blockquote></div><br></div>