Xen users - Feb 2008 - New binary release of GPL PV drivers for Windows

I''ve just uploaded a new binary release of the GPL PV drivers for
Windows - release 0.6.3. Fixes in this version are:

. Should now work on any combination of front and backend bit widths
(32, 32p, 64). Previous crashes that I thought were due to Intel arch
were actually due to this problem.
. The vbd driver will now not enumerate ''boot'' disks (eg those
normally
serviced by the emulated pci ide device) unless the xenhide driver is
loaded which hides that pci ide device. Without this it was possible to
load xenvbd, not load xenhide, and get two windows drivers (xenvbd and
pciide) running the same backend disk. Filesystem hosing was a
near-certain outcome!

For everyone who''s been getting crashes with xenvbd, this should fix
those up.

As usual, any and all feedback is appreciated!

James


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

Oops... forgot the link:

http://www.meadowcourt.org/WindowsXenPV-0.6.3.zip

James

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

Do you have a link to the new binary release?
 
-Nick
>>> On 2008/02/02 at 04:55, "James Harper"
<james.harper@bendigoit.com.au> wrote:
I''ve just uploaded a new binary release of the GPL PV drivers for
Windows - release 0.6.3. Fixes in this version are:

. Should now work on any combination of front and backend bit widths
(32, 32p, 64). Previous crashes that I thought were due to Intel arch
were actually due to this problem.
. The vbd driver will now not enumerate ''boot'' disks (eg those
normally
serviced by the emulated pci ide device) unless the xenhide driver is
loaded which hides that pci ide device. Without this it was possible to
load xenvbd, not load xenhide, and get two windows drivers (xenvbd and
pciide) running the same backend disk. Filesystem hosing was a
near-certain outcome!

For everyone who''s been getting crashes with xenvbd, this should fix
those up.

As usual, any and all feedback is appreciated!

James





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

On Saturday 02 February 2008 04:43:43 pm you wrote:
> Hi James. Really excited about your work. This is the first time (0.6.3)
> that I''ve tried your PV drivers, now that you''ve ruled
out problems on
> Intel arch.
Ok, ignore my private message, and I''m now cc-ing the list. I just
selected
the earliest System Restore point I had, and I was able to wipe out my 
damage, and I installed your drivers smoothly.

First problem is when I select the ''/gplpv'' entry in the boot
menu, I get a
BSOD (message available on request) and the following messages in
dom0''s
(fc8) syslog:

Feb  2 18:03:42 Insp6400 kernel: blkback: ring-ref 2047, event-channel 5, 
protocol 1 (x86_32-abi)
Feb  2 18:03:42 Insp6400 kernel: blkback: ring-ref 2046, event-channel 6, 
protocol 1 (x86_32-abi)

Then I rebooted w/o /gplpv, and was pleased to see that Taskmgr reported I had 
a 2nd connection anyway, Local Area Connection 2, 1Gbps. After some initial 
confusion about why all the computers in my subnet were getting dhcp 
discovery messages logged on their firewalls every 10 secs, I realized that 
both windows connections were using the same mac address, and the
''2''
connection was being ignored by my router/dhcp server. I went into windows 
Start -> Connect To -> Show all connections, and disabled the original
Local
Area Connection.

I must say, I don''t actually see any speed improvements in my crude
tests. Do
I have to do anything to configure the hard disk in windows like I had to 
disable one of my Local Area Connections?

What about the remaining PCI devices under ''Other Devices'' in
Device Manager,
console and vfb, that you didn''t have drivers for? I didn''t
notice any
mention of them in the ToDo.

Thanx for the work so far.

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

> 
> First problem is when I select the ''/gplpv'' entry in the
boot menu, I
get
> a
> BSOD (message available on request) and the following messages in
dom0''s
> (fc8) syslog:
> 
> Feb  2 18:03:42 Insp6400 kernel: blkback: ring-ref 2047, event-channel
5,
> protocol 1 (x86_32-abi)
> Feb  2 18:03:42 Insp6400 kernel: blkback: ring-ref 2046, event-channel
6,
> protocol 1 (x86_32-abi)
> 
That tells me you are running a Dom0 with Xen 3.1.1+ patches applied. Is
that correct?

If you could send me a screen capture of the BSoD, or just the numbers
on it, that could be useful.

