Wonderfull...
I've using them on XP and W2K3. They are working like a charm. Thank you and many thanks to Red hat for releasing these drivers. Regards,

Signature · 3 lines

http://www.glennie.fr
If the only tool you have is hammer, you tend to see every problem as 
a nail.

Kenni Lund

2009-09-24 20:38 UTC #2 lore raw

In reply to Yan Vugenfirer

2009/9/24 Yan Vugenfirer <[email protected]>:

Quoted 4 lines

Hello All,
I am happy to announce that the Windows guest drivers binaries are released.

Thank you, I've been waiting for this for quite a while :)

I've done some benchmarking with the drivers on Windows XP SP3 32bit, but it seems like using the VirtIO drivers are slower than the IDE drivers in (almost) all cases. Perhaps I've missed something or does the driver still need optimization?

I created two raw images of 5GB and attached them to a WinXP SP3 virtual machine with:
"-drive file=virtio.img,if=virtio -drive file=ide.img,if=ide"

I installed the VirtIO drivers, rebooted, formatted the new virtual HDDs with NTFS and downloaded IOMeter. Three different test were run; database workload ("Default" in IOmeter), maximum read throughput and maximum write throughput (settings taken from IOmeter documentation). All results are the average of two individual runs of the test. Each test ran for 3 minutes.

--
Typical database workload
("default" in Iometer: 2kb, 67% read, 33% write, 100% random, 0% sequential) --
Total I/Os per sec:
IDE: 86,67
VirtIO: 66,84

Total MBs per second:
IDE: 0,17MB/sec
VirtIO: 0,13MB/sec

Average I/O response time:
IDE: 11,59ms
VirtIO: 14,96ms

Maximum I/O response time:
IDE: 177,06ms
VirtIO: 244,52ms

% CPU Utilization:
IDE: 3,15%
VirtIO: 2,55%

--
Maximum reading throughput
(64kb, 100% read, 0% write, 0% random, 100% sequential) --
Total I/Os per sec:
IDE: 3266,17
VirtIO: 2694,34

Total MBs per second:
IDE: 204,14MB/sec
VirtIO: 168,40MB/sec

Average I/O response time:
IDE: 0,3053ms
VirtIO: 0,3710ms

Maximum I/O response time:
IDE: 210,60ms
VirtIO: 180,65ms

% CPU Utilization:
IDE: 70,4%
VirtIO: 55,66%

--
Maximum writing throughput
(64kb, 0% read, 100% write, 0% random, 100% sequential) --
Total I/Os per sec:
IDE: 258,92
VirtIO: 123,69

Total MBs per second:
IDE: 16,18MB/sec
VirtIO: 7,74MB/sec

Average I/O response time:
IDE: 3,89ms
VirtIO: 8,17ms

Maximum I/O response time:
IDE: 241,99ms
VirtIO: 838,19ms

% CPU Utilization:
IDE: 8,21%
VirtIO: 4,88%

This was tested on a Arch Linux host with kernel 2.6.30.6 64bit and kvm-88. One CPU and 2GB of RAM was assigned to the virtual machine.

Is this expected behaviour?

Thanks again for your effort on the VirtIO drivers :)

Best Regards
Kenni Lund

Javier Guerra

2009-09-24 20:59 UTC #3 lore raw

Quoted 4 lines · Kenni Lund

I've done some benchmarking with the drivers on Windows XP SP3 32bit, but it seems like using the VirtIO drivers are slower than the IDE drivers in (almost) all cases. Perhaps I've missed something or does the driver still need optimization?

very interesting!

it seems that IDE wins on all the performance numbers, but VirtIO always has lower CPU utilization. i guess this is guest CPU %, right? it would also be interesting to compare the CPU usage from the host point of view, since a lower 'off-guest' CPU usage is very important for scaling to many guests doing I/O.

Signature · 1 line

Javier

Dor Laor

2009-09-24 21:06 UTC #4 lore raw

Quoted 6 lines · Javier Guerra

Quoted 4 lines · Kenni Lund
I've done some benchmarking with the drivers on Windows XP SP3 32bit, but it seems like using the VirtIO drivers are slower than the IDE drivers in (almost) all cases. Perhaps I've missed something or does the driver still need optimization?

Quoted 8 lines

very interesting!
it seems that IDE wins on all the performance numbers, but VirtIO always has lower CPU utilization. i guess this is guest CPU %, right? it would also be interesting to compare the CPU usage from the host point of view, since a lower 'off-guest' CPU usage is very important for scaling to many guests doing I/O.

Can you re-try it with setting the host ioscheduler to deadline? Virtio backend (thread pool) is sensitive for it.

These drivers are mainly tweaked for win2k3 and win2k8. We once had queue depth settings in the driver, not sure we still have it, Vadim, can you add more info?

Also virtio should provide IO parallelism as opposed to IDE. I don't think your test test it. Virtio can provide more virtual drives than the max 4 that ide offers.

Dor

Vadim Rozenfeld

2009-09-25 06:52 UTC #5 lore raw

Quoted 16 lines · Dor Laor

Quoted 6 lines · Javier Guerra
Quoted 4 lines · Kenni Lund
I've done some benchmarking with the drivers on Windows XP SP3 32bit, but it seems like using the VirtIO drivers are slower than the IDE drivers in (almost) all cases. Perhaps I've missed something or does the driver still need optimization?
Quoted 8 lines
very interesting!
it seems that IDE wins on all the performance numbers, but VirtIO always has lower CPU utilization. i guess this is guest CPU %, right? it would also be interesting to compare the CPU usage from the host point of view, since a lower 'off-guest' CPU usage is very important for scaling to many guests doing I/O.

Quoted 8 lines

Can you re-try it with setting the host ioscheduler to deadline? Virtio backend (thread pool) is sensitive for it.
These drivers are mainly tweaked for win2k3 and win2k8. We once had queue depth settings in the driver, not sure we still have it, Vadim, can you add more info?
Also virtio should provide IO parallelism as opposed to IDE. I don't think your test test it. Virtio can provide more virtual drives than the max 4 that ide offers.
Dor

Windows XP 32-bit virtio block driver was created from our mainline code almost for fun.
Not like our mainline code, which is STORPORT oriented, it is a SCSIPORT (!!!!) mini-port driver. SCSIPORT has never been known as I/O optimized storage stack.
SCSIPORT architecture is almost dead officially.
Windows XP 32-bit has no support for STORPORT or virtual storage stack.
Developing monolithic disk driver, which will sit right on top of virtio-blk PCI device, looks like the one way to have some kind of high throughput storage for Windows XP 32-bit.

Regards,
Vadim.

Kenni Lund

2009-09-25 07:53 UTC #6 lore raw

2009/9/25 Vadim Rozenfeld <[email protected]>:

Quoted 26 lines · Dor Laor

Quoted 20 lines · Javier Guerra
Quoted 10 lines · Kenni Lund
Quoted 7 lines
I've done some benchmarking with the drivers on Windows XP SP3 32bit, but it seems like using the VirtIO drivers are slower than the IDE drivers in
(almost) all cases. Perhaps I've missed something or does the driver still
need optimization?
Quoted 8 lines
very interesting!
it seems that IDE wins on all the performance numbers, but VirtIO always has lower CPU utilization. i guess this is guest CPU %, right? it would also be interesting to compare the CPU usage from the host point of view, since a lower 'off-guest' CPU usage is very important for scaling to many guests doing I/O.
Quoted 4 lines
These drivers are mainly tweaked for win2k3 and win2k8. We once had queue depth settings in the driver, not sure we still have it, Vadim, can you add more info?
Dor

Quoted 7 lines

Windows XP 32-bit virtio block driver was created from our mainline code almost for fun.
Not like our mainline code, which is STORPORT oriented, it is a SCSIPORT (!!!!) mini-port driver.
SCSIPORT has never been known as I/O optimized storage stack. SCSIPORT architecture is almost dead officially.
Windows XP 32-bit has no support for STORPORT or virtual storage stack.

Ok, in that case, wouldn't it be better simply not to build the XP driver and instead put a note somewhere (in the wiki?), saying that it doesn't make sense to use VirtIO on XP due to these reasons?

Quoted 3 lines

Developing monolithic disk driver, which will sit right on top of virtio-blk PCI device, looks like the one way
to have some kind of high throughput storage for Windows XP 32-bit.

Ok, since these drivers are targeted Windows Server and XP is getting old, I suppose no efforts will be put into developing such driver, or?

Best Regards,
Kenni

Vadim Rozenfeld

2009-09-25 09:01 UTC #7 lore raw

Quoted 37 lines · Kenni Lund

2009/9/25 Vadim Rozenfeld<[email protected]>:
Quoted 27 lines · Dor Laor
Quoted 21 lines · Javier Guerra
Quoted 10 lines · Kenni Lund
Quoted 8 lines
I've done some benchmarking with the drivers on Windows XP SP3 32bit, but it seems like using the VirtIO drivers are slower than the IDE drivers in
(almost) all cases. Perhaps I've missed something or does the driver still
need optimization?
Quoted 9 lines
very interesting!
it seems that IDE wins on all the performance numbers, but VirtIO always has lower CPU utilization. i guess this is guest CPU %, right? it would also be interesting to compare the CPU usage from the host point of view, since a lower 'off-guest' CPU usage is very important for scaling to many guests doing I/O.
Quoted 5 lines
These drivers are mainly tweaked for win2k3 and win2k8. We once had queue depth settings in the driver, not sure we still have it, Vadim, can you add more info?
Dor
Quoted 8 lines
Windows XP 32-bit virtio block driver was created from our mainline code almost for fun.
Not like our mainline code, which is STORPORT oriented, it is a SCSIPORT (!!!!) mini-port driver.
SCSIPORT has never been known as I/O optimized storage stack. SCSIPORT architecture is almost dead officially.
Windows XP 32-bit has no support for STORPORT or virtual storage stack.

Quoted 4 lines

Ok, in that case, wouldn't it be better simply not to build the XP driver and instead put a note somewhere (in the wiki?), saying that it doesn't make sense to use VirtIO on XP due to these reasons?

I have no idea what was the reason for building and announcing XP 32bit driver. I mean, technically it is possible. You can also expect less CPU consumption by switching to SCSIPORT virtio driver. But please don't expect any significant performance burst.

Quoted 8 lines

Quoted 5 lines
Developing monolithic disk driver, which will sit right on top of virtio-blk PCI device, looks like the one way
to have some kind of high throughput storage for Windows XP 32-bit.
Ok, since these drivers are targeted Windows Server and XP is getting old, I suppose no efforts will be put into developing such driver, or?

I don't know, but why not? It shouldn't be too complicated.

Quoted 7 lines

Best Regards,
Kenni
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html