Clock TOD issues (mostly) resolved?
adrian at freebsd.org
Tue Jun 2 08:08:36 UTC 2009
Just create a PR for the copying issue and email me the PR number.
2009/6/2 Mister Olli <mister.olli at googlemail.com>:
>> > - 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.
> 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
> 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
> more_data 0% 2112KB 662.8KB/s - stalled -^CKilled by signal 2.
> 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 :-)
> Mr. Olli
More information about the freebsd-xen