Yours and others'' feedback tells me that I haven''t actually
fixed the
bug that a lot of people had reported. And I just can''t reproduce the
problem. What version of Windows are you testing under? I need to know
the product (eg windows 2003 std edition r2) and what service packs you
have applied.
> Then I rebooted w/o /gplpv, and was pleased to see that Taskmgr
reported I
> had
> a 2nd connection anyway, Local Area Connection 2, 1Gbps. After some
> initial
> confusion about why all the computers in my subnet were getting dhcp
> discovery messages logged on their firewalls every 10 secs, I realized
> that
> both windows connections were using the same mac address, and the
''2''
> connection was being ignored by my router/dhcp server. I went into
windows
> Start -> Connect To -> Show all connections, and disabled the
original
> Local
> Area Connection.
> 
> I must say, I don''t actually see any speed improvements in my
crude
tests.
> Do
> I have to do anything to configure the hard disk in windows like I had
to
> disable one of my Local Area Connections?
You should disable the existing qemu-provided LAN device, otherwise you
probably won''t see any difference.
> What about the remaining PCI devices under ''Other
Devices'' in Device
> Manager,
> console and vfb, that you didn''t have drivers for? I
didn''t notice any
> mention of them in the ToDo.
I just disable them. I don''t know that there is any benefit in
providing
PV drivers for them. I might put a stub driver together so at least they
don''t stand out in device manager.

James


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

Jim,

Also, what bit width dom0 and domU are you running? That would also
help.

Thanks

James

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

On Saturday 02 February 2008 08:44:23 pm James Harper
wrote:
> > Feb  2 18:03:42 Insp6400 kernel: blkback: ring-ref 2047, event-channel
5,
> > protocol 1 (x86_32-abi)
> > Feb  2 18:03:42 Insp6400 kernel: blkback: ring-ref 2046, event-channel
6,
> > protocol 1 (x86_32-abi)
>
> That tells me you are running a Dom0 with Xen 3.1.1+ patches applied. Is
> that correct?
Xen 3.1.2, kernel 2.6.21 w/xen.gz compiled from 3.1.0-rc7 (by fedora), all 
32bit PAE.
> If you could send me a screen capture of the BSoD, or just the numbers
> on it, that could be useful.
*** STOP: 0x0000007B (0xF8AB9524,0xC0000034,0x00000000,0x00000000)
> Yours and others'' feedback tells me that I haven''t
actually fixed the
> bug that a lot of people had reported. And I just can''t reproduce
the
> problem. What version of Windows are you testing under? I need to know
> the product (eg windows 2003 std edition r2) and what service packs you
> have applied.
WinXP Pro SP2.
> > both windows connections were using the same mac address, and the
''2''
> > connection was being ignored by my router/dhcp server. I went into
windows
> > Start -> Connect To -> Show all connections, and disabled the
original
> > Local Area Connection.
> >
> > I must say, I don''t actually see any speed improvements in my
crude tests.
Do
> > I have to do anything to configure the hard disk in windows like I had
to
> > disable one of my Local Area Connections?
>
> You should disable the existing qemu-provided LAN device, otherwise you
> probably won''t see any difference.
As I said, I did disable the original ''Local Area Connection''.
I was asking
about the hard disk.
> > What about the remaining PCI devices under ''Other
Devices'' in Device
Manager,
> > console and vfb, that you didn''t have drivers for? I
didn''t notice any
> > mention of them in the ToDo.
>
> I just disable them. I don''t know that there is any benefit in
providing
> PV drivers for them. I might put a stub driver together so at least they
> don''t stand out in device manager.
Actually, the console is the one area of hvm that cries the most for a speed 
increase. Don''t know how much can actually be done with a virtual card,
tho''.

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

Hi Jim, some comments below:

On Feb 3, 2008 3:08 AM, jim burns <jim_burn@bellsouth.net> wrote:
> On Saturday 02 February 2008 08:44:23 pm James Harper wrote:
> > > Feb  2 18:03:42 Insp6400 kernel: blkback: ring-ref 2047,
event-channel
> 5,
> > > protocol 1 (x86_32-abi)
> > > Feb  2 18:03:42 Insp6400 kernel: blkback: ring-ref 2046,
event-channel
> 6,
> > > protocol 1 (x86_32-abi)
> >
> > That tells me you are running a Dom0 with Xen 3.1.1+ patches applied.
Is
> > that correct?
>
> Xen 3.1.2, kernel 2.6.21 w/xen.gz compiled from 3.1.0-rc7 (by fedora), all
> 32bit PAE.
>
> > If you could send me a screen capture of the BSoD, or just the numbers
> > on it, that could be useful.
>
> *** STOP: 0x0000007B (0xF8AB9524,0xC0000034,0x00000000,0x00000000)
>
This seems to be the  same as my problem, Inaccessible Boot Device. Can you
try without installing the "xenhide" driver, and then trying an xm
block-attach on your domain? The driver loads the new disk but can''t
access
with a 0 mb size etc.
>
> > Yours and others'' feedback tells me that I haven''t
actually fixed the
> > bug that a lot of people had reported. And I just can''t
reproduce the
> > problem. What version of Windows are you testing under? I need to know
> > the product (eg windows 2003 std edition r2) and what service packs
you
> > have applied.
>
> WinXP Pro SP2.
>
> > > both windows connections were using the same mac address, and the
''2''
> > > connection was being ignored by my router/dhcp server. I went
into
> windows
> > > Start -> Connect To -> Show all connections, and disabled
the original
> > > Local Area Connection.
> > >
> > > I must say, I don''t actually see any speed improvements
in my crude
> tests.
> Do
> > > I have to do anything to configure the hard disk in windows like
I had
> to
> > > disable one of my Local Area Connections?
> >
> > You should disable the existing qemu-provided LAN device, otherwise
you
> > probably won''t see any difference.
>
> As I said, I did disable the original ''Local Area
Connection''. I was
> asking
> about the hard disk.

As long as the xenhide driver works and the xenvbd driver handles the disk
access, you won''t see any difference. In order to confirm, your disk
device
under device manager, looking at it by view type "by connection", you
shall
see that the disk is under the xenvbd SCSI controller device.  If it''s
still
under IDE controller Intel, then you''ll see no speed difference.

>
> > > What about the remaining PCI devices under ''Other
Devices'' in Device
> Manager,
> > > console and vfb, that you didn''t have drivers for? I
didn''t notice any
> > > mention of them in the ToDo.
> >
> > I just disable them. I don''t know that there is any benefit
in providing
> > PV drivers for them. I might put a stub driver together so at least
they
> > don''t stand out in device manager.
>
> Actually, the console is the one area of hvm that cries the most for a
> speed
> increase. Don''t know how much can actually be done with a virtual
card,
> tho''.
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
Best regards,
erenoglu@gmail.com


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

First, thanks for your great work!

I''ve testet winnet/amd64 on
	Wicrosoft Windows XP
	Professional x64 Edition
	Version 2003
	Service Pack 2

on top of Xen 3.2.0 Release / 64bit running on Xeon E5345

and, in general it works. Installation is a bit tricky, but raw network i/o
is now on both delegated GBit Nics around 40MB/sec.
FTP transferring a 1GB gives about 27MB/sec. to XenPV Disk, about 19MB/sec
to Qemu Disk.

I disabled console and vfb driver, as every reboot states "New Hardware
found,
which can be used after reboot" ... this message keeps up after every
reboot.
This might have to do with the fact, that this domU doesn''t have vnc
and sdl
by default?

Additionally, as well as the former Realtek NIC''s disappeared, the
XenPV NIC''s
need different configurations as Windows says "TCP/IP settings are
identical
on..." and doesn''t accept the settings. I think this is only a
weired Windows
behaviour.

The original Qemu Disk and Qemu CDROM Devices are available to the new XenPV
Disk and CDROM Devices. Where the Qemu CDROM can be disabled, is there any
way to switch over the boot device to the XenPV Disk ?

If someone knows a Windows Benchmarking Suite, I''ll do real tests. I
know my
recent tests are not comparable to any value, but I''m a little bit
handycapped
on windows ;)

cheers,

Stephan

	


James Harper schrieb:
> I''ve just uploaded a new binary release of the GPL PV drivers for
> Windows - release 0.6.3. Fixes in this version are:
> 
> . Should now work on any combination of front and backend bit widths
> (32, 32p, 64). Previous crashes that I thought were due to Intel arch
> were actually due to this problem.
> . The vbd driver will now not enumerate ''boot'' disks (eg
those normally
> serviced by the emulated pci ide device) unless the xenhide driver is
> loaded which hides that pci ide device. Without this it was possible to
> load xenvbd, not load xenhide, and get two windows drivers (xenvbd and
> pciide) running the same backend disk. Filesystem hosing was a
> near-certain outcome!
> 
> For everyone who''s been getting crashes with xenvbd, this should
fix
> those up.
> 
> As usual, any and all feedback is appreciated!
> 
> James
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users

-- 
Stephan Seitz
Senior System Administrator

*netz-haut* e.K.
multimediale kommunikation

zweierweg 22
97074 würzburg

fon: +49 931 2876247
fax: +49 931 2876248

web: www.netz-haut.de <http://www.netz-haut.de/>

registriergericht: amtsgericht würzburg, hra 5054



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

Thanks for the feedback. I have just a few moments ago release another
binary too, but it is mostly to fix a problem under XP.
> 
> I disabled console and vfb driver, as every reboot states "New
Hardware
> found,
> which can be used after reboot" ... this message keeps up after every
> reboot.
> This might have to do with the fact, that this domU doesn''t have
vnc
and
> sdl
> by default?
The XenPCI driver just blindly creates pdo''s (think of a pdo as
something you attach another driver to) for all the devices marked as
present for that domain. Console and vfb are there but I don''t really
know what to do with them.

The release I just did has dummy drivers for console and vfb, so at
least you can make the warning go away without having to disable them.
> Additionally, as well as the former Realtek NIC''s disappeared, the
XenPV
> NIC''s
> need different configurations as Windows says "TCP/IP settings are
> identical
> on..." and doesn''t accept the settings. I think this is only
a weired
> Windows
> behaviour.
Yes. It is. Windows remembers that it has another adapter (even though
it isn''t currently ''plugged in'') and warns you about
that. Ignoring the
warning is the sanest thing to do as you may still want to boot without
/gplpv and have a working network.
> The original Qemu Disk and Qemu CDROM Devices are available to the new
> XenPV
> Disk and CDROM Devices. Where the Qemu CDROM can be disabled, is there
any
> way to switch over the boot device to the XenPV Disk ?
Xenhide is supposed to do this. In fact if you have qemu and xenpv disks
then you are in very serious danger of completely killing your
filesystem! I think I know what might be happening... I think the latest
version of xen doesn''t give the pciide device a special subsys setting.

I''ll fix it and put another release up in a minute.
> If someone knows a Windows Benchmarking Suite, I''ll do real tests.
I
know
> my
> recent tests are not comparable to any value, but I''m a little bit
> handycapped
> on windows ;)
Let me know of the results, but I''d be inclined to do an ''xm
destroy'' on
that domain right now and wait a few minutes until I put up a fix.

James

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

On Saturday 02 February 2008 09:18:25 pm Emre Erenoglu
wrote:
> This seems to be the  same as my problem, Inaccessible Boot Device. Can you
> try without installing the "xenhide" driver, and then trying an
xm
> block-attach on your domain? The driver loads the new disk but
can''t access
> with a 0 mb size etc.
I tried uninstalling xenhide. Boy, did that mess up my vm. Windows had to 
reinstall almost every device in the guest, and now I have to revalidate 
w/Microsoft. Probably analogous to ripping out the backplane of your computer 
and putting in another. I rebooted w/o /gplpv and got my system working 
again. Then i tried rebooting w/ /gplpv, and it hung at the Windows logo for 
a long time. I went to bed, and when I got up, my logs indicated it took 
about 1/2 hour to boot. Interesting thing is power saving had been enabled, 
and my screen was blank. I''ve never seen that before, and had always
wanted
it.

After verifying the condition of my system, I tried a crude benchmark copying 
a large file to dom0, and I got a BSOD w/different numbers as below. I never 
got to do a block-attach, and now I''m just going to try James''
0.6.5 release,
including xenhide.

*** STOP: 0x0000008E (0x80000003,0x805310DD,0x8054FFA8,0x00000000)
> As long as the xenhide driver works and the xenvbd driver handles the disk
> access, you won''t see any difference. In order to confirm, your
disk device
> under device manager, looking at it by view type "by connection",
you shall
> see that the disk is under the xenvbd SCSI controller device.  If
it''s still
> under IDE controller Intel, then you''ll see no speed difference.
 
With and w/o /gplpv, my Qemu disks were still present under the ''Intel
... IDE
Controller''. I didn''t look closely at the the Xen driver to
see if there was
an actual block device attached.

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

