Tom, A virtual machine setup is an operating system running on an operating system on top of an operating system.
OK, not quite. The middle one, the VM itself, is as a bit less complex than a full operating system as machine-independent code goes, but nevertheless the machine-dependent bat-shit-crazy stuff is far more complex with gobs of extremely messy nuances face it on both sides because x86 is a fucking minefield Everyone needs to adjust their expectation that all 3 layers are perfect, AND not assume that it is our layer doing the wrong thing Really the layers should simplify but the current marketplace is still gaining more value out of product differentiation than simplification+convergence, both sw and hw Even if our subsystem isn't doing something 'right', it is NOT the stated goal of OpenBSD to run well on every garbage VM, because it has become impossible for the little guy to be perfect. Concerted efforts to diagnose and improve these low-level issues uses the same crowd of people who are trying to improve other edges which may be more important. do you want our vmm to work well? or do you want us to work better on someone else's vmm? Sorry, limited skillset, pick what you want mlarkin to focus on! But that is unfair, and even if he listened to your wishlist, UNPRODUCTIVE. Where does this go? Get ready for monopolies in everything, or oligopolies at best... or fight their establishment. > Just to say the gaps in ping response seems get worse as the uptime increases > ie > with the uptime around 5 minutes the gaps between ping results are around 1 > sec > (what I consider normal) > with the uptime around 2 hrs 45 minutes the gaps between ping results are 13 > sec > with the uptime 8 hrs 30 minutes the gaps between ping results are 35 seconds > > Output of sysctl kern.timecounter below > > kern.timecounter.tick=1 > kern.timecounter.timestepwarnings=0 > kern.timecounter.hardware=acpihpet0 > kern.timecounter.choice=i8254(0) acpihpet0(1000) acpitimer0(1000) > dummy(-1000000) > > I will change the ACPI now to i8254 and report back later on > Thanks > > > On 26 October 2017 at 20:25, Mike Belopuhov <m...@belopuhov.com> wrote: > > On Thu, Oct 26, 2017 at 19:05 +0100, Tom Smyth wrote: > >> Lads, > >> > >> Im pleased to say that my testing of OpenBSD 6.1 and OpenBSD 6.2 > >> Release > >> amd64 , > >> appear to work a little better in Proxmox PVE5.1 as released this week, > >> > >> I used iso version 5.1-722cc488-1 from Proxmox > >> Updated on 24 October 2017 > >> > >> The Console no longer freezes but after a few hours > >> the console (vga console accessed via Proxmox webinterface seems > >> to lag a little > >> the interval between pings for instance takes up to 13 seconds, which > >> is a bit strange... ie it takes 13 seconds for each line of Ping result > >> which is u > >> Ill report more feedback later, but at least OpenBSD is not freezing > >> as bad in this > >> version of Proxmox PVE 5.1 > >> > > > > Hi, > > > > Can you please show us the output of "sysctl kern.timecounter". > > If you're currently using an acpihpet0, can you please try > > switching to the acpitimer0 (and if that doesn't help, i8254) via > > > > sysctl kern.timecounter.hardware=acpitimer0 > > > > and attempt to reproduce the 13 secod delay. > > > > Regards, > > Mike >
