similar to: "Tick-counting" vs "Tick-less" timekeeping issues on VMs emulating BIOS PCs

On 03/01/16 21:11, H. Peter Anvin via Syslinux wrote: > On 03/01/16 07:21, Patrick Masotta via Syslinux wrote: >> >> At the moment I'm seeing timing issues on TFTP transfers (lwIP depends >> on the new interrupt based timer). I have consistently detected >> >> multiple Requests, double ACKs, etc. All these problems seem to be >> >> sourced on the

>>> ... Bottom line; There are timing issues with TFTP transfers on VM machines emulating BIOS hardware. Probably the interrupt based timer is not the culprit; now I'm working on /core/fs/pxe/core.c trying to see if there's something wrong there. Best, Patrick <<< I've been working on this issue, I have tested the timers, and as you guys mentioned before they

On 03/03/16 09:45, Patrick Masotta wrote: > > At the BIOS standard rate of 18.2Hz, no modern machine is even going to > > notice. > > I think they do when running a VM, > > That's why my Debian VM date is always indicating whatever, > no matter how many times I reset the time of the day. > (Running on a i7-3630QM host) > For some reason they cannot emulate a

> > There are quite a few; primarily we simply cannot make lwIP > (lpxelinux.0) work without it. However, pxelinux.0 should not depend on > this. I'm finding most of the problems on lpxelinux.0 > >Now, tickful timekeeping is wasteful, but this is a bootloader, and >functionality is the main concern. The "tickless" version still >depended on the BIOS

On 03/03/16 09:18, Patrick Masotta wrote: >>>> How so? > > it says they cannot emulate the timer interrupt very well; > that's what I understood... If it's the VMware document I'm thinking of (titled "Timekeeping in VMware Virtual Machines"), then the issue is that emulating the timer interrupt can cause a heavy load on the host if the guest timer is

On 03/03/16 09:34, Patrick Masotta wrote: > > If it's the VMware document I'm thinking of (titled "Timekeeping in > > VMware Virtual Machines"), then the issue is that emulating the timer > > interrupt can cause a heavy load on the host if the guest timer is > > configured to run at a high rate. > > It seems it's more that that even at the

On 02/03/16 22:47, Patrick Masotta via Syslinux wrote: > Not really, a virtual environment can easily emulate the BIOS_timer at 0x046C > but it has problems emulating a "real" timer interrupt to be hooked... > That's the real problem. The timer interrupt works fine in at least KVM, Xen, VMware, and Hyper-V. (I've tested iPXE in all of those virtual environments, and

On 03/01/16 07:21, Patrick Masotta via Syslinux wrote: > > At the moment I'm seeing timing issues on TFTP transfers (lwIP depends > on the new interrupt based timer). I have consistently detected > > multiple Requests, double ACKs, etc. All these problems seem to be > > sourced on the now unreliable timeouts. > I have used TFTP on the same (BIOS VM) scenarios with

>>> If it's the VMware document I'm thinking of (titled "Timekeeping in VMware Virtual Machines"), then the issue is that emulating the timer interrupt can cause a heavy load on the host if the guest timer is configured to run at a high rate. Michael <<< It seems it's more that that even at the regular rate... Best, Patrick

On 03/03/16 07:31, Patrick Masotta wrote: > > The timer interrupt works fine in at least KVM, Xen, VMware, and > > Hyper-V. (I've tested iPXE in all of those virtual environments, and > > iPXE relies on the timer interrupt actually triggering a call to an ISR > > within the VM.) > > Well, that contradicts what the VMware document says. How so? Michael

On Mon, Mar 7, 2016 at 10:50 AM, Patrick Masotta via Syslinux <syslinux at zytor.com> wrote: >>>> > > ... > Bottom line; There are timing issues with TFTP transfers > on VM machines emulating BIOS hardware. > Probably the interrupt based timer is not the culprit; > now I'm working on /core/fs/pxe/core.c trying to see if > there's something wrong

>>> > Not really, a virtual environment can easily emulate the BIOS_timer at 0x046C > but it has problems emulating a "real" timer interrupt to be hooked... > That's the real problem. The timer interrupt works fine in at least KVM, Xen, VMware, and Hyper-V. (I've tested iPXE in all of those virtual environments, and iPXE relies on the timer interrupt

>>> Your Linux guest will have reconfigured the timer interrupt to run faster than the BIOS standard rate of 18.2Hz. Michael <<< It could be; I really do not know. Bottom line; There are timing issues with TFTP transfers on VM machines emulating BIOS hardware. Probably the interrupt based timer is not the culprit; now I'm working on /core/fs/pxe/core.c trying to

>>>How so? it says they cannot emulate the timer interrupt very well; that's what I understood...

>>> At the BIOS standard rate of 18.2Hz, no modern machine is even going to notice. Michael <<< I think they do when running a VM, That's why my Debian VM date is always indicating whatever, no matter how many times I reset the time of the day. (Running on a i7-3630QM host) For some reason they cannot emulate a good timer interrupt. Best, Patrick

In 780427f0e11 (Indicate that clock was set in the pvclock gtod notifier), logic was added to pass a CLOCK_WAS_SET notification to the pvclock notifier chain. While that patch added a action flag returned from accumulate_nsecs_to_secs(), it only uses the returned value in one location, and not in the logarithmic accumulation. This means if a leap second triggered during the logarithmic

In 780427f0e11 (Indicate that clock was set in the pvclock gtod notifier), logic was added to pass a CLOCK_WAS_SET notification to the pvclock notifier chain. While that patch added a action flag returned from accumulate_nsecs_to_secs(), it only uses the returned value in one location, and not in the logarithmic accumulation. This means if a leap second triggered during the logarithmic

People at vmware have provided patches for RHEL 5 that aim to fix timekeeping issues in vmware guests. https://bugzilla.redhat.com/show_bug.cgi?id=463573 Description of problem (excerpt) : "In a virtual environment, timekeeping for RHEL 64 bit kernels can be problematic, since time is kept by counting timer interrupts for this kernel. The problem arises when the VM is descheduled for some

This is really stupid question. But referring to: http://lists.centos.org/pipermail/centos/2009-October/083791.html I don't see any line related to ntpd in my /var/log/messages . Do I need to turn-on ntpd for timekeeping on VMs? Some people say not to use ntpd on VMs for timekeeping or is it ntpdate cron job? Can someone please elaborate on this? Thanks, Jonathan. -------------- next part

> Le 11/03/2014 10:32, Eric PEYREMORTE a ?crit : > Some news here. I didn't test with 5.01 yet (didn't see that one sorry). > With 5.01 i don't have any problem. Problems begin with 5.10. > -- > Eric PEYREMORTE Hello Eric: To sum up your report: _ 4.0x works; _ 4.10-pre22 (lwip branch) works; _ 5.01 (elflink branch) works; _ 5.10 (lwip merge into elflink) fails; I