I sent this mail to xen-users, but no answer so I try here just in case:
Hello everyone,
I''m currently trying to run an Asterisk server in a Xen kernel under 
Dom0 (debian kernel 2.6.18 with xen hypervisor 3.0.4). I had read of 
some possible timing issues with ztdummy (using rtc) under DomU, but I 
have a zaptel compatible PCI card (TDM400P), and I experience big 
problems with IRQ misses every time there is a bit of load on the server 
(for example, when an HVM DomU is running). The card is supposed to 
report 1000 interruptions per second, but it doesn''t, and consequences 
are horrible crackling sound in communications. Running the utility 
zttest to check for the stability of those interrupts under a small bit 
of load, i get:
# ./zttest
Opened pseudo zap interface, measuring accuracy...
99.609375% 99.609375% 99.218750% 99.316406% 99.804688% 99.414062% 
99.121094%
99.511719% 99.121094% 99.316406% 99.707031% 99.707031% 98.730469% 
99.414062% 99.902344%
99.218750% 100.000000% 99.414062% 98.828125% 99.218750% 99.316406% 
98.449707% 100.000000%
(from digium: results should be >= 99.98 in order not to have sound 
problems)
I tried about everything I could find on Asterisk documentation: moving 
PCI slots, noapic and acpi=off boot options, play with different kernel 
options: iosched/preemption/timer/..., play with BIOS PCI options, PCI 
latencies, IRQ balance, smp_afinity, ................ but impossible to 
come up with anything correcting that problem.
I then mailed to Asterisk user mailing list and they told me:
"Xen has many, many problems with interrupt handling and is utterly
unsuitable for running anything that depends on hardware peripherals. I
speak from very painful experience.
There is no way, under any circumstance, that I would try to run
Asterisk with interface cards in a Xen environment. It''s too bad you
wasted so much time trying to fix it -- it''s never going to work."
Does anyone have an idea of how to possibly resolve this issue, or 
should I really abandon the idea using Xen and Asterisk together?
# xm info
host                   : sol
release                : 2.6.18
version                : #3 SMP Fri May 11 11:32:34 CEST 2007
machine                : x86_64
nr_cpus                : 2
nr_nodes               : 1
sockets_per_node       : 1
cores_per_socket       : 2
threads_per_core       : 1
cpu_mhz                : 2009
hw_caps                : 
178bfbff:e3d3fbff:00000000:00000010:00000001:00000000:00000003
total_memory           : 2047
free_memory            : 136
xen_major              : 3
xen_minor              : 0
xen_extra              : .3-1
xen_caps               : xen-3.0-x86_64
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : Tue Oct 17 22:09:52 2006 +0100
cc_compiler            : gcc version 4.1.2 20061028 (prerelease) (Debian 
4.1.1-19)
cc_compile_by          : ultrotter
cc_compile_domain      : debian.org
cc_compile_date        : Fri Nov  3 00:21:27 CET 2006
xend_config_format     : 2
# cat /proc/interrupts
         CPU0              CPU1
1:         94          0        Phys-irq  i8042
6:          3          0        Phys-irq  floppy
8:          0          0        Phys-irq  rtc
9:          0          0        Phys-irq  acpi
14:         63          0        Phys-irq  ide0
16:          1          0        Phys-irq  libata, eth3
17:     532462          0        Phys-irq  libata
18:       4102          0        Phys-irq  libata
19:     493234          0        Phys-irq  sky2, eth0
20:     689908          0        Phys-irq  eth1
21:    5559727          0        Phys-irq  wctdm
256:    3022027          0     Dynamic-irq  timer0
257:     522260          0     Dynamic-irq  resched0
258:         43          0     Dynamic-irq  callfunc0
259:          0     432127     Dynamic-irq  resched1
260:          0        106     Dynamic-irq  callfunc1
261:          0    1743951     Dynamic-irq  timer1
262:       1020          0     Dynamic-irq  xenbus
263:          0          0     Dynamic-irq  console
NMI:          0          0
LOC:          0          0
ERR:          0
MIS:          0
Thanks,
François.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
> I''m currently trying to run an Asterisk server in a Xen kernel under > Dom0 (debian kernel 2.6.18 with xen hypervisor 3.0.4). I had read of > some possible timing issues with ztdummy (using rtc) under DomU, but I > have a zaptel compatible PCI card (TDM400P), and I experience big > problems with IRQ misses every time there is a bit of load on the server > (for example, when an HVM DomU is running). The card is supposed to > report 1000 interruptions per second, but it doesn''t, and consequences > are horrible crackling sound in communications. Running the utility > zttest to check for the stability of those interrupts under a small bit > of load, i get:I believe folk have had success running asterisk in a domU and assigning the PCI device directly to the guest. It''s best to set the affinity masks for other guests and dom0 such that the domU with asterisk in it has a dedicated physical CPU core. We ran asterisk on an older version of Xen without any problems, and nothing has changed that should effect xen''s ability to do this. [you could try using the sedf scheduler if you still have problems with ''credit''] Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I actually first asked to asterisk mailing lists, and a few persons told me that it was Xen''s fault, as it was not yet ''mature'' enough to have a good IRQ handling under load. Note that I made tests the last few days as I wasn''t sure if it was Xen or not, and the exact same system works perfectly with a normal Linux kernel (same config file except for Xen stuff that are removed). A Dom-0 kernel without any VMs running comports itself the way I described (bad), and I tried both schedulers (sedf and credit) without success. It doesn''t appear to be a load problem as the load is about the same with the non-Xen kernel I tried, but with IRQ handling in load period. I''m talking about a machine that is certainly not over-loaded, but that once in a while suffers some iowait for disk access. Under Xen kernel, if I kill everything I can and only leave Asterisk with at most one simultaneous conversation, it works quite nice. I''m using the debian (I think they actually come from fedora) patches for 2.6.18, and just want to know if this issue is known or has/will been/be resolved somehow in future versions, if there is anyway I can deal with it with some kernel configuration, or if I should wait a few months/years more to be able to use Xen in my specific setting. Thanks, François. Ian Pratt wrote:>> I''m currently trying to run an Asterisk server in a Xen kernel under >> Dom0 (debian kernel 2.6.18 with xen hypervisor 3.0.4). I had read of >> some possible timing issues with ztdummy (using rtc) under DomU, but I >> have a zaptel compatible PCI card (TDM400P), and I experience big >> problems with IRQ misses every time there is a bit of load on the server >> (for example, when an HVM DomU is running). The card is supposed to >> report 1000 interruptions per second, but it doesn''t, and consequences >> are horrible crackling sound in communications. Running the utility >> zttest to check for the stability of those interrupts under a small bit >> of load, i get: >> > > I believe folk have had success running asterisk in a domU and assigning the PCI device directly to the guest. It''s best to set the affinity masks for other guests and dom0 such that the domU with asterisk in it has a dedicated physical CPU core. > > We ran asterisk on an older version of Xen without any problems, and nothing has changed that should effect xen''s ability to do this. [you could try using the sedf scheduler if you still have problems with ''credit''] > > Ian > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel