Date: Tue, 02 Jun 2009 09:49:03 +0200 From: Mister Olli <mister.olli@googlemail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-xen@freebsd.org Subject: Re: Clock TOD issues (mostly) resolved? Message-ID: <1243928943.2351.5.camel@phoenix.blechhirn.net> In-Reply-To: <d763ac660905310604l6a5e1887ne8f7bd4971784b79@mail.gmail.com> References: <d763ac660905290645v331d3387x2549eda596b939b8@mail.gmail.com> <1243774686.12279.7.camel@phoenix.blechhirn.net> <d763ac660905310604l6a5e1887ne8f7bd4971784b79@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1243928943.2351.5.camel>