Re: [Xen-users] ntpd under Xen Dom0 exhibits extremely high jitter/noise? runs stable/quiet under non-xen kernel.

[Pasi Kärkkäinen <pasik@xxxxxx>]

On Tue, Jan 12, 2010 at 06:14:57PM -0800, mail ignored wrote:
> On a selection of boxes, ntpd running in Xen Dom0 reproducibly
> exhibits extermely high noise/jitter.
> Switching back to -default, non-xen kernel ntpd runs with very low 
> jitter/noise.
> 
> Question -- how can I 'tame' ntpd noise & jitter when running in Dom0?
>  Is the problem a config issue, or a bug?
> 
> Already reported this downstream; everybody's "stumped".
> 

How many vcpus does your dom0 have? Have you configured domain weights
(ie. guaranteed cpu time for dom0?)

Have you tried dedicating a single cpu core only for dom0? 

-- Pasi

> Running
> 
>  uname -a
>   Linux test 2.6.31.8-0.1 #1 SMP 2009-12-15 23:55:40 +0100 x86_64
> x86_64 x86_64 GNU/Linux
> 
> with @ grub,
> 
>  kernel /vmlinuz root=/dev/V0/ROOT rootfstype=ext4
> rootflags=journal_checksum resume=/dev/V0/SWAP showopts splash=silent
> selinux=0 SELINUX_INIT=NO elevator=cfq vga=0x31a console=tty0
> console=ttyS0,57600n8
> 
>  cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>    tsc
> 
> on 5 different mobos, all with AMD Phenom II X4 Deneb Cores
> (http://en.wikipedia.org/wiki/List_of_AMD_Phenom_microprocessors#.22Deneb.22_.28C2.2C_45_nm.2C_quad-core.29)
> 
> e.g.,
> 
>  grep "model name" /proc/cpuinfo
>    model name      : AMD Phenom(tm) II X4 920 Processor
>  grep flags /proc/cpuinfo
>    flags           : fpu de tsc msr pae mce cx8 apic mtrr mca cmov pat
> clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext
> 3dnow constant_tsc rep_good nonstop_tsc pni cx16 popcnt hypervisor
> lahf_lm cmp_legacy extapic cr8_legacy abm sse4a misalignsse
> 3dnowprefetch
> 
> running ntpd, within ~ 5 minutes of launch,
> 
>  ntpq -p -c rv
> 
> returns expected low-jitter, low-offset, full-reach results,
> 
>              remote           refid      st t when poll reach   delay   offset
>       jitter
>       
> ==============================================================================
>         *clock.fmt.he.ne .PPS.            1 u    2  128  377   14.472    6.176
>       21.235
>         +otc2.psu.edu    128.4.1.1        2 u   68  128  377   98.808   17.478
>       33.898
>         +clock.isc.org   216.200.141.8    2 u   67  128  377   15.491   -4.421
>       22.236
>         +clock.sjc.he.ne .CDMA.           1 u   66  128  377   14.973   14.981
>       23.539
>         +zorro.sf-bay.or 216.218.254.202  2 u   77  128  377   14.861   -5.981
>       14.786
>         +rrcs-64-183-56- .GPS.            1 u  124  128  377   34.705   11.295
>       36.253
>         +nist1.aol-ca.tr .ACTS.           1 u   62  128  377   16.302    8.190
>       24.812
> 
> rebooting to,
> 
>  uname -a
>   Linux test 2.6.31.8-0.1-xen #1 SMP 2009-12-15 23:55:40 +0100 x86_64
> x86_64 x86_64 GNU/Linux
> 
> with @ grub,
> 
>  kernel /xen.gz loglvl=all loglvl_guest=all dom0_mem=1024M
> vga=gfx-1280x1024x32 console=vga,com1 com1=57600,8n1 iommu=1
> cpufreq=xen:performance cpuidle
>  module /vmlinuz-xen root=/dev/V0/ROOT rootfstype=ext4
> rootflags=journal_checksum resume=/dev/V0/SWAP showopts splash=silent
> selinux=0 SELINUX_INIT=NO elevator=cfq vga=0x31a console=tty0
> console=xvc0,57600 iommu=off noirqdebug clocksource=xen
> 
> and,
> 
>  cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>    xen
> 
>  cat /etc/init.d/boot.local
>    xenpm set-scaling-governor ondemand
>    xenpm set-scaling-governor performance
> 
> after boot,
> 
>  cat /proc/cpuinfo | grep MHz
>   cpu MHz         : 2800.000
>   cpu MHz         : 2800.000
>   cpu MHz         : 2800.000
>   cpu MHz         : 2800.000
> 
>  xenpm get-cpufreq-para | grep governor
>   current_governor     : performance
>   current_governor     : performance
>   current_governor     : performance
>   current_governor     : performance
> 
> ntpd @ Dom0 return extremely high offset & jitter, never dropping to
> 'normal', non-xen levels; e.g., even after 2-3 days of running,
> 
>             remote           refid      st t when poll reach   delay   offset 
>  jitter
>       
> ==============================================================================
>         +clock.fmt.he.ne .PPS.            1 u   60   64  377   21.185  -1690.8
>       658.866
>         +otc2.psu.edu    128.4.1.1        2 u   33   64  377  109.992  -1754.1
>       659.825
>         +clock.isc.org   216.200.141.8    2 u    2   64  377   13.304  -1827.8
>       676.431
>         *clock.sjc.he.ne .CDMA.           1 u   46   64  377   21.193  -1724.5
>       655.151
>          zorro.sf-bay.or 216.218.254.202  2 u   53   64  377   15.396  -1711.7
>       653.852
>         +rrcs-64-183-56- .GPS.            1 u   28   64  377   53.359  -1766.9
>       657.547
>         +nist1.aol-ca.tr .ACTS.           1 u   37   64  377   22.613  -1742.4
>       665.713
> 
> Also, with ntpd *off*,
> 
> @ boot to kernel-default
>   sntp clock.isc.org && date && hwclock --show
>       2009 Dec 28 10:38:49.000867 + 0.250226 +/- 0.023099 secs
>       Mon Dec 28 10:38:50 PST 2009
>       Mon 28 Dec 2009 10:38:51 AM PST  -0.998094 seconds
> 
> @ boot to kernel-xen
>   sntp clock.isc.org && date && hwclock --show
> !     2009 Dec 28 10:31:32.000206 + 28800.725203 +/- 0.013941 secs
> !     Mon Dec 28 18:31:32 PST 2009
>       Mon 28 Dec 2009 10:31:33 AM PST  -0.638684 seconds
> 
> note the dramatic differences in 'sntp' & 'date' results.  These
> results can be reproduced swithicn back and forth between -xen &
> -default kernel boots.
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users