> On Saturday 02 February 2008 09:18:25 pm Emre Erenoglu wrote:
> > This seems to be the  same as my problem, Inaccessible Boot Device.
Can
> you
> > try without installing the "xenhide" driver, and then trying
an xm
> > block-attach on your domain? The driver loads the new disk but
can''t
> access
> > with a 0 mb size etc.
> 
> I tried uninstalling xenhide. Boy, did that mess up my vm. Windows had to
> reinstall almost every device in the guest, and now I have to revalidate
> w/Microsoft. Probably analogous to ripping out the backplane of your
> computer
> and putting in another. I rebooted w/o /gplpv and got my system working
> again. Then i tried rebooting w/ /gplpv, and it hung at the Windows logo
> for
> a long time. I went to bed, and when I got up, my logs indicated it took
> about 1/2 hour to boot. Interesting thing is power saving had been
> enabled,
> and my screen was blank. I''ve never seen that before, and had
always
> wanted
> it.
Unless you were using 0.6.3 or older, I would have expected that xenvbd
wouldn''t touch the boot disks without xenhide. Is it possible that the
damage was done earlier and it only just surfaced now?
> After verifying the condition of my system, I tried a crude benchmark
> copying
> a large file to dom0, and I got a BSOD w/different numbers as below. I
> never
> got to do a block-attach, and now I''m just going to try
James'' 0.6.5
> release,
> including xenhide.
> 
> *** STOP: 0x0000008E (0x80000003,0x805310DD,0x8054FFA8,0x00000000)
That''s an ''assert'' statement being executed, eg in
one of the drivers there is a statement that says ''if this condition
isn''t true then crash''. Can you tell me what driver it was
triggered in?
> 
> > As long as the xenhide driver works and the xenvbd driver handles the
> disk
> > access, you won''t see any difference. In order to confirm,
your disk
> device
> > under device manager, looking at it by view type "by
connection", you
> shall
> > see that the disk is under the xenvbd SCSI controller device.  If
it''s
> still
> > under IDE controller Intel, then you''ll see no speed
difference.
> 
> With and w/o /gplpv, my Qemu disks were still present under the
''Intel ...
> IDE
> Controller''. I didn''t look closely at the the Xen driver
to see if there
> was
> an actual block device attached.
Ah yes, xenhide 0.6.4 didn''t do the right thing with Xen 3.2.0.

James

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

On Sun, Feb 03, 2008 at 12:30:51PM +0100, Stephan Seitz
wrote:
> 
> If someone knows a Windows Benchmarking Suite, I''ll do real tests.
I know my
> recent tests are not comparable to any value, but I''m a little bit
> handycapped
> on windows ;)
> 
You could use IOmeter http://www.iometer.org. It''s a widely used disk
benchmarking tool on Windows.

It''s easy to run benchmarks using different requests sizes, different
number
of outstanding io''s etc..

-- Pasi

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

On Mon, Feb 04, 2008 at 06:21:41PM +0200, Pasi Kärkkäinen
wrote:
> On Sun, Feb 03, 2008 at 12:30:51PM +0100, Stephan Seitz wrote:
> > 
> > If someone knows a Windows Benchmarking Suite, I''ll do real
tests. I know my
> > recent tests are not comparable to any value, but I''m a
little bit
> > handycapped
> > on windows ;)
> > 
> 
> You could use IOmeter http://www.iometer.org. It''s a widely used
disk
> benchmarking tool on Windows.
> 
> It''s easy to run benchmarks using different requests sizes,
different number
> of outstanding io''s etc..
> 
With small requests sizes (512 bytes or 4k) you can measure how many IOPS
(IO operations per second) you can get, and with big request sizes (64+ kB)
you can measure how much throughput you can get..

Changing the number of outstanding IO''s means how many IO operations
are
active at the same time (optimal values depends on the storage used, and on
the queue depth of the hardware, drivers and kernel). 

Note that IOmeter wants to use raw disk devices, so don''t create any
partitions or format the disk before using IOmeter.

-- Pasi

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

On Tue, Feb 05, 2008 at 10:22:55AM +0200, Pasi Kärkkäinen
wrote:
> On Mon, Feb 04, 2008 at 06:21:41PM +0200, Pasi Kärkkäinen wrote:
> > On Sun, Feb 03, 2008 at 12:30:51PM +0100, Stephan Seitz wrote:
> > > 
> > > If someone knows a Windows Benchmarking Suite, I''ll do
real tests. I know my
> > > recent tests are not comparable to any value, but I''m a
little bit
> > > handycapped
> > > on windows ;)
> > > 
> > 
> > You could use IOmeter http://www.iometer.org. It''s a widely
used disk
> > benchmarking tool on Windows.
> > 
> > It''s easy to run benchmarks using different requests sizes,
different number
> > of outstanding io''s etc..
> > 
> 
> With small requests sizes (512 bytes or 4k) you can measure how many IOPS
> (IO operations per second) you can get, and with big request sizes (64+ kB)
> you can measure how much throughput you can get..
> 
> Changing the number of outstanding IO''s means how many IO
operations are
> active at the same time (optimal values depends on the storage used, and on
> the queue depth of the hardware, drivers and kernel). 
> 
> Note that IOmeter wants to use raw disk devices, so don''t create
any
> partitions or format the disk before using IOmeter.
> 
And please share your benchmarking results :)

