VMware Communities
alexferro
Contributor
Contributor

Low speed for a Fast Ethernet on WinXP over VMWorkstation 5.5.1

Hi,

this my configuration:

Kernel 2.4.32

ethernet NIC r8169 (10-100-1000 Fast Ethernet)

VMWare Workstation v. 5.5.1

WinXP Prof over VMWare

I probe to change the "normal" speed from 10Mbit to 100Mbit of Windows NIC interface (named AMD PCNet Family) but without success.

How can I change the speed of NIC to 100Mbit?

Thanks, Alessandro

0 Kudos
21 Replies
KevinG
Immortal
Immortal

If you install the VMware tools, the virtual network adapter should change to a VMware Accelerated AMD

0 Kudos
alexferro
Contributor
Contributor

I have installed VMware Tools for Windows Build: build-19175 but the NIC was tha same AMD PCNet Family...

Why? I have to disinstall the old one NIC and reinstall It?

Thanks

0 Kudos
KevinG
Immortal
Immortal

Post the .vmx file from the virtual machine

How did you create this VM?

0 Kudos
alexferro
Contributor
Contributor

Below the vmx:

#!/usr/bin/vmware

config.version = "7"

virtualHW.version = "3"

memsize = "512"

ide0:0.present = "TRUE"

ide0:0.fileName = "winXPPro.vmdk"

ide0:1.present = "TRUE"

ide0:1.fileName = "/dev/cdrom"

ide0:1.deviceType = "atapi-cdrom"

floppy0.fileName = "/dev/fd0"

Ethernet0.present = "TRUE"

sound.present = "FALSE"

displayName = "winXPPro"

guestOS = "winxppro"

priority.grabbed = "normal"

priority.ungrabbed = "normal"

isolation.tools.dnd.disable = "TRUE"

uuid.location = "56 4d 26 7f 90 a8 06 ba-bb e3 e7 7b d2 4a 59 96"

ethernet0.addressType = "generated"

ethernet0.generatedAddress = "00:0c:29:ad:73:7b"

ethernet0.generatedAddressOffset = "0"

tools.remindInstall = "FALSE"

ide0:1.startConnected = "TRUE"

ide0:0.writeThrough = "TRUE"

ide0:0.redo = ""

uuid.bios = "56 4d 6c ee 18 73 d9 2e-a3 0f 28 dd cf ad 73 7b"

ide0:0.deviceType = "ata-hardDisk"

usb.present = "TRUE"

tools.syncTime = "FALSE"

uuid.action = "keep"

undopoint.disableSnapshots = "TRUE"

extendedConfigFile = "winXPPro.vmxf"

0 Kudos
RDPetruska
Leadership
Leadership

This VM was created with an older version of Workstation (or maybe GSX Server). With the guest powered off, upgrade the virtual hardware (VM-->Upgrade Virtual Machine), then power the guest back on, and make sure the Tools are the latest version. You may also want to update your Workstation to the latest release, 5.5.3, and upgrade the VMware Tools at that time.

0 Kudos
KevinG
Immortal
Immortal

Hi alexferro

As Robert has pointed out... upgrade your virtual hardware and then install the VMware Tools.

I suspected that your virtual machine may be an older version. this is why I ask you to post your .vmx file

0 Kudos
dmair
Champion
Champion

I apologise if I missed a detail but, are you (the OP) only concerned about this for cosmetic reasons. The VMware NIC can't change the electrical signaling of the NIC/cabling it is attached to. If you have a guest bridged to a 1Gbps NIC then the packets are signaled at 1Gbps regardless of what the guest NIC claims it is capable of. VMware doesn't throttle network traffic to match the guest NIC's claimed capabilities (one of the VMware developers confirmed that recently). For host virtual and guest to guest virtual NICs (except for restricted team LANs) throughput should be limited only by memory and CPU bandwidth regardless of the guest NIC's claimed capabilities.

0 Kudos
Peter_vm
Immortal
Immortal

I apologise if I missed a detail but, are you (the

OP) only concerned about this for cosmetic reasons.

The VMware NIC can't change the electrical signaling

of the NIC/cabling it is attached to. If you have a

guest bridged to a 1Gbps NIC then the packets are

signaled at 1Gbps regardless of what the guest NIC

claims it is capable of. VMware doesn't throttle

network traffic to match the guest NIC's claimed

capabilities (one of the VMware developers confirmed

that recently).

Are you then saying that DOS VM should be able to utilize 1Gbps if host NIC is 1Gbps?

For host virtual and guest to guest

virtual NICs (except for restricted team LANs)

throughput should be limited only by memory and CPU

bandwidth regardless of the guest NIC's claimed

capabilities.

I don't think he had "host virtual NIC" situation.

0 Kudos
RDPetruska
Leadership
Leadership

>Are you then saying that DOS VM should be able to utilize 1Gbps if host NIC is 1Gbps?

In theory, yes. Read about the users with Win2003 guests that are shutting down the virtual NIC due to an erroneous 'recognition' of a DDOS attack, because the virtual NIC is transferring data much faster than its advertised speed.

0 Kudos
KevinG
Immortal
Immortal

