From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Re: [Xen-users] About profiling xen Date: Thu, 01 Oct 2009 14:16:56 -0700 Message-ID: <4AC51C48.40203@goop.org> References: <196324.1267.qm@web94604.mail.in2.yahoo.com> <20090930063747.GG1434@reaktio.net> <4AC3E889.6060407@goop.org> <4AC516EC.3050704@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Marco Tizzoni Cc: "Fajar A." , Fasiha Ashraf , xen , xen-users@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 10/01/09 14:05, Marco Tizzoni wrote: >> The clock*event* mechanism is all about setting up timers to raise events. >> >> When running paravirtualized, we use Xen-specific versions of both. >> > Ok. My problem is granularity. In xen I can't raise events more > frequently than 1000/s (with timer set to 1000hz). > Net test softwares such as netperf or hping use setitimer to send > packet at a fixed rate. On a non-xen box they works fine even with > 100k packets/sec (i.e. 100k alarms/sec). This can be problematic for > streaming software and more in general for soft real-time > applications. > [...] > Thanks for your test, I tried and timers work as expected. OK, good, that takes timers out of the equation. I guess the problem is the rate at which Xen will context switch between two domains. Hm. Does anything change if you pin your domains to different cpus? J