Xen users - Mar 2011 - Slow windows network with gplpv driver.

This concerns an old problem
http://lists.xensource.com/archives/html/xen-users/2010-08/msg00567.html

Still having the problem with network performance but need to really fix it.

Just did a test with 32 bit xp with 0.11.0.238 drive.
it show device as Xen Net device driver.

Iperf gives 14.7 Mbits/sec

Running an xp live boot cd  get 13.6 Mbits/sec
Doesn''t looks like the the pv driver is doing anything to help the
network as
there is probably extra load with no pv drivers for disk and display.

How much of a speed improvement are others seeing?

The real issue is speed for samba shares. 

I have tried on other hardware and it''s a bit faster but not that
impressive.
To keep the speed in perspective this is /proc/cpuinfo

8 cores like this:
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU           E5310  @ 1.60GHz
stepping        : 7
cpu MHz         : 1596.078
cache size      : 4096 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov pat clflush 
acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good aper
fmperf pni ssse3 cx16 hypervisor lahf_lm
bogomips        : 3192.15
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

Any suggestions?
I''m willing to try most anything as if I do not get this better
I''ll have a
lot of work to do, redoing most everything :-(

John


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

> 
> This concerns an old problem
>
http://lists.xensource.com/archives/html/xen-users/2010-08/msg00567.html
> 
> Still having the problem with network performance but need to really
fix it.
> 
> Just did a test with 32 bit xp with 0.11.0.238 drive.
> it show device as Xen Net device driver.
> 
> Iperf gives 14.7 Mbits/sec
> 
> Running an xp live boot cd  get 13.6 Mbits/sec
> Doesn''t looks like the the pv driver is doing anything to help the
network as
> there is probably extra load with no pv drivers for disk and display.
> 
> How much of a speed improvement are others seeing?
> 
> The real issue is speed for samba shares.
> 
> I have tried on other hardware and it''s a bit faster but not that
impressive.
> To keep the speed in perspective this is /proc/cpuinfo
> 
XP is probably a poor benchmark for GPLPV (or even without) for a few
reasons. If you want to get decent performance out of XP, disable the
firewall service (in services, not just in the network control panel)
and append " /PATCHTPR" to the boot.ini entry if using GPLPV. The
problem with XP is that it makes _very_ frequent calls to change and
read the TPR (Task PRiority) register, which incurs quite a bit of
overhead. "/PATCHTPR" avoids that completely on AMD hardware and
optimises the read case on Intel hardware, although I think Intel under
Xen may not suffer so badly these days.

I''m seeing a few gigabits per second when doing DomU<->Dom0
testing, and
full hardware speeds when talking over a physical network adapter when I
last tested.

James


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

On Thursday, March 03, 2011 05:57:21 pm you wrote:
> > This concerns an old problem
> 
> http://lists.xensource.com/archives/html/xen-users/2010-08/msg00567.html
> 
> > Still having the problem with network performance but need to really
> 
> fix it.
> 
> > Just did a test with 32 bit xp with 0.11.0.238 drive.
> > it show device as Xen Net device driver.
> > 
> > Iperf gives 14.7 Mbits/sec
> > 
> > Running an xp live boot cd  get 13.6 Mbits/sec
> > Doesn''t looks like the the pv driver is doing anything to
help the
> 
> network as
> 
> > there is probably extra load with no pv drivers for disk and display.
> > 
> > How much of a speed improvement are others seeing?
> > 
> > The real issue is speed for samba shares.
> > 
> > I have tried on other hardware and it''s a bit faster but not
that
> 
> impressive.
> 
> > To keep the speed in perspective this is /proc/cpuinfo
> 
> XP is probably a poor benchmark for GPLPV (or even without) for a few
> reasons. If you want to get decent performance out of XP, disable the
> firewall service (in services, not just in the network control panel)
> and append " /PATCHTPR" to the boot.ini entry if using GPLPV. The
> problem with XP is that it makes _very_ frequent calls to change and
> read the TPR (Task PRiority) register, which incurs quite a bit of
> overhead. "/PATCHTPR" avoids that completely on AMD hardware and
> optimises the read case on Intel hardware, although I think Intel under
> Xen may not suffer so badly these days.
> 
> I''m seeing a few gigabits per second when doing DomU<->Dom0
testing, and
> full hardware speeds when talking over a physical network adapter when I
> last tested.
> 
> James

Looks like I already had /PATCHTPR although in lower case. I changed to upper 
case.   Turning off the firewall helped a little. Now up to 17 Mbit/sec.
This is an older intel server may that be the issue?

I''ll try the same on a amd server tomorrow.

I''m thinking of running server 2008 on this intel server, is that
likely to
work much better?

I have a couple windows applications that we must run that do not deal well 
with a multiuser environment.  I''d prefer to use xp but suppose could
run
windows7 if that will help but will need a lot of extra ram.

John

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

On 3/3/2011 2:59 PM, John McMonagle wrote:
> This concerns an old problem
> http://lists.xensource.com/archives/html/xen-users/2010-08/msg00567.html
Have you tried changing the MAC address on the virtual network 
interfaces for these slow domains? I had one customer who was seeing 
only 10 Mbps, and adjusting the MAC address to anything else fixed it. I 
still do not know why that was the case, but some limitation in Xen or a 
driver seemed to have been at play.

-John

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

> 
> On 3/3/2011 2:59 PM, John McMonagle wrote:
> > This concerns an old problem
> >
http://lists.xensource.com/archives/html/xen-users/2010-08/msg00567.html
> 
> Have you tried changing the MAC address on the virtual network
> interfaces for these slow domains? I had one customer who was seeing
> only 10 Mbps, and adjusting the MAC address to anything else fixed it.
I
> still do not know why that was the case, but some limitation in Xen or
a
> driver seemed to have been at play.
> 
This could happen if the user thought they could make up any random MAC
address. Certain bits in the MAC address indicate multicast and
broadcast address types, and setting one of those could have nasty
consequences for the whole network.

Using a duplicate MAC address would also cause problems, although it
would be unusual for it to just slow things down.

There is nothing else about a MAC address that should make any
difference though.

James

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

On 3/3/2011 10:49 PM, James Harper wrote:
>> Have you tried changing the MAC address on the virtual network
>> >  interfaces for these slow domains? I had one customer who was
seeing
>> >  only 10 Mbps, and adjusting the MAC address to anything else
fixed
>> it.
> I
>> >  still do not know why that was the case, but some limitation in 
>> Xen or
> a
>> >  driver seemed to have been at play.
>> > 
> This could happen if the user thought they could make up any random MAC
> address. Certain bits in the MAC address indicate multicast and
> broadcast address types, and setting one of those could have nasty
> consequences for the whole network.
The MAC in question started with the QEMU first bytes. It looked 
something like this, but with a different last three bytes:

52:54:00:68:0C:E5

Would anything in those last three bytes cause an issue?

Since then, I have switched to using Xen MACs (starting with 00:16:3E), 
though I don''t know if this will matter.

-John


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

> 
> The MAC in question started with the QEMU first bytes. It looked
something
> like this, but with a different last three bytes:
> 
> 52:54:00:68:0C:E5
> 
> Would anything in those last three bytes cause an issue?
> 
> Since then, I have switched to using Xen MACs (starting with
00:16:3E), though
> I don''t know if this will matter.
> 
The bits that matter are the lower 2 bits of the first byte. Bit 0
indicates a unicast (0) or multicast (1) address. Bit 1 indicates a
globally unique (0) or a locally administered (1) address. Your value of
52 is a unicast locally administered address, and appears fine. Your
00:16:3E address is also okay, but if it''s an address you are making up
and controlling yourself you might want to set the locally administered
bit.

Wikipedia is probably a good starting point -
http://en.wikipedia.org/wiki/Mac_address

James

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

> XP is probably a poor benchmark for GPLPV (or even without) for a few
> reasons. If you want to get decent performance out of XP, disable the
> firewall service (in services, not just in the network control panel)
> and append " /PATCHTPR" to the boot.ini entry if using GPLPV. The
> problem with XP is that it makes _very_ frequent calls to change and
> read the TPR (Task PRiority) register, which incurs quite a bit of
> overhead. "/PATCHTPR" avoids that completely on AMD hardware and
> optimises the read case on Intel hardware, although I think Intel under
> Xen may not suffer so badly these days.
> 
> I''m seeing a few gigabits per second when doing DomU<->Dom0
testing, and
> full hardware speeds when talking over a physical network adapter when I
> last tested.
> 
> James
> 
> 
James,
Is there anything in Server 2008 like PATCHTPR that needs to be enabled,
or does Server 2008 already work okay?  How about Server 2003, as its
pretty much the same code base as XP?

Also, I still have to disable checksum offloading and large send
offloading in the GPLPV drivers to get decent performance - leaving
these enabled yields very, very slow network performance on my Xen
boxes, and disabling them shows a drastic improvement in network
transfer rates.  not sure if this is a Xen version issue, but I''ve seen
it in Xen versions from 3.2.3 (SLES10) to 4.0.1 (OpenSuSE).  My physical
network cards have these features enabled, which really, really helps,
but I seem to need to disable them in the domUs.

-Nick



--------
This e-mail may contain confidential and privileged material for the sole use of
the intended recipient.  If this email is not intended for you, or you are not
responsible for the delivery of this message to the intended recipient, please
note that this message may contain SEAKR Engineering (SEAKR)
Privileged/Proprietary Information.  In such a case, you are strictly prohibited
from downloading, photocopying, distributing or otherwise using this message,
its contents or attachments in any way.  If you have received this message in
error, please notify us immediately by replying to this e-mail and delete the
message from your mailbox.  Information contained in this message that does not
relate to the business of SEAKR is neither endorsed by nor attributable to
SEAKR.

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

On Thursday 03 March 2011 09:13:39 pm John McMonagle
wrote:
> On Thursday, March 03, 2011 05:57:21 pm you wrote:
> > > This concerns an old problem
> >
> >
http://lists.xensource.com/archives/html/xen-users/2010-08/msg00567.html
> >
> > > Still having the problem with network performance but need to
really
> >
> > fix it.
> >
> > > Just did a test with 32 bit xp with 0.11.0.238 drive.
> > > it show device as Xen Net device driver.
> > >
> > > Iperf gives 14.7 Mbits/sec
> > >
> > > Running an xp live boot cd  get 13.6 Mbits/sec
> > > Doesn''t looks like the the pv driver is doing anything
to help the
> >
> > network as
> >
> > > there is probably extra load with no pv drivers for disk and
display.
> > >
> > > How much of a speed improvement are others seeing?
> > >
> > > The real issue is speed for samba shares.
> > >
> > > I have tried on other hardware and it''s a bit faster but
not that
> >
> > impressive.
> >
> > > To keep the speed in perspective this is /proc/cpuinfo
> >
> > XP is probably a poor benchmark for GPLPV (or even without) for a few
> > reasons. If you want to get decent performance out of XP, disable the
> > firewall service (in services, not just in the network control panel)
> > and append " /PATCHTPR" to the boot.ini entry if using
GPLPV. The
> > problem with XP is that it makes _very_ frequent calls to change and
> > read the TPR (Task PRiority) register, which incurs quite a bit of
> > overhead. "/PATCHTPR" avoids that completely on AMD hardware
and
> > optimises the read case on Intel hardware, although I think Intel
under
> > Xen may not suffer so badly these days.
> >
> > I''m seeing a few gigabits per second when doing
DomU<->Dom0 testing, and
> > full hardware speeds when talking over a physical network adapter when
I
> > last tested.
> >
> > James
>
> Looks like I already had /PATCHTPR although in lower case. I changed to
> upper case.   Turning off the firewall helped a little. Now up to 17
> Mbit/sec. This is an older intel server may that be the issue?
>
> I''ll try the same on a amd server tomorrow.
>
> I''m thinking of running server 2008 on this intel server, is that
likely to
> work much better?
>
> I have a couple windows applications that we must run that do not deal well
> with a multiuser environment.  I''d prefer to use xp but suppose
could run
> windows7 if that will help but will need a lot of extra ram.
>
> John
I tried on a AMD server  and it was about the same percentage improvement.
The only thing that had any noticeable affect was stopping the windows 
firewall.
Had no change with  /PATCHTPR or  disable checksum offloading and large send
offloading.

The application seemed a bit more responsive I''ll see what the users
say.

I''ll try to install server 2008 next week and see what happens with
that.
Any one know any tricks to get single user Windows apps to behave in a multi 
user environment?

John


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

> 
> James,
> Is there anything in Server 2008 like PATCHTPR that needs to be
enabled,
> or does Server 2008 already work okay?  How about Server 2003, as its
> pretty much the same code base as XP?
Server 2003 sp2 (or was it sp1?) removed the TPR instructions from the
kernel and did things a slightly different way so it''s not necessary
there.
> Also, I still have to disable checksum offloading and large send
> offloading in the GPLPV drivers to get decent performance - leaving
> these enabled yields very, very slow network performance on my Xen
> boxes, and disabling them shows a drastic improvement in network
> transfer rates.  not sure if this is a Xen version issue, but I''ve
seen
> it in Xen versions from 3.2.3 (SLES10) to 4.0.1 (OpenSuSE).  My
physical
> network cards have these features enabled, which really, really helps,
> but I seem to need to disable them in the domUs.
> 
Slow performance to where? DomU<->Dom0, DomU<->DomU, or
DomU<->physical
network, or all of them?

James

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

> Server 2003 sp2 (or was it sp1?) removed the TPR instructions from the
> kernel and did things a slightly different way so it''s not
necessary
> there.
> 
Ah, okay.
> Slow performance to where? DomU<->Dom0, DomU<->DomU, or
DomU<->physical
> network, or all of them?
> 
All of the above - it actually ends up generating invalid checksums on
the packets.



--------
This e-mail may contain confidential and privileged material for the sole use of
the intended recipient.  If this email is not intended for you, or you are not
responsible for the delivery of this message to the intended recipient, please
note that this message may contain SEAKR Engineering (SEAKR)
Privileged/Proprietary Information.  In such a case, you are strictly prohibited
from downloading, photocopying, distributing or otherwise using this message,
its contents or attachments in any way.  If you have received this message in
error, please notify us immediately by replying to this e-mail and delete the
message from your mailbox.  Information contained in this message that does not
relate to the business of SEAKR is neither endorsed by nor attributable to
SEAKR.

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

> 
> > Server 2003 sp2 (or was it sp1?) removed the TPR instructions from
the
> > kernel and did things a slightly different way so it''s not
necessary
> > there.
> >
> 
> Ah, okay.
> 
> > Slow performance to where? DomU<->Dom0, DomU<->DomU, or
DomU<->physical
> > network, or all of them?
> >
> 
> All of the above - it actually ends up generating invalid checksums on
> the packets.
> 
The point of the offloading in DomU is that no checksum generation is
necessary, so the checksums will always be invalid while the packets
exist on the bridge. If the packet is sent to another DomU that supports
checksum offload then Dom0 will leave the checksum invalid and pass a
flag with the packet to say that the packet is checked and so looking at
the checksum is unnecessary. If the packet is sent to a DomU that
doesn''t support offload then Dom0 will just calculate the checksum. If
the packet hits a physical network adapter then the hardware will
calculate the checksum or if the hardware doesn''t support it then Dom0
will calculate it.

That''s the way it''s supposed to work. I have seen problem
where:

. The packet is routed onto a GRE tunnel. This was a while back (~2.6.18
I think) and erratic... it would work fine for a week then suddenly
start spitting out bad packets onto the GRE tunnel. 

. The packet is bridged onto a VLAN on a physical network adapter. Some
network adapters support checksum offload but only for the untagged vlan
1. Linux seems to not handle this correctly for some (all?) such
adapters so the checksum is never calculated. Same for large send
offload. Again, I only saw this on older kernels but in that case the
offload has not been turned on again for newer kernels as the
performance isn''t required (routing out to WAN connections etc).

And I''m sure there are more cases where it is a problem.

But when it''s all working properly, seeing packets on your bridge with
invalid checksums is expected.

James


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

> > 
> 
> The point of the offloading in DomU is that no checksum generation is
> necessary, so the checksums will always be invalid while the packets
> exist on the bridge. If the packet is sent to another DomU that supports
> checksum offload then Dom0 will leave the checksum invalid and pass a
> flag with the packet to say that the packet is checked and so looking at
> the checksum is unnecessary. If the packet is sent to a DomU that
> doesn''t support offload then Dom0 will just calculate the
checksum. If
> the packet hits a physical network adapter then the hardware will
> calculate the checksum or if the hardware doesn''t support it then
Dom0
> will calculate it.
Right, understood, but I tend to see bad checksums on packets when they
reach the destination (or are on the wire, via a Network TAP), and not
just on the local bridge.
> 
> That''s the way it''s supposed to work. I have seen problem
where:
> 
> . The packet is routed onto a GRE tunnel. This was a while back (~2.6.18
> I think) and erratic... it would work fine for a week then suddenly
> start spitting out bad packets onto the GRE tunnel. 
> 
> . The packet is bridged onto a VLAN on a physical network adapter. Some
> network adapters support checksum offload but only for the untagged vlan
> 1. Linux seems to not handle this correctly for some (all?) such
> adapters so the checksum is never calculated. Same for large send
> offload. Again, I only saw this on older kernels but in that case the
> offload has not been turned on again for newer kernels as the
> performance isn''t required (routing out to WAN connections etc).
This definitely describes one of my scenarios - on my production systems
(SLES10 and SLES11) I frequently tag VLANs on a single physical
interface.  However, I also see the problem on some of my Desktop Xen
systems where I''m running Xen + openSuSE 11.3 + Windows XP VM, with a
single bridge that does not use VLANs.

I''ll have to do some more checking and make sure I work through all of
the scenarios...

-Nick



--------
This e-mail may contain confidential and privileged material for the sole use of
the intended recipient.  If this email is not intended for you, or you are not
responsible for the delivery of this message to the intended recipient, please
note that this message may contain SEAKR Engineering (SEAKR)
Privileged/Proprietary Information.  In such a case, you are strictly prohibited
from downloading, photocopying, distributing or otherwise using this message,
its contents or attachments in any way.  If you have received this message in
error, please notify us immediately by replying to this e-mail and delete the
message from your mailbox.  Information contained in this message that does not
relate to the business of SEAKR is neither endorsed by nor attributable to
SEAKR.

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

> >
> > The point of the offloading in DomU is that no checksum generation
is
> > necessary, so the checksums will always be invalid while the packets
> > exist on the bridge. If the packet is sent to another DomU that
supports
> > checksum offload then Dom0 will leave the checksum invalid and pass
a
> > flag with the packet to say that the packet is checked and so
looking at
> > the checksum is unnecessary. If the packet is sent to a DomU that
> > doesn''t support offload then Dom0 will just calculate the
checksum.
If
> > the packet hits a physical network adapter then the hardware will
> > calculate the checksum or if the hardware doesn''t support it
then
Dom0
> > will calculate it.
> 
> Right, understood, but I tend to see bad checksums on packets when
they
> reach the destination (or are on the wire, via a Network TAP), and not
> just on the local bridge.
> 
I guess the important distinction then is do you see the same problems
with Linux DomU''s with checksum offload too, or is it just GPLPV? If
it''s just GPLPV then obviously the problem is mine :)

James

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

> I guess the important distinction then is do you see the same problems
> with Linux DomU''s with checksum offload too, or is it just GPLPV?
If
> it''s just GPLPV then obviously the problem is mine :)
> 
> James
A very small number of Linux kernels exhibit the same issue with
checksums, but, by and large, it''s just the GPLPV drivers.



--------
This e-mail may contain confidential and privileged material for the sole use of
the intended recipient.  If this email is not intended for you, or you are not
responsible for the delivery of this message to the intended recipient, please
note that this message may contain SEAKR Engineering (SEAKR)
Privileged/Proprietary Information.  In such a case, you are strictly prohibited
from downloading, photocopying, distributing or otherwise using this message,
its contents or attachments in any way.  If you have received this message in
error, please notify us immediately by replying to this e-mail and delete the
message from your mailbox.  Information contained in this message that does not
relate to the business of SEAKR is neither endorsed by nor attributable to
SEAKR.

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

On Friday, March 04, 2011 02:32:25 pm John McMonagle
wrote:
> On Thursday 03 March 2011 09:13:39 pm John McMonagle wrote:
> > On Thursday, March 03, 2011 05:57:21 pm you wrote:
> > > > Just did a test with 32 bit xp with 0.11.0.238 drive.
> > > > it show device as Xen Net device driver.
> > > > 
> > > > Iperf gives 14.7 Mbits/sec
> > > > 
> > > > Running an xp live boot cd  get 13.6 Mbits/sec
> > > > Doesn''t looks like the the pv driver is doing
anything to help the
> 
> I tried on a AMD server  and it was about the same percentage improvement.
> The only thing that had any noticeable affect was stopping the windows
> firewall.
> Had no change with  /PATCHTPR or  disable checksum offloading and large
> send offloading.
> 
> The application seemed a bit more responsive I''ll see what the
users say.
> 
> I''ll try to install server 2008 next week and see what happens
with that.
> Any one know any tricks to get single user Windows apps to behave in a
> multi user environment?
> 
> John
> 
I finally did an install of server 2008 on the same xen dom0.
Before installing pv drivers get 43 Mbit/sec.
better than double xp.