Well there is some cosmetic issues.... but to take advantage of the performance gain of the Accelerated virtual network adapter.

The OP will have to upgrade the virtual hardware to be able to take advantage of the NIC morphing available with WS 5.x and use the new device driver that provides the performance gain.

0 Kudos
Peter_vm
Immortal
Immortal

>Are you then saying that DOS VM should be able to

utilize 1Gbps if host NIC is 1Gbps?

In theory, yes.

But do you have a hands on experience on that?

Read about the users with Win2003

guests that are shutting down the virtual NIC due to

an erroneous 'recognition' of a DDOS attack, because

the virtual NIC is transferring data much faster than

its advertised speed.

I don't think denial of service attack detection has anything to do with it.

0 Kudos
dmair
Champion
Champion

But do you have a hands on experience on that?

Petr's description was good enough for me. Besides, VMware can't change the electrical characteristics of the actual NIC a guest is bridged on.

I don't think denial of service attack detection has anything to do with it

I disagree, it's only an example that demonstrates the point. The OS in question ASSUMED it was experiencing a DoS because it was instrumented to compare measured throughput with the rated capabilities of the "device" that throughput was being measured on. Actual exceeded rated. That implies that the VMware NIC is subject to the limitations of the physical NIC since that's the only way you could get a quart out of a pint pot in this case.

0 Kudos
Peter_vm
Immortal
Immortal

Petr's description was good enough for me. Besides,

VMware can't change the electrical characteristics of

the actual NIC a guest is bridged on.

I don't see Petr's comments in this thread.

I'm not disputing effects on electrical characteristics of the physical NIC. I'm saying that there were (are) situations when guest cannot utilize speed of physical NIC.

I don't think denial of service attack detection

has anything to do with it

I disagree, it's only an example that demonstrates

the point. The OS in question ASSUMED it was

experiencing a DoS because it was instrumented to

compare measured throughput that exceeded the rated

capabilities of the device that throughput was being

measured on. That implies that the VMware NIC is

subject to the limitations of the physical NIC since

that's the only way you could get a quart out of a

pint pot in this case.

You may disagree, but Windows 2003 OS issue described by Robert is not related to network performance observed in DOS Virtual Machine.

0 Kudos
RDPetruska
Leadership
Leadership

>but Windows 2003 OS issue described by Robert is not related to network performance observed in DOS Virtual Machine.

Of course not. I said theoretically. And, I was stating an actual example which shows the theory in practice.

0 Kudos
dmair
Champion
Champion

I'm saying that there were (are) situations when guest cannot utilize speed of physical NIC.

That could only by the guest's own choice, i.e. throttling or inadequacy in the guest itself. The claimed speed of the VM NIC is still not to actual NIC capabilities regardless. The electrical signaling won't change no matter what VMware does. Petr's post was made in response to a similar question in a previous thread. He said categorically that VMware does not throttle guest network I/O (except for bandwidth limited team LANs).

Robert has responded on your disagreement with my disagreement with you. The point was offered only as an example to demonstrate that a guest can (will) get physical device dictated performance regardless of the performance claimed by the virtual device. This is true for any guest. A guest that chooses to control traffic to a mean rate matching the VM NIC's claimed capabilities will still see frame first to last byte times consistent with the physical NIC electrical signaling.

0 Kudos
Peter_vm
Immortal
Immortal

>but Windows 2003 OS issue described by Robert is not

related to network performance observed in DOS

Virtual Machine.

Of course not. I said theoretically. And, I was

stating an actual example which shows the theory in

practice.

I was talking about DOS VM, not Windows 2003.

0 Kudos
dmair
Champion
Champion

I'll say it again then. No guest OS has no control over the actual network signaling rate and neither does VMware. That Windows 2003 has the observed behaviour is offered as evidence of the behaviour of the VM NIC, not as evidence of the behaviour of Windows 2003. What happens to one VMware NIC happens to another VMware NIC of the same configuration. Therefore, DOS will experience packet signaling matching the physical NIC regardless of what the Virtual NIC claims and any restriction to the claimed NIC performance is a feature of DOS, not a feature of VMware.

0 Kudos
Peter_vm
Immortal
Immortal

any restriction to the claimed

NIC performance is a feature of DOS, not a feature of

VMware.

Or, more precisely, is a combination of a real hardware, VMware emulation of specific NIC card, DOS driver for that emulated NIC, DOS and DOS application.

0 Kudos
dmair
Champion
Champion

VMware emulation of specific NIC card

I disagree with that part being a significant factor and believe that it is of academic and anecdotal relevance only. VMware's responsibility ends with the Virtual NIC implementation and one of VMware's top engineers has asserted here that VMware does no bandwidth management for bridged guest NICs. Given the hardware platform when DOS drivers were being actively developed it is ludicrous to imagine that they used timing loops to manage 10Mbps traffic so I seriously doubt they restrict traffic levels to reported capabilities of the device. At that time network interfaces were only beginning to gain some consistency. However, the platform still had weak resources so I seriously doubt any network enabled applications or services invested the time to manage traffic levels with timing loops. Repeat for alternative traffic metering methods.

0 Kudos