-- Pasi

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

Hi Pasi,

I wasn''t able to get Windows XP Professional x64 running with gplpv
until
James released 0.8.0 if his great drivers.

So my answer is a bit delayed:

Equipment: core2 duo, 2,66GHz, Areca PCI-X Raid 6 over 8 disks


System is running Xen 3.2.0 64bit, dom0 is 2.6.18.8

Tested HVM domU is running XP Pro x64, Version 2003, SP 2, tested with iometer
2006-07-27 stable.

--- Disk/IO using a gplpv''d disk:

pattern: 4k, 50% read, 50% write

	total iops:		~14180
		read		~7045-7065
		write		~7025-7045
	total MB/s:		~55
		read		~27.5
		write		~27.5 (looks like 50%...)

	avg IO response time:	~0.071 ms
	max IO response time:	~19.438 ms
	cpu utilization:	0% (??)

pattern: 32k, 50% read, 50% write

	total iops:		~6900
		read		~3435
		write		~3450
	total MB/s:		~215
		read		~107.5
		write		~107.5

	avg IO response time:	~0.145 ms
	max IO response time:	~21.525 ms
	cpu utilization:	~5.52%


pure read operations with 32k pattern shows about 280 MB/s throughput
pure write operation with 512B pattern shows about 8.5 MB/s througput


--- Disk/IO using a QEMU disk:

pattern: 4k, 50% read, 50% write

	total iops:		~3650
		read		~1828
		write		~1790
	total MB/s:		~14
		read		~7
		write		~7

	avg IO response time:	~0.276 ms
	max IO response time:	~55.242 ms
	cpu utilization:	98.7%

pattern: 32k, 50% read, 50% write

	total iops:		~3064
		read		~1370-1390
		write		~1360
	total MB/s:		~84
		read		~42-44
		write		~40-42

	avg IO response time:	~0.387 ms
	max IO response time:	~77.450 ms
	cpu utilization:	~76.8%


pure read operations with 32k pattern shows about 94 MB/s throughput
pure write operation with 512B pattern shows about 1.8 MB/s througput



--- (filebased) disk IO at dom0 (random, using dbench):

	10 workers on ext3,defaults: ~660 MB/s
	10 workers on xfs,defaults: ~620 MB/s

hdparm shows 3.3 GB/s cached and 366 MB/s buffered



Pasi Kärkkäinen schrieb:
> On Tue, Feb 05, 2008 at 10:22:55AM +0200, Pasi Kärkkäinen wrote:
>> On Mon, Feb 04, 2008 at 06:21:41PM +0200, Pasi Kärkkäinen wrote:
>>> On Sun, Feb 03, 2008 at 12:30:51PM +0100, Stephan Seitz wrote:
>>>> If someone knows a Windows Benchmarking Suite, I''ll do
real tests. I know my
>>>> recent tests are not comparable to any value, but I''m
a little bit
>>>> handycapped
>>>> on windows ;)
>>>>
>>> You could use IOmeter http://www.iometer.org. It''s a
widely used disk
>>> benchmarking tool on Windows.
>>>
>>> It''s easy to run benchmarks using different requests
sizes, different number
>>> of outstanding io''s etc..
>>>
>> With small requests sizes (512 bytes or 4k) you can measure how many
IOPS
>> (IO operations per second) you can get, and with big request sizes (64+
kB)
>> you can measure how much throughput you can get..
>>
>> Changing the number of outstanding IO''s means how many IO
operations are
>> active at the same time (optimal values depends on the storage used,
and on
>> the queue depth of the hardware, drivers and kernel). 
>>
>> Note that IOmeter wants to use raw disk devices, so don''t
create any
>> partitions or format the disk before using IOmeter.
>>
> 
> And please share your benchmarking results :)
> 
> -- Pasi

-- 
Stephan Seitz
Senior System Administrator

*netz-haut* e.K.
multimediale kommunikation

zweierweg 22
97074 würzburg

fon: +49 931 2876247
fax: +49 931 2876248

web: www.netz-haut.de <http://www.netz-haut.de/>

registriergericht: amtsgericht würzburg, hra 5054



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

