<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif"><div class="gmail_default"> dmesg | grep HPET</div><div class="gmail_default">[    0.000000] ACPI: HPET 0x00000000BFFE274F 000038 (v01 BOCHS  BXPCHPET 00000001 BXPC 00000001)</div><div class="gmail_default">[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000</div><div><br></div><div>I seem to indeed have a HPET in my VM. Does that mean that I should be able to use fq as intended or could the HPET be some kind of virtualized device?</div><div><br></div><div>Regards,</div><div>Hans-Kristian </div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 25 January 2017 at 22:09, Jonathan Morton <span dir="ltr"><<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 25 Jan, 2017, at 23:05, Hans-Kristian Bakke <<a href="mailto:hkbakke@gmail.com">hkbakke@gmail.com</a>> wrote:<br>
><br>
> Do I understand correctly that fq is really just hit and miss within a VM in general then? Is there no advantage to the fair queing part even with a low-precision clock?<br>
<br>
</span>First, check using dmesg or whatever that you do, or do not, have a working HPET within your VM.<br>
<br>
If this is a widespread problem, I could concoct a patch to sch_fq which compensates for it.  I already fixed the same problem when using part of sch_fq as a basis for part of sch_cake, and demonstrated correct operation on an old, slow PC without an HPET.<br>
<span class="HOEnZb"><font color="#888888"><br>
 - Jonathan Morton<br>
<br>
</font></span></blockquote></div><br></div>