On Tue, Jul 21, 2009 at 06:41:09AM -0400, Michael Goldish wrote: > > ----- "Dor Laor" <dlaor@xxxxxxxxxx> wrote: > > > On 07/20/2009 06:07 PM, Michael Goldish wrote: > > > Currently the test will only run on Windows. > > > It should be able to run on Linux just as well, but if I understand > > correctly, > > > testing time drift on Linux is less interesting. > > > > Linux is interesting too. The problem is more visible on windows > > since > > it uses 1000hz frequency when it plays multimedia. It makes timer irq > > injection harder. > > If I understand correctly, most Linuxes don't use RTC at all (please > correct me if I'm wrong). This means there's no point in testing > time drift on Linux, because even if there's any drift, it won't get > corrected by -rtc-td-hack. And it's pretty hard to get a drift on > RHEL-3.9 for example -- at least it was very hard for me. https://bugzilla.redhat.com/show_bug.cgi?id=507834 for example. Also we'd like to test different clocks. For example with RHEL5 you can choose, via a kernel boot parameter the following clocks: clock= [BUGS=IA-32, HW] gettimeofday clocksource override. [Deprecated] Forces specified clocksource (if avaliable) to be used when calculating gettimeofday(). If specified clocksource is not avalible, it defaults to PIT. Format: { pit | tsc | cyclone | pmtmr } >From Documentation/kernel-parameters.txt file of the 2.6.18 kernel. Passing options to the guest kernel is also required for other things, and perhaps there should be a generic mechanism to do it. > > Does the test fail without the rtc-td-hack? > > The problem with the test is that it's hard to decide on the drift > thresholds for failure, because the more load you use, the larger the > drift you get. > -rtc-td-hack makes it harder to get a drift -- you need to add more load > in order to get the same drift. > However, in my experiments, when I got a drift, it was not corrected when > the load stopped. If I get 5 seconds of drift during load, and then I > stop the load and wait, the drift remains 5 seconds, which makes me think > I may be doing something wrong. I never got to see the cool fast rotating > clock either. > Another weird thing I noticed was that the drift was much larger when the > VM and load were NOT pinned to a single CPU. It could cause a leap from 5% > to 30%. (my office desktop has 2 CPUs.) > I used Vista with kvm-85 I think. I tried both video load (VLC) and dir /s. > Even if I did something wrong, I hope the test itself is OK, because its > behavior is completely configurable. > > > > > > > Also make some tiny cosmetic changes (spacing), and move the > > stress_boot test > > > before the shutdown test (shutdown should be last). > > > > > > Signed-off-by: Michael Goldish<mgoldish@xxxxxxxxxx> > > > --- > > > client/tests/kvm/kvm_tests.cfg.sample | 46 > > ++++++++++++++++++++++++++------ > > > 1 files changed, 37 insertions(+), 9 deletions(-) > > > > > > diff --git a/client/tests/kvm/kvm_tests.cfg.sample > > b/client/tests/kvm/kvm_tests.cfg.sample > > > index 1288952..2d75a66 100644 > > > --- a/client/tests/kvm/kvm_tests.cfg.sample > > > +++ b/client/tests/kvm/kvm_tests.cfg.sample > > > @@ -92,20 +92,33 @@ variants: > > > test_name = disktest > > > test_control_file = disktest.control > > > > > > - - linux_s3: install setup > > > + - linux_s3: install setup > > > type = linux_s3 > > > > > > - - shutdown: install setup > > > + - timedrift: install setup > > > + type = timedrift > > > + extra_params += " -rtc-td-hack" > > > + # Pin the VM and host load to CPU #0 > > > + cpu_mask = 0x1 > > > + # Set the load and rest durations > > > + load_duration = 20 > > > + rest_duration = 20 > > > + # Fail if the drift after load is higher than 50% > > > + drift_threshold = 50 > > > + # Fail if the drift after the rest period is higher than > > 10% > > > + drift_threshold_after_rest = 10 > > > + > > > + - stress_boot: install setup > > > + type = stress_boot > > > + max_vms = 5 > > > + alive_test_cmd = ps aux > > > + > > > + - shutdown: install setup > > > type = shutdown > > > kill_vm = yes > > > kill_vm_gracefully = no > > > > > > > > > - - stress_boot: > > > - type = stress_boot > > > - max_vms = 5 > > > - alive_test_cmd = ps aux > > > - > > > # NICs > > > variants: > > > - @rtl8139: > > > @@ -121,6 +134,7 @@ variants: > > > variants: > > > # Linux section > > > - @Linux: > > > + no timedrift > > > cmd_shutdown = shutdown -h now > > > cmd_reboot = shutdown -r now > > > ssh_status_test_command = echo $? > > > @@ -303,8 +317,6 @@ variants: > > > > > md5sum=bf4635e4a4bd3b43838e72bc8c329d55 > > > > > md5sum_1m=18ecd37b639109f1b2af05cfb57dfeaf > > > > > > - > > > - > > > # Windows section > > > - @Windows: > > > no autotest > > > @@ -318,6 +330,21 @@ variants: > > > migration_test_command = ver&& vol > > > stress_boot: > > > alive_test_cmd = systeminfo > > > + timedrift: > > > + # For this to work, the ISO should contain vlc > > (vlc.exe) and a video (ED_1024.avi) > > > + cdrom = windows/vlc.iso > > > + time_command = "echo TIME: %date% %time%" > > > + time_filter_re = "(?<=TIME: \w\w\w ).{19}(?=\.\d\d)" > > > + time_format = "%m/%d/%Y %H:%M:%S" > > > + guest_load_command = 'cmd /c "d:\vlc -f --loop > > --no-qt-privacy-ask --no-qt-system-tray d:\ED_1024.avi"' > > > + # Alternative guest load: > > > + #guest_load_command = "(dir /s&& dir /s&& dir /s&& > > dir /s)> nul" > > > + guest_load_stop_command = "taskkill /F /IM vlc.exe" > > > + guest_load_instances = 2 > > > + host_load_command = "bzip2 -c --best /dev/urandom> > > /dev/null" > > > + # Alternative host load: > > > + #host_load_command = "dd if=/dev/urandom of=/dev/null" > > > + host_load_instances = 8 > > > > > > variants: > > > - Win2000: > > > @@ -582,5 +609,6 @@ variants: > > > only > > qcow2.*ide.*default.*up.*Ubuntu-8.10-server.*(autotest.sleeptest) > > > only rtl8139 > > > > > > + > > > # Choose your test list > > > only fc8_quick > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
