Clock TOD issues (mostly) resolved?

[Mister Olli]

Hi,

> > - scp'ing the kernel file to the dom0 instance hanged after transfering
> >        ~ 1MB of data and did not finish. This now works perfect. I
> >        hadn't got the time to test larger network transfers.
> 
> Good!

Sorry on that, I just recognized that it's not fixed right now. Maybe
Most probable I've tested with the wrong kernel, since I have a r kernel
here to transfer my freshly build kernel to the host dom0.
I just tested with r193225 and it didn't work. Transfer always stops
after 2112kb of transfered data, no matter what kind of data I copy:

======================================================================== 
template-8_CURRENT# scp /boot/kernel/kernel dante at 10.30.1.15:/tmp
Password: 
kernel                                         46% 2112KB 268.4KB/s - stalled -^CKilled by signal 2.
template-8_CURRENT# dd if=/dev/zero of=/tmp/more_data bs=1024k count=512
512+0 records in
512+0 records out
536870912 bytes transferred in 27.200000 secs (19737901 bytes/sec)
template-8_CURRENT# scp /tmp/more_data dante at 10.30.1.15:/tmp
Password: 
more_data                                       0% 2112KB 662.8KB/s - stalled -^CKilled by signal 2.
template-8_CURRENT#
========================================================================

Transfering smaller files (like SVN checkout) works like a charm within
the domU.
I also tested transfering 512MB of data from dom0 -> domU and it worked
as expected.


> 
> > - clock jumps fully disappeared for me. I can do a complete 'make
> >        buildworld' without any interruptions due to the time jump, even
> >        when I'm not using ntpd within the domU.
> 
> Good! The time will still drift a little until a hypervisor wall clock
> sync occurs (mostly due to a large enough change to the dom0 time);
> I'll investigate that later. I'm curious to know exactly how Linux
> DomU's manage to keep in lock-step with the dom0 time.

Didn't recognize any heavy time drifts until now. I have less than 0.5
after ~14 hours uptime. This is great :-)


Regards,
---
Mr. Olli