With pv driver 328 Mbit/sec.
Not spectacular but usable.

Then I installed Synaptic Endpoint Protection.
That brought me back to 162 Mbit/sec.

Any suggestions?

John



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

Guess I''m mostly used to linux.
iperf is a very simple tests and doesn''t take good of hardware to get
close to
1gbits/sec with gbit  ethernet.

This machine will primarily do terminal services. it will access some files on 
Linux server. 
We are a linux shop and that allows us to run some widows apps while keeping 
all the users on linux terminals.

Did a test of the current server 2003 real server and it''s getting 230
Mbits
/second.
Odds are the 160Mbits/second with SEP running will be Ok but I''d like
to do
better.
Watching Resource monitor in server 2008 cpu goes to 100% while running tests.
Dom0 stays at 0%.

Ran into another strange thing.
I tried changing vcpus  from  from 2 to 4.
my networks speed dropped to 74 Mbits/s

If I revert back to 2 it comes back to 160.
What can cause that?
I have not activate yet in case that matters.

John



On Wednesday, March 09, 2011 10:37:25 am Dustin Henning
wrote:
> 1) SEP adds a network layer, it is going to slow you down, this is going to
> be amplified HVM processor virtualization.
> 2) You''re calling 318 Mbit/sec "usable" on Windows? 
Really?  That''s
> impressive on Windows unless you have a 10 Gbit NIC.
> The only suggestion I would have for your scenario is don''t
virtualize.
> I''m sure that''s not what you want to hear, but I think
you''re asking too
> much. Dustin
> 
> -----Original Message-----
> From: xen-users-bounces@lists.xensource.com
> [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of John McMonagle
> Sent: Wednesday, March 09, 2011 11:30
> To: xen-users@lists.xensource.com
> Subject: Re: [Xen-users] Slow windows network with gplpv driver.
> 
> On Friday, March 04, 2011 02:32:25 pm John McMonagle wrote:
> > On Thursday 03 March 2011 09:13:39 pm John McMonagle wrote:
> > > On Thursday, March 03, 2011 05:57:21 pm you wrote:
> > > > > Just did a test with 32 bit xp with 0.11.0.238 drive.
> > > > > it show device as Xen Net device driver.
> > > > > 
> > > > > Iperf gives 14.7 Mbits/sec
> > > > > 
> > > > > Running an xp live boot cd  get 13.6 Mbits/sec
> > > > > Doesn''t looks like the the pv driver is doing
anything to help the
> > 
> > I tried on a AMD server  and it was about the same percentage
> > improvement. The only thing that had any noticeable affect was
stopping
> > the windows firewall.
> > Had no change with  /PATCHTPR or  disable checksum offloading and
large
> > send offloading.
> > 
> > The application seemed a bit more responsive I''ll see what
the users say.
> > 
> > I''ll try to install server 2008 next week and see what
happens with that.
> > Any one know any tricks to get single user Windows apps to behave in a
> > multi user environment?
> > 
> > John
> 
> I finally did an install of server 2008 on the same xen dom0.
> Before installing pv drivers get 43 Mbit/sec.
> better than double xp.
> 
> With pv driver 328 Mbit/sec.
> Not spectacular but usable.
> 
> Then I installed Synaptic Endpoint Protection.
> That brought me back to 162 Mbit/sec.
> 
> Any suggestions?
> 
> John
> 
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

John,
	I am running an 0.9.x version of GPLPV, so forgive me if I am not up
to date on this, but in that version, having more than 1 core significantly
slowed down WindowsXP.  If this is still the case, and if it transfers to
Server 2003, then you might find better performance with 1 core, and if it
shouldn''t still be true, then you might have found a new problem with
the
GPLPV driver.  Another possibility is that the additional virtual cores are
being pinned to hyperthreads instead of real cores or something.  I am
making these suggestions under the assumption that you know making 4 virtual
cores on 2 real cores host would degrade performance for obvious reasons.
	Dustin

-----Original Message-----
From: John McMonagle [mailto:johnm@advocap.org] 
Sent: Wednesday, March 09, 2011 15:51
To: Dustin.Henning@prd-inc.com
Cc: xen-users@lists.xensource.com
Subject: Re: [Xen-users] Slow windows network with gplpv driver.

Guess I''m mostly used to linux.
iperf is a very simple tests and doesn''t take good of hardware to get
close
to 
1gbits/sec with gbit  ethernet.

This machine will primarily do terminal services. it will access some files
on 
Linux server. 
We are a linux shop and that allows us to run some widows apps while keeping

all the users on linux terminals.

Did a test of the current server 2003 real server and it''s getting 230
Mbits

/second.
Odds are the 160Mbits/second with SEP running will be Ok but I''d like
to do
better.
Watching Resource monitor in server 2008 cpu goes to 100% while running
tests.
Dom0 stays at 0%.

Ran into another strange thing.
I tried changing vcpus  from  from 2 to 4.
my networks speed dropped to 74 Mbits/s

If I revert back to 2 it comes back to 160.
What can cause that?
I have not activate yet in case that matters.

John



On Wednesday, March 09, 2011 10:37:25 am Dustin Henning
wrote:
> 1) SEP adds a network layer, it is going to slow you down, this is going
to
> be amplified HVM processor virtualization.
> 2) You''re calling 318 Mbit/sec "usable" on Windows? 
Really?  That''s
> impressive on Windows unless you have a 10 Gbit NIC.
> The only suggestion I would have for your scenario is don''t
virtualize.
> I''m sure that''s not what you want to hear, but I think
you''re asking too
> much. Dustin
> 
> -----Original Message-----
> From: xen-users-bounces@lists.xensource.com
> [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of John McMonagle
> Sent: Wednesday, March 09, 2011 11:30
> To: xen-users@lists.xensource.com
> Subject: Re: [Xen-users] Slow windows network with gplpv driver.
> 
> On Friday, March 04, 2011 02:32:25 pm John McMonagle wrote:
> > On Thursday 03 March 2011 09:13:39 pm John McMonagle wrote:
> > > On Thursday, March 03, 2011 05:57:21 pm you wrote:
> > > > > Just did a test with 32 bit xp with 0.11.0.238 drive.
> > > > > it show device as Xen Net device driver.
> > > > > 
> > > > > Iperf gives 14.7 Mbits/sec
> > > > > 
> > > > > Running an xp live boot cd  get 13.6 Mbits/sec
> > > > > Doesn''t looks like the the pv driver is doing
anything to help the
> > 
> > I tried on a AMD server  and it was about the same percentage
> > improvement. The only thing that had any noticeable affect was
stopping
> > the windows firewall.
> > Had no change with  /PATCHTPR or  disable checksum offloading and
large
> > send offloading.
> > 
> > The application seemed a bit more responsive I''ll see what
the users
say.
> > 
> > I''ll try to install server 2008 next week and see what
happens with
that.
> > Any one know any tricks to get single user Windows apps to behave in a
> > multi user environment?
> > 
> > John
> 
> I finally did an install of server 2008 on the same xen dom0.
> Before installing pv drivers get 43 Mbit/sec.
> better than double xp.
> 
> With pv driver 328 Mbit/sec.
> Not spectacular but usable.
> 
> Then I installed Synaptic Endpoint Protection.
> That brought me back to 162 Mbit/sec.
> 
> Any suggestions?
> 
> John
> 
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users


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

Dustin

This is 4 of 8 real cores.

I started with 2.
Like to start testing a bit underpowered to see how things work.
Is there an issue with multiple cores or changing the number of cores?

John


On Wednesday, March 09, 2011 02:58:37 pm Dustin Henning
wrote:
> John,
> 	I am running an 0.9.x version of GPLPV, so forgive me if I am not up
> to date on this, but in that version, having more than 1 core significantly
> slowed down WindowsXP.  If this is still the case, and if it transfers to
> Server 2003, then you might find better performance with 1 core, and if it
> shouldn''t still be true, then you might have found a new problem
with the
> GPLPV driver.  Another possibility is that the additional virtual cores are
> being pinned to hyperthreads instead of real cores or something.  I am
> making these suggestions under the assumption that you know making 4
> virtual cores on 2 real cores host would degrade performance for obvious
> reasons. Dustin
> 
> -----Original Message-----
> From: John McMonagle [mailto:johnm@advocap.org]
> Sent: Wednesday, March 09, 2011 15:51
> To: Dustin.Henning@prd-inc.com
> Cc: xen-users@lists.xensource.com
> Subject: Re: [Xen-users] Slow windows network with gplpv driver.
> 
> Guess I''m mostly used to linux.
> iperf is a very simple tests and doesn''t take good of hardware to
get close
> to
> 1gbits/sec with gbit  ethernet.
> 
> This machine will primarily do terminal services. it will access some files
> on
> Linux server.
> We are a linux shop and that allows us to run some widows apps while
> keeping
> 
> all the users on linux terminals.
> 
> Did a test of the current server 2003 real server and it''s getting
230
> Mbits
> 
> /second.
> Odds are the 160Mbits/second with SEP running will be Ok but I''d
like to do
> better.
> Watching Resource monitor in server 2008 cpu goes to 100% while running
> tests.
> Dom0 stays at 0%.
> 
> Ran into another strange thing.
> I tried changing vcpus  from  from 2 to 4.
> my networks speed dropped to 74 Mbits/s
> 
> If I revert back to 2 it comes back to 160.
> What can cause that?
> I have not activate yet in case that matters.
> 
> John
> 
> On Wednesday, March 09, 2011 10:37:25 am Dustin Henning wrote:
> > 1) SEP adds a network layer, it is going to slow you down, this is
going
> 
> to
> 
> > be amplified HVM processor virtualization.
> > 2) You''re calling 318 Mbit/sec "usable" on Windows?
Really?  That''s
> > impressive on Windows unless you have a 10 Gbit NIC.
> > The only suggestion I would have for your scenario is don''t
virtualize.
> > I''m sure that''s not what you want to hear, but I
think you''re asking too
> > much. Dustin
> > 
> > -----Original Message-----
> > From: xen-users-bounces@lists.xensource.com
> > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of John
> > McMonagle Sent: Wednesday, March 09, 2011 11:30
> > To: xen-users@lists.xensource.com
> > Subject: Re: [Xen-users] Slow windows network with gplpv driver.
> > 
> > On Friday, March 04, 2011 02:32:25 pm John McMonagle wrote:
> > > On Thursday 03 March 2011 09:13:39 pm John McMonagle wrote:
> > > > On Thursday, March 03, 2011 05:57:21 pm you wrote:
> > > > > > Just did a test with 32 bit xp with 0.11.0.238
drive.
> > > > > > it show device as Xen Net device driver.
> > > > > > 
> > > > > > Iperf gives 14.7 Mbits/sec
> > > > > > 
> > > > > > Running an xp live boot cd  get 13.6 Mbits/sec
> > > > > > Doesn''t looks like the the pv driver is
doing anything to help
> > > > > > the
> > > 
> > > I tried on a AMD server  and it was about the same percentage
> > > improvement. The only thing that had any noticeable affect was
stopping
> > > the windows firewall.
> > > Had no change with  /PATCHTPR or  disable checksum offloading and
large
> > > send offloading.
> > > 
> > > The application seemed a bit more responsive I''ll see
what the users
> 
> say.
> 
> > > I''ll try to install server 2008 next week and see what
happens with
> 
> that.
> 
> > > Any one know any tricks to get single user Windows apps to behave
in a
> > > multi user environment?
> > > 
> > > John
> > 
> > I finally did an install of server 2008 on the same xen dom0.
> > Before installing pv drivers get 43 Mbit/sec.
> > better than double xp.
> > 
> > With pv driver 328 Mbit/sec.
> > Not spectacular but usable.
> > 
> > Then I installed Synaptic Endpoint Protection.
> > That brought me back to 162 Mbit/sec.
> > 
> > Any suggestions?
> > 
> > John
> > 
> > 
> > 
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xensource.com
> > http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Regarding GPLPV, I am not aware of current issues or lack thereof.
However, I shouldn''t think changing the number of cores would cause
issues
for the driver (even changing to 1 for testing, the SMP HAL is already
installed and won''t change automatically, but can run on a single core
the
same as a Linux SMP kernel).  OTOH, I can''t tell you whether or not
changing
the number of cores would affect activation, so you may want to hold off on
that.  Hopefully James Harper will be in touch with you soon on this (or
someone else if they have answers).
	Dustin

-----Original Message-----
From: John McMonagle [mailto:johnm@advocap.org] 
Sent: Wednesday, March 09, 2011 16:22
To: Dustin.Henning@prd-inc.com
Cc: xen-users@lists.xensource.com
Subject: Re: [Xen-users] Slow windows network with gplpv driver.

Dustin

This is 4 of 8 real cores.

I started with 2.
Like to start testing a bit underpowered to see how things work.
Is there an issue with multiple cores or changing the number of cores?

John


On Wednesday, March 09, 2011 02:58:37 pm Dustin Henning
wrote:
> John,
> 	I am running an 0.9.x version of GPLPV, so forgive me if I am not up
> to date on this, but in that version, having more than 1 core
significantly
> slowed down WindowsXP.  If this is still the case, and if it transfers to
> Server 2003, then you might find better performance with 1 core, and if it
> shouldn''t still be true, then you might have found a new problem
with the
> GPLPV driver.  Another possibility is that the additional virtual cores
are
> being pinned to hyperthreads instead of real cores or something.  I am
> making these suggestions under the assumption that you know making 4
> virtual cores on 2 real cores host would degrade performance for obvious
> reasons. Dustin
> 
> -----Original Message-----
> From: John McMonagle [mailto:johnm@advocap.org]
> Sent: Wednesday, March 09, 2011 15:51
> To: Dustin.Henning@prd-inc.com
> Cc: xen-users@lists.xensource.com
> Subject: Re: [Xen-users] Slow windows network with gplpv driver.
> 
> Guess I''m mostly used to linux.
> iperf is a very simple tests and doesn''t take good of hardware to
get
close
> to
> 1gbits/sec with gbit  ethernet.
> 
> This machine will primarily do terminal services. it will access some
files
> on
> Linux server.
> We are a linux shop and that allows us to run some widows apps while
> keeping
> 
> all the users on linux terminals.
> 
> Did a test of the current server 2003 real server and it''s getting
230
> Mbits
> 
> /second.
> Odds are the 160Mbits/second with SEP running will be Ok but I''d
like to
do
> better.
> Watching Resource monitor in server 2008 cpu goes to 100% while running
> tests.
> Dom0 stays at 0%.
> 
> Ran into another strange thing.
> I tried changing vcpus  from  from 2 to 4.
> my networks speed dropped to 74 Mbits/s
> 
> If I revert back to 2 it comes back to 160.
> What can cause that?
> I have not activate yet in case that matters.
> 
> John
> 
> On Wednesday, March 09, 2011 10:37:25 am Dustin Henning wrote:
> > 1) SEP adds a network layer, it is going to slow you down, this is
going
> 
> to
> 
> > be amplified HVM processor virtualization.
> > 2) You''re calling 318 Mbit/sec "usable" on Windows?
Really?  That''s
> > impressive on Windows unless you have a 10 Gbit NIC.
> > The only suggestion I would have for your scenario is don''t
virtualize.
> > I''m sure that''s not what you want to hear, but I
think you''re asking too
> > much. Dustin
> > 
> > -----Original Message-----
> > From: xen-users-bounces@lists.xensource.com
> > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of John
> > McMonagle Sent: Wednesday, March 09, 2011 11:30
> > To: xen-users@lists.xensource.com
> > Subject: Re: [Xen-users] Slow windows network with gplpv driver.
> > 
> > On Friday, March 04, 2011 02:32:25 pm John McMonagle wrote:
> > > On Thursday 03 March 2011 09:13:39 pm John McMonagle wrote:
> > > > On Thursday, March 03, 2011 05:57:21 pm you wrote:
> > > > > > Just did a test with 32 bit xp with 0.11.0.238
drive.
> > > > > > it show device as Xen Net device driver.
> > > > > > 
> > > > > > Iperf gives 14.7 Mbits/sec
> > > > > > 
> > > > > > Running an xp live boot cd  get 13.6 Mbits/sec
> > > > > > Doesn''t looks like the the pv driver is
doing anything to help
> > > > > > the
> > > 
> > > I tried on a AMD server  and it was about the same percentage
> > > improvement. The only thing that had any noticeable affect was
stopping
> > > the windows firewall.
> > > Had no change with  /PATCHTPR or  disable checksum offloading and
large
> > > send offloading.
> > > 
> > > The application seemed a bit more responsive I''ll see
what the users
> 
> say.
> 
> > > I''ll try to install server 2008 next week and see what
happens with
> 
> that.
> 
> > > Any one know any tricks to get single user Windows apps to behave
in a
> > > multi user environment?
> > > 
> > > John
> > 
> > I finally did an install of server 2008 on the same xen dom0.
> > Before installing pv drivers get 43 Mbit/sec.
> > better than double xp.
> > 
> > With pv driver 328 Mbit/sec.
> > Not spectacular but usable.
> > 
> > Then I installed Synaptic Endpoint Protection.
> > That brought me back to 162 Mbit/sec.
> > 
> > Any suggestions?
> > 
> > John
> > 
> > 
> > 
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xensource.com
> > http://lists.xensource.com/xen-users


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

I think I have at have  figured out this issue.

The main problem was using Symantic sep.
Under XP removing sep and disabling windows firewall speed up by a factor of 
about 8.  Doing just one or the other had little affect.

Under server server 2003 or 2008 speed went up by a factor of about 2 - 3.

Anyone have any recommendations  on antivirus for server 2003 and 2008 or a 
link to some competent unbiased tests?

I mostly do linux and deal with windows that much.  
Thanks for all the help.

John


On Wednesday 09 March 2011 03:21:47 pm John McMonagle
wrote:
> Dustin
>
> This is 4 of 8 real cores.
>
> I started with 2.
> Like to start testing a bit underpowered to see how things work.
> Is there an issue with multiple cores or changing the number of cores?
>
> John
>
> On Wednesday, March 09, 2011 02:58:37 pm Dustin Henning wrote:
> > John,
> > 	I am running an 0.9.x version of GPLPV, so forgive me if I am not up
> > to date on this, but in that version, having more than 1 core
> > significantly slowed down WindowsXP.  If this is still the case, and
if
> > it transfers to Server 2003, then you might find better performance
with
> > 1 core, and if it shouldn''t still be true, then you might
have found a
> > new problem with the GPLPV driver.  Another possibility is that the
> > additional virtual cores are being pinned to hyperthreads instead of
real
> > cores or something.  I am making these suggestions under the
assumption
> > that you know making 4 virtual cores on 2 real cores host would
degrade
> > performance for obvious reasons. Dustin
> >
> > -----Original Message-----
> > From: John McMonagle [mailto:johnm@advocap.org]
> > Sent: Wednesday, March 09, 2011 15:51
> > To: Dustin.Henning@prd-inc.com
> > Cc: xen-users@lists.xensource.com
> > Subject: Re: [Xen-users] Slow windows network with gplpv driver.
> >
> > Guess I''m mostly used to linux.
> > iperf is a very simple tests and doesn''t take good of
hardware to get
> > close to
> > 1gbits/sec with gbit  ethernet.
> >
> > This machine will primarily do terminal services. it will access some
> > files on
> > Linux server.
> > We are a linux shop and that allows us to run some widows apps while
> > keeping
> >
> > all the users on linux terminals.
> >
> > Did a test of the current server 2003 real server and it''s
getting 230
> > Mbits
> >
> > /second.
> > Odds are the 160Mbits/second with SEP running will be Ok but
I''d like to
> > do better.
> > Watching Resource monitor in server 2008 cpu goes to 100% while
running
> > tests.
> > Dom0 stays at 0%.
> >
> > Ran into another strange thing.
> > I tried changing vcpus  from  from 2 to 4.
> > my networks speed dropped to 74 Mbits/s
> >
> > If I revert back to 2 it comes back to 160.
> > What can cause that?
> > I have not activate yet in case that matters.
> >
> > John
> >
> > On Wednesday, March 09, 2011 10:37:25 am Dustin Henning wrote:
> > > 1) SEP adds a network layer, it is going to slow you down, this
is
> > > going
> >
> > to
> >
> > > be amplified HVM processor virtualization.
> > > 2) You''re calling 318 Mbit/sec "usable" on
Windows?  Really?  That''s
> > > impressive on Windows unless you have a 10 Gbit NIC.
> > > The only suggestion I would have for your scenario is
don''t virtualize.
> > > I''m sure that''s not what you want to hear, but
I think you''re asking
> > > too much. Dustin
> > >
> > > -----Original Message-----
> > > From: xen-users-bounces@lists.xensource.com
> > > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of John
> > > McMonagle Sent: Wednesday, March 09, 2011 11:30
> > > To: xen-users@lists.xensource.com
> > > Subject: Re: [Xen-users] Slow windows network with gplpv driver.
> > >
> > > On Friday, March 04, 2011 02:32:25 pm John McMonagle wrote:
> > > > On Thursday 03 March 2011 09:13:39 pm John McMonagle wrote:
> > > > > On Thursday, March 03, 2011 05:57:21 pm you wrote:
> > > > > > > Just did a test with 32 bit xp with
0.11.0.238 drive.
> > > > > > > it show device as Xen Net device driver.
> > > > > > >
> > > > > > > Iperf gives 14.7 Mbits/sec
> > > > > > >
> > > > > > > Running an xp live boot cd  get 13.6
Mbits/sec
> > > > > > > Doesn''t looks like the the pv driver
is doing anything to help
> > > > > > > the
> > > >
> > > > I tried on a AMD server  and it was about the same
percentage
> > > > improvement. The only thing that had any noticeable affect
was
> > > > stopping the windows firewall.
> > > > Had no change with  /PATCHTPR or  disable checksum
offloading and
> > > > large send offloading.
> > > >
> > > > The application seemed a bit more responsive I''ll
see what the users
> >
> > say.
> >
> > > > I''ll try to install server 2008 next week and see
what happens with
> >
> > that.
> >
> > > > Any one know any tricks to get single user Windows apps to
behave in
> > > > a multi user environment?
> > > >
> > > > John
> > >
> > > I finally did an install of server 2008 on the same xen dom0.
> > > Before installing pv drivers get 43 Mbit/sec.
> > > better than double xp.
> > >
> > > With pv driver 328 Mbit/sec.
> > > Not spectacular but usable.
> > >
> > > Then I installed Synaptic Endpoint Protection.
> > > That brought me back to 162 Mbit/sec.
> > >
> > > Any suggestions?
> > >
> > > John
> > >
> > >
> > >
> > > _______________________________________________
> > > Xen-users mailing list
> > > Xen-users@lists.xensource.com
> > > http://lists.xensource.com/xen-users
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users

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