On Thu, Feb 21, 2008 at 09:08:32PM +0100, Stephan Seitz
wrote:
> Hi Pasi,
> 
> I wasn''t able to get Windows XP Professional x64 running with
gplpv until
> James released 0.8.0 if his great drivers.
> 
> So my answer is a bit delayed:
> 
> Equipment: core2 duo, 2,66GHz, Areca PCI-X Raid 6 over 8 disks
> 
> 
> System is running Xen 3.2.0 64bit, dom0 is 2.6.18.8
> 
> Tested HVM domU is running XP Pro x64, Version 2003, SP 2, tested with 
> iometer 2006-07-27 stable.
>
Thanks for the testing results!

So it seems windows gplpv drivers give almost 4x better performance compared to
emulated
qemu disks.. Nice!

-- Pasi
 
> --- Disk/IO using a gplpv''d disk:
> 
> pattern: 4k, 50% read, 50% write
> 
> 	total iops:		~14180
> 		read		~7045-7065
> 		write		~7025-7045
> 	total MB/s:		~55
> 		read		~27.5
> 		write		~27.5 (looks like 50%...)
> 
> 	avg IO response time:	~0.071 ms
> 	max IO response time:	~19.438 ms
> 	cpu utilization:	0% (??)
> 
> pattern: 32k, 50% read, 50% write
> 
> 	total iops:		~6900
> 		read		~3435
> 		write		~3450
> 	total MB/s:		~215
> 		read		~107.5
> 		write		~107.5
> 
> 	avg IO response time:	~0.145 ms
> 	max IO response time:	~21.525 ms
> 	cpu utilization:	~5.52%
> 
> 
> pure read operations with 32k pattern shows about 280 MB/s throughput
> pure write operation with 512B pattern shows about 8.5 MB/s througput
> 
> 
> --- Disk/IO using a QEMU disk:
> 
> pattern: 4k, 50% read, 50% write
> 
> 	total iops:		~3650
> 		read		~1828
> 		write		~1790
> 	total MB/s:		~14
> 		read		~7
> 		write		~7
> 
> 	avg IO response time:	~0.276 ms
> 	max IO response time:	~55.242 ms
> 	cpu utilization:	98.7%
> 
> pattern: 32k, 50% read, 50% write
> 
> 	total iops:		~3064
> 		read		~1370-1390
> 		write		~1360
> 	total MB/s:		~84
> 		read		~42-44
> 		write		~40-42
> 
> 	avg IO response time:	~0.387 ms
> 	max IO response time:	~77.450 ms
> 	cpu utilization:	~76.8%
> 
> 
> pure read operations with 32k pattern shows about 94 MB/s throughput
> pure write operation with 512B pattern shows about 1.8 MB/s througput
> 
> 
> 
> --- (filebased) disk IO at dom0 (random, using dbench):
> 
> 	10 workers on ext3,defaults: ~660 MB/s
> 	10 workers on xfs,defaults: ~620 MB/s
> 
> hdparm shows 3.3 GB/s cached and 366 MB/s buffered
> 
> 
> 
> Pasi Kärkkäinen schrieb:
> >On Tue, Feb 05, 2008 at 10:22:55AM +0200, Pasi Kärkkäinen wrote:
> >>On Mon, Feb 04, 2008 at 06:21:41PM +0200, Pasi Kärkkäinen wrote:
> >>>On Sun, Feb 03, 2008 at 12:30:51PM +0100, Stephan Seitz wrote:
> >>>>If someone knows a Windows Benchmarking Suite,
I''ll do real tests. I
> >>>>know my
> >>>>recent tests are not comparable to any value, but
I''m a little bit
> >>>>handycapped
> >>>>on windows ;)
> >>>>
> >>>You could use IOmeter http://www.iometer.org. It''s a
widely used disk
> >>>benchmarking tool on Windows.
> >>>
> >>>It''s easy to run benchmarks using different requests
sizes, different
> >>>number
> >>>of outstanding io''s etc..
> >>>
> >>With small requests sizes (512 bytes or 4k) you can measure how
many IOPS
> >>(IO operations per second) you can get, and with big request sizes
(64+
> >>kB)
> >>you can measure how much throughput you can get..
> >>
> >>Changing the number of outstanding IO''s means how many IO
operations are
> >>active at the same time (optimal values depends on the storage
used, and
> >>on
> >>the queue depth of the hardware, drivers and kernel). 
> >>
> >>Note that IOmeter wants to use raw disk devices, so don''t
create any
> >>partitions or format the disk before using IOmeter.
> >>
> >
> >And please share your benchmarking results :)
> >
> >-- Pasi
> 
> 
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Thursday 21 February 2008 03:08:32 pm Stephan Seitz
wrote:
> I wasn''t able to get Windows XP Professional x64 running with
gplpv until
> James released 0.8.0 if his great drivers.
>
> So my answer is a bit delayed:
Ok, here''s my results.

Equipment: core duo 2300, 1.66ghz each, sata drive configured for UDMA/100
System: fc8 32bit pae, xen 3.1.2, xen.gz 3.1.0-rc7, dom0 2.6.21
Tested hvm: XP Pro SP2, 2002, tested w/ iometer 2006-07-27 (1Gb \iobw.tst, 5min
run)

iobw.tst on linux seems to grow to all available disk space - mine was 7Gb for
the first runs w/
/gplpv, then just before I rebooted w/o /gplpv, I created a 4Gb file with dd: dd
if=/dev/zero
of=/iobw.tst bs=2048 count=2097152. Since the client doing the actual disk io is
always
local to the computer being tested, I would expect network io to be negligible,
and the pv
net drivers were always enabled. (Physical eth0 is 100MB/s.)

file backed vbd on local disk, w/ and w/o /gplpv (James Harper''s
0.8.1):

pattern 4k, 50% read, 0% random (what do the minus signs mean?)

(dynamo is the windows or linux client doing the actual work)
dynamo on?  |   io/s   |  MB/s  | Avg. i/o time(ms} | max i/o time(ms) | %CPU
domu w/gplpv|   -83.1  |  -0.32 |      -51.25       |     0            | 45.99
     dom0   |  1485.9  |   5.8  |      -19.19       |      597.5       | 16.05
2nd run:
domu w/gplpv|   273.0  |   1.07 |      431.52       |       0          | 32.27
domu w/qemu |   251.6  |   0.98 |       10.05       |       0          | 28.44
dom0 w/7Gb  |  1040.1  |   4.06 |        0.96       |      395.4       |  0(domu
not involved)
dom0 w/4Gb  |   808.1  |   3.16 |        1.24       |      977.1       |  0
(2nd dom0 numbers from when booted w/o /gplpv)

pattern 32k, 50% read, 0% random

domu w/gplpv|   161.6  |   5.05 |       -3.32       |        0         | 19.80
domu w/qemu |   109.0  |   3.41 |       -8.93       |        0         | 25.35
dom0 w/7Gb  |   140.7  |   4.40  |       7.10       |      467.6       |  0
dom0 w/4Gb  |   159.3  |   4.98 |        6.28       |      270.1       |  0

Conclusion: gplpv disk drivers severely lag dom0 disk performance for small
pattern io, but is similar for large pattern io.

Now for the same tests with Halsign. This time, the file backed vbd is on a
samba share mounted on dom0.

dynamo on?  |   io/s   |  MB/s  | Avg. i/o time(ms} | max i/o time(ms) | %CPU
domu w/hals.|   331.3  |   1.29 |      -31.78       |       0          | 39.02
domu w/qemu |   460.2  |   1.80 |       -5.85       |       0          | 42.35
dom0 w/4Gb  |   958.1  |   3.75 |        1.04       |      187.8       |  0
dom0 w/4Gb  |  1080.5  |   4.22 |        0.92       |      192.2       |  0
(2nd dom0 numbers from when booted w/o /pv)

pattern 32k, 50% read, 0% random

domu w/hals.|    81.1  |   2.53 |       49.94       |        0         | 36.36
domu w/qemu |    74.6  |   2.33 |       10.11       |        0         | 32.00
dom0 w/4Gb  |   138.9  |   4.34  |       7.20       |      340.8       |  0
dom0 w/4Gb  |   148.0  |   4.62 |        6.76       |      228.6       |  0

Conclusion: Even tho'' samba might be expected to be slower than a local
disk,
the small pattern numbers are very similar to gplpv, possibly because the io
is being offloaded on the samba host. The domu 32k pattern numbers are less
than dom0, unlike gplpv, but that may be because my samba buffers are only
8k.

And now, just for grins, the results from putting a dynamo client on a pv fc8
domu (I had to disable the firewalls on both domus):

pattern?    |   io/s   |  MB/s  | Avg. i/o time(ms} | max i/o time(ms) | %CPU
4k, 50% read|   931.2  |   3.64 |        1.07       |       294.0      |  0
32k,50% read|   191.8  |   5.99 |        5.21       |       389.8      |  0

The numbers are very similar to dom0.

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