[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] theoretical network rx performance of Windows with PVdrivers


  • To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
  • Date: Wed, 19 Nov 2008 20:44:37 +1100
  • Cc:
  • Delivery-date: Wed, 19 Nov 2008 01:45:02 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AclJdZaq6OGodxhGRNi3MA0h9mpWyQABil1rAAAYkYAAK5u6YA==
  • Thread-topic: [Xen-devel] theoretical network rx performance of Windows with PVdrivers

> >
> > I don't think evtchn->IRQ latency is particularly large. But also I
> > don't know what else might be causing your erratic behaviour.
> >
> 
> That's probably all I needed to know for now. I think it might
actually
> be Windows that's the problem...
> 

*sigh*

I was queuing the next dpc (under windows, the dpc is the bit that get
scheduled by the isr and runs at a lower priority than the isr but
higher than normal user code) and then measuring the time until the next
dpc occurred. I also re-queue another dpc when too much work has been
done by the current instance to try and even out the load a bit - dpcs
are supposed to complete in microseconds. When there was a large delay
between the queuing and the executing of the dpc I assumed it was
windows delaying it for some reason, but it's my code after the
re-queuing and the end of the dpc that is delaying things. There is
still a problem with Windows taking too long to do things, but it's not
where I thought it was.

I guess I'm just too used to everything being Windows's fault :)

Thanks

James

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.