SEP uses a crappy network driver (I can''t remember what it''s
called,
but you''re lucky it uninstalled properly, I had fits getting it off of
some
of our real machines).  Any AV that doesn''t include firewall
shouldn''t cause
this problem, and it''s hard telling whether there is any AV that does
firewall and wouldn''t.  The latter seems unlikely, though, if even the
Windows firewall is causing it.
	Dustin

-----Original Message-----
From: xen-users-bounces@lists.xensource.com
[mailto:xen-users-bounces@lists.xensource.com] On Behalf Of John McMonagle
Sent: Monday, April 04, 2011 17:22
To: xen-users@lists.xensource.com
Cc: Dustin.Henning@prd-inc.com
Subject: Re: [Xen-users] Slow windows network with gplpv driver.

I think I have at have  figured out this issue.

The main problem was using Symantic sep.
Under XP removing sep and disabling windows firewall speed up by a factor of

about 8.  Doing just one or the other had little affect.

Under server server 2003 or 2008 speed went up by a factor of about 2 - 3.

Anyone have any recommendations  on antivirus for server 2003 and 2008 or a 
link to some competent unbiased tests?

I mostly do linux and deal with windows that much.  
Thanks for all the help.

John


On Wednesday 09 March 2011 03:21:47 pm John McMonagle
wrote:
> Dustin
>
> This is 4 of 8 real cores.
>
> I started with 2.
> Like to start testing a bit underpowered to see how things work.
> Is there an issue with multiple cores or changing the number of cores?
>
> John
>
> On Wednesday, March 09, 2011 02:58:37 pm Dustin Henning wrote:
> > John,
> > 	I am running an 0.9.x version of GPLPV, so forgive me if I am not up
> > to date on this, but in that version, having more than 1 core
> > significantly slowed down WindowsXP.  If this is still the case, and
if
> > it transfers to Server 2003, then you might find better performance
with
> > 1 core, and if it shouldn''t still be true, then you might
have found a
> > new problem with the GPLPV driver.  Another possibility is that the
> > additional virtual cores are being pinned to hyperthreads instead of
real
> > cores or something.  I am making these suggestions under the
assumption
> > that you know making 4 virtual cores on 2 real cores host would
degrade
> > performance for obvious reasons. Dustin
> >
> > -----Original Message-----
> > From: John McMonagle [mailto:johnm@advocap.org]
> > Sent: Wednesday, March 09, 2011 15:51
> > To: Dustin.Henning@prd-inc.com
> > Cc: xen-users@lists.xensource.com
> > Subject: Re: [Xen-users] Slow windows network with gplpv driver.
> >
> > Guess I''m mostly used to linux.
> > iperf is a very simple tests and doesn''t take good of
hardware to get
> > close to
> > 1gbits/sec with gbit  ethernet.
> >
> > This machine will primarily do terminal services. it will access some
> > files on
> > Linux server.
> > We are a linux shop and that allows us to run some widows apps while
> > keeping
> >
> > all the users on linux terminals.
> >
> > Did a test of the current server 2003 real server and it''s
getting 230
> > Mbits
> >
> > /second.
> > Odds are the 160Mbits/second with SEP running will be Ok but
I''d like to
> > do better.
> > Watching Resource monitor in server 2008 cpu goes to 100% while
running
> > tests.
> > Dom0 stays at 0%.
> >
> > Ran into another strange thing.
> > I tried changing vcpus  from  from 2 to 4.
> > my networks speed dropped to 74 Mbits/s
> >
> > If I revert back to 2 it comes back to 160.
> > What can cause that?
> > I have not activate yet in case that matters.
> >
> > John
> >
> > On Wednesday, March 09, 2011 10:37:25 am Dustin Henning wrote:
> > > 1) SEP adds a network layer, it is going to slow you down, this
is
> > > going
> >
> > to
> >
> > > be amplified HVM processor virtualization.
> > > 2) You''re calling 318 Mbit/sec "usable" on
Windows?  Really?  That''s
> > > impressive on Windows unless you have a 10 Gbit NIC.
> > > The only suggestion I would have for your scenario is
don''t
virtualize.
> > > I''m sure that''s not what you want to hear, but
I think you''re asking
> > > too much. Dustin
> > >
> > > -----Original Message-----
> > > From: xen-users-bounces@lists.xensource.com
> > > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of John
> > > McMonagle Sent: Wednesday, March 09, 2011 11:30
> > > To: xen-users@lists.xensource.com
> > > Subject: Re: [Xen-users] Slow windows network with gplpv driver.
> > >
> > > On Friday, March 04, 2011 02:32:25 pm John McMonagle wrote:
> > > > On Thursday 03 March 2011 09:13:39 pm John McMonagle wrote:
> > > > > On Thursday, March 03, 2011 05:57:21 pm you wrote:
> > > > > > > Just did a test with 32 bit xp with
0.11.0.238 drive.
> > > > > > > it show device as Xen Net device driver.
> > > > > > >
> > > > > > > Iperf gives 14.7 Mbits/sec
> > > > > > >
> > > > > > > Running an xp live boot cd  get 13.6
Mbits/sec
> > > > > > > Doesn''t looks like the the pv driver
is doing anything to help
> > > > > > > the
> > > >
> > > > I tried on a AMD server  and it was about the same
percentage
> > > > improvement. The only thing that had any noticeable affect
was
> > > > stopping the windows firewall.
> > > > Had no change with  /PATCHTPR or  disable checksum
offloading and
> > > > large send offloading.
> > > >
> > > > The application seemed a bit more responsive I''ll
see what the users
> >
> > say.
> >
> > > > I''ll try to install server 2008 next week and see
what happens with
> >
> > that.
> >
> > > > Any one know any tricks to get single user Windows apps to
behave in
> > > > a multi user environment?
> > > >
> > > > John
> > >
> > > I finally did an install of server 2008 on the same xen dom0.
> > > Before installing pv drivers get 43 Mbit/sec.
> > > better than double xp.
> > >
> > > With pv driver 328 Mbit/sec.
> > > Not spectacular but usable.
> > >
> > > Then I installed Synaptic Endpoint Protection.
> > > That brought me back to 162 Mbit/sec.
> > >
> > > Any suggestions?
> > >
> > > John
> > >
> > >
> > >
> > > _______________________________________________
> > > Xen-users mailing list
> > > Xen-users@lists.xensource.com
> > > http://lists.xensource.com/xen-users
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users

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



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

Windows firewall seems to only be a problem in XP.

John


On Tuesday, April 05, 2011 07:41:06 am Dustin Henning
wrote:
> 	SEP uses a crappy network driver (I can''t remember what
it''s called,
> but you''re lucky it uninstalled properly, I had fits getting it
off of some
> of our real machines).  Any AV that doesn''t include firewall
shouldn''t
> cause this problem, and it''s hard telling whether there is any AV
that
> does firewall and wouldn''t.  The latter seems unlikely, though, if
even
> the Windows firewall is causing it.
> 	Dustin
> 
> -----Original Message-----
> From: xen-users-bounces@lists.xensource.com
> [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of John McMonagle
> Sent: Monday, April 04, 2011 17:22
> To: xen-users@lists.xensource.com
> Cc: Dustin.Henning@prd-inc.com
> Subject: Re: [Xen-users] Slow windows network with gplpv driver.
> 
> I think I have at have  figured out this issue.
> 
> The main problem was using Symantic sep.
> Under XP removing sep and disabling windows firewall speed up by a factor
> of
> 
> about 8.  Doing just one or the other had little affect.
> 
> Under server server 2003 or 2008 speed went up by a factor of about 2 - 3.
> 
> Anyone have any recommendations  on antivirus for server 2003 and 2008 or a
> link to some competent unbiased tests?
> 
> I mostly do linux and deal with windows that much.
> Thanks for all the help.
> 
> John
> 
> On Wednesday 09 March 2011 03:21:47 pm John McMonagle wrote:
> > Dustin
> > 
> > This is 4 of 8 real cores.
> > 
> > I started with 2.
> > Like to start testing a bit underpowered to see how things work.
> > Is there an issue with multiple cores or changing the number of cores?
> > 
> > John
> > 
> > On Wednesday, March 09, 2011 02:58:37 pm Dustin Henning wrote:
> > > John,
> > > 
> > > 	I am running an 0.9.x version of GPLPV, so forgive me if I am
not up
> > > 
> > > to date on this, but in that version, having more than 1 core
> > > significantly slowed down WindowsXP.  If this is still the case,
and if
> > > it transfers to Server 2003, then you might find better
performance
> > > with 1 core, and if it shouldn''t still be true, then you
might have
> > > found a new problem with the GPLPV driver.  Another possibility
is
> > > that the additional virtual cores are being pinned to
hyperthreads
> > > instead of
> 
> real
> 
> > > cores or something.  I am making these suggestions under the
assumption
> > > that you know making 4 virtual cores on 2 real cores host would
degrade
> > > performance for obvious reasons. Dustin
> > > 
> > > -----Original Message-----
> > > From: John McMonagle [mailto:johnm@advocap.org]
> > > Sent: Wednesday, March 09, 2011 15:51
> > > To: Dustin.Henning@prd-inc.com
> > > Cc: xen-users@lists.xensource.com
> > > Subject: Re: [Xen-users] Slow windows network with gplpv driver.
> > > 
> > > Guess I''m mostly used to linux.
> > > iperf is a very simple tests and doesn''t take good of
hardware to get
> > > close to
> > > 1gbits/sec with gbit  ethernet.
> > > 
> > > This machine will primarily do terminal services. it will access
some
> > > files on
> > > Linux server.
> > > We are a linux shop and that allows us to run some widows apps
while
> > > keeping
> > > 
> > > all the users on linux terminals.
> > > 
> > > Did a test of the current server 2003 real server and
it''s getting 230
> > > Mbits
> > > 
> > > /second.
> > > Odds are the 160Mbits/second with SEP running will be Ok but
I''d like
> > > to do better.
> > > Watching Resource monitor in server 2008 cpu goes to 100% while
running
> > > tests.
> > > Dom0 stays at 0%.
> > > 
> > > Ran into another strange thing.
> > > I tried changing vcpus  from  from 2 to 4.
> > > my networks speed dropped to 74 Mbits/s
> > > 
> > > If I revert back to 2 it comes back to 160.
> > > What can cause that?
> > > I have not activate yet in case that matters.
> > > 
> > > John
> > > 
> > > On Wednesday, March 09, 2011 10:37:25 am Dustin Henning wrote:
> > > > 1) SEP adds a network layer, it is going to slow you down,
this is
> > > > going
> > > 
> > > to
> > > 
> > > > be amplified HVM processor virtualization.
> > > > 2) You''re calling 318 Mbit/sec "usable"
on Windows?  Really?  That''s
> > > > impressive on Windows unless you have a 10 Gbit NIC.
> > > > The only suggestion I would have for your scenario is
don''t
> 
> virtualize.
> 
> > > > I''m sure that''s not what you want to hear,
but I think you''re asking
> > > > too much. Dustin
> > > > 
> > > > -----Original Message-----
> > > > From: xen-users-bounces@lists.xensource.com
> > > > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of
John
> > > > McMonagle Sent: Wednesday, March 09, 2011 11:30
> > > > To: xen-users@lists.xensource.com
> > > > Subject: Re: [Xen-users] Slow windows network with gplpv
driver.
> > > > 
> > > > On Friday, March 04, 2011 02:32:25 pm John McMonagle wrote:
> > > > > On Thursday 03 March 2011 09:13:39 pm John McMonagle
wrote:
> > > > > > On Thursday, March 03, 2011 05:57:21 pm you wrote:
> > > > > > > > Just did a test with 32 bit xp with
0.11.0.238 drive.
> > > > > > > > it show device as Xen Net device driver.
> > > > > > > > 
> > > > > > > > Iperf gives 14.7 Mbits/sec
> > > > > > > > 
> > > > > > > > Running an xp live boot cd  get 13.6
Mbits/sec
> > > > > > > > Doesn''t looks like the the pv
driver is doing anything to
> > > > > > > > help the
> > > > > 
> > > > > I tried on a AMD server  and it was about the same
percentage
> > > > > improvement. The only thing that had any noticeable
affect was
> > > > > stopping the windows firewall.
> > > > > Had no change with  /PATCHTPR or  disable checksum
offloading and
> > > > > large send offloading.
> > > > > 
> > > > > The application seemed a bit more responsive
I''ll see what the
> > > > > users
> > > 
> > > say.
> > > 
> > > > > I''ll try to install server 2008 next week and
see what happens with
> > > 
> > > that.
> > > 
> > > > > Any one know any tricks to get single user Windows apps
to behave
> > > > > in a multi user environment?
> > > > > 
> > > > > John
> > > > 
> > > > I finally did an install of server 2008 on the same xen
dom0.
> > > > Before installing pv drivers get 43 Mbit/sec.
> > > > better than double xp.
> > > > 
> > > > With pv driver 328 Mbit/sec.
> > > > Not spectacular but usable.
> > > > 
> > > > Then I installed Synaptic Endpoint Protection.
> > > > That brought me back to 162 Mbit/sec.
> > > > 
> > > > Any suggestions?
> > > > 
> > > > John
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Xen-users mailing list
> > > > Xen-users@lists.xensource.com
> > > > http://lists.xensource.com/xen-users
> > 
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xensource.com
> > http://lists.xensource.com/xen-users
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
> 
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users