ESXi - N40L - Slow Network Speeds


Recommended Posts

Hi Guys,

I am running 2 VMS, WHS2011 and WinXP, both have vmxnet3 drivers installed. The XP network says its running at 1.4GB/s and the WHS network is running at 10GB/s.

When I transfer files from one VM to the other i am getting speeds of 2MB/s. Why is this so slow??

I have run iperf and get speeds of 102 Mbits/sec

whilst the file transfer is in progress CPU usage is around 10% on both VM machines, but when I run iperf, CPU usage maxs out at 100% on the XP VM and about 55-65% on the WHS2011 VM.

Is the CPU being at 100% throttling the network?

I am running one physical network card,

Can anyone shed some light on this? I am a newbie to VMs but not to computers :)

thanks!

Link to comment
https://www.neowin.net/forum/topic/1128838-esxi-n40l-slow-network-speeds/
Share on other sites

Those speeds (That are reported in Windows) are for the Virtual Adapters. Although its true that transferring speeds between VM's on the same does write directly between Memory and not hit the wire so to speak. The speed will only be 1Gbps on the Physical Adapter by the way. Have you applied all the latest patches to ESXi, I would highly recommend it. My CPU usage is always really low, Infact I am surprised at how efficient it is. I just need some more memory in my baby!

http://www.vmware.com/patchmgr/findPatch.portal

SK[' timestamp=1357165637' post='595429082]

If your using the vmxnet3 driver shouldn't it be showing 10GB?

*Edit*

Just checked my XP VM out and indeed it shows 1.4GB. Never noticed that before.

102Mbit is about right for a 1GB NIC no?

It might be for XP that it shows 1.4Gbps, Don't have one to test it. I have only seen it at 10GBps. Budman could chime in though and tell us if this is the case.

Yes your right just over 100MB for 1Gbps.

So I don't have an XP vm currently - but I could fire one up for sure.

But between my nas vm and win7 vm I show this, btw 102mbps is SLOW if you showing connected at gig speeds.

C:\Windows\System32>iperf -c storage -w 256k
------------------------------------------------------------
Client connecting to storage, TCP port 5001
TCP window size:  256 KByte
------------------------------------------------------------
[276] local 192.168.1.210 port 49233 connected with 192.168.1.8 port 5001
[ ID] Interval	   Transfer	 Bandwidth
[276]  0.0-10.0 sec   599 MBytes   502 Mbits/sec

I should see if I can get that up a bit - my physical machines see much higher. 800Mbps should be seen on a gig network fairly easy.

So file copy from my nas vm to my win7 vm

post-14624-0-27431800-1357221554.png

So I am seeing 50MBytes per second in this test.

But curious to what disks your writing/reading from - are you just trying to copy a file from datastore drive of vm to another datastore drive on the other vm. My nas has raw access to the 3 drives it uses for storage. So the above tests were from one of those disks to the datastore drive of the win7 vm

Also curious --- you gave 4GB to each of your VMs, do you have more than 8 in your N40L?

So I did a test that I think more reflects what your doing more likely. And that is from datastore drive to datastore drive of each VM. And in that test I got only 23MBps

post-14624-0-56310600-1357222192.png

What else is your datastore disk doing at the time?? That performance is not going to be the best, your 2 different VMs are accessing the same physical disk. So yeah there is going to be some contention for time.

thanks, i have 10GB of memory in my N40L, an 8Gb and a 2Gb stick.

I have a drivepool in WHS, consisting of 2TB and 1.5TB WD Green drives

I am transferring files from the pool to the XP machine which has a second 2TB drive attached.

The VMs themselves were stored on the 250Gb drive, but I have moved them to another 2TB drive for now.

The ESXi is installed on a 8GB USB pen drive.

Thanks

a bit of progress maybe?

under the WHS2011 VM

If i "pull" a file from the xp machine to the WHS drivepool i get speeds of 13.5MB/s

if i "push" a file from the WHS drivepool to the xp machine i get speeds of 2MB/s

could that be a write issue with the XP HDD ? (E: 2TB)

thats still pretty crappy for a gig network. If I do a iperf or file copy to a physical machine from the vm I get this

C:\test>robocopy \\storage\media\cleanup c:\test test.mp4

-------------------------------------------------------------------------------
   ROBOCOPY	 ::	 Robust File Copy for Windows
-------------------------------------------------------------------------------

  Started : Thu Jan 03 10:31:22 2013

   Source = \\storage\media\cleanup\
	 Dest : c:\test\

	Files : test.mp4

  Options : /COPY:DAT /R:1000000 /W:30

------------------------------------------------------------------------------

						   1	\\storage\media\cleanup\
100%		New File			 650.8 m		test.mp4

------------------------------------------------------------------------------

			   Total	Copied   Skipped  Mismatch	FAILED	Extras
	Dirs :		 1		 0		 1		 0		 0		 0
   Files :		 1		 1		 0		 0		 0		 0
   Bytes :  650.86 m  650.86 m		 0		 0		 0		 0
   Times :   0:00:09   0:00:09					   0:00:00   0:00:00


   Speed :			74150984 Bytes/sec.
   Speed :			4242.953 MegaBytes/min.

   Ended : Thu Jan 03 10:31:31 2013

C:\test>iperf -c storage -w 256k
------------------------------------------------------------
Client connecting to storage, TCP port 5001
TCP window size:  256 KByte
------------------------------------------------------------
[336] local 192.168.1.100 port 16077 connected with 192.168.1.8 port 5001
[ ID] Interval	   Transfer	 Bandwidth
[336]  0.0-10.0 sec  1012 MBytes   849 Mbits/sec

Notice the 800+ Mbits per second over gig.. And in the 70MBps for file pull from my VM.

Do an iperf test from your physical to your VM, using a higher window size, say -w 256k You can see example of this test in my above output. On the server set it up with iperf -s -w 256k

Do you have 2 physical boxes we can play with - 295Mbps is that your iperf test.. That is pretty crappy for a gig network. Did you use the larger window size for your test?

at 8.59 mbps -- is that over wireless or something? Are you reading writing from a USB disk or something.. That is just horrific performance.

Damn you beat me too it! I was going to say that. How are they formatted?

I added the drives under the vclient and formatted them via windows - is that right? am a novice with ESXi

Do you have 2 physical boxes we can play with - 295Mbps is that your iperf test.. That is pretty crappy for a gig network. Did you use the larger window size for your test?

at 8.59 mbps -- is that over wireless or something? Are you reading writing from a USB disk or something.. That is just horrific performance.

yes, those figures are are with iperf on a wired Gb network

I've just performed another iperf test

physcial XP machine set as server (1Gb network) - wired

physical win7 laptop set as client (100Mb network) - wired

and i get 87Mbits/sec

the laptop has only got a 100Mb network card, so thats the max on this network - this is for this test only.

Well 87mbps on 100mbit connection is about right.. Best you could see on 100mbit is around mid 90's -- think best I have ever seen is 97 something. Never ever going to see actual speed of the connection.

But on gig you should be seeing closer to 800s vs your under 300 number.

So question for you on your VM whs - did you give whs raw access to the disks, or did you create vmfs on the disks that the OS has access to.

So for example on my storage box

post-14624-0-36278900-1357239638.jpg

Notice that the 3 disks I have given it to use in a drive pool the disks are raw mapped, and then above that you see the virtual disk (on the datastore drive) that is the vmfs for the OS installed too.

Here is a guide on how to do that

http://vm-help.com/esx40i/SATA_RDMs.php

So for example here is my maps

/vmfs/volumes/4f677e4a-81443006-5233-2c768aadf656/RDMs # ls -la

drwxr-xr-x 1 root root 1120 Dec 26 13:12 .

drwxr-xr-t 1 root root 5180 Dec 29 14:59 ..

-rw------- 1 root root 2000398934016 Apr 7 2012 rdm1-rdmp.vmdk

-rw------- 1 root root 521 Dec 26 13:12 rdm1.vmdk

-rw------- 1 root root 750156374016 Apr 16 2012 rdm2-rdmp.vmdk

-rw------- 1 root root 520 Dec 26 13:12 rdm2.vmdk

-rw------- 1 root root 750156374016 Apr 14 2012 rdm3-rdmp.vmdk

-rw------- 1 root root 520 Dec 26 13:12 rdm3.vmdk

/vmfs/volumes/4f677e4a-81443006-5233-2c768aadf656/RDMs #

So couple of things to deal with on your slow performance - why your iperf between vms is so slow. And then make sure that your drive access is as fast as it can be. How are attaching the disks to your VMs could be a limiting factor - and have to look into the speed between vms from a network as well. I do recall seeing above 1Gbps before on iperf between machines

yeah just looked up a old thread about N40L performance - and in a test there I was seeing 1.5Gbps between vms - have to take a look why only seeing 500mbps now

https://www.neowin.net/forum/topic/1071115-esxi-hp-microserver-n40l-performance/page__view__findpost__p__594826393

post-14624-0-44916300-1335455395.jpg

So I got something not quite right as well - wonder what would of changed?? I know the client is different in this test. Have to look to getting my between vms speeds back to that over 1Gbps ;)

This is a copy from A Win7 VM to my physical Desktop over a 1GB switch. The discs are thin provisioned.


-------------------------------------------------------------------------------
ROBOCOPY :: Robust File Copy for Windows
-------------------------------------------------------------------------------
Started : 04 January 2013 09:16:13
Source : VM7COMPUTER
Dest : C:\Users\Andrew\Desktop\
Files : SOME.FILE
Options : /DCOPY:DA /COPY:DAT /R:1000000 /W:30
------------------------------------------------------------------------------
1 VM7COMPUTER

100% New File 701.8 m SOME.FILE
------------------------------------------------------------------------------
Total Copied Skipped Mismatch FAILED Extras
Dirs : 1 0 0 0 0 0
Files : 1 1 0 0 0 0
Bytes : 701.88 m 701.88 m 0 0 0 0
Times : 0:00:06 0:00:06 0:00:00 0:00:00

Speed : 108010209 Bytes/sec.
Speed : 6180.393 MegaBytes/min.
Ended : 04 January 2013 09:16:20
[/CODE]

This is copying from a Win XP machine to my physical desktop over the same switch with the VM in the same datastore. Basically, there is nothing different from the above other than its a VM with XP rather than 7.

[CODE]
-------------------------------------------------------------------------------
ROBOCOPY :: Robust File Copy for Windows
-------------------------------------------------------------------------------
Started : 04 January 2013 10:10:43
Source : VMXPCOMPUTER
Dest : C:\Users\Andrew\Desktop\
Files : SOME.FILE
Options : /DCOPY:DA /COPY:DAT /R:1000000 /W:30
------------------------------------------------------------------------------
1 VMXPCOMPUTER
100% New File 851.2 m SOME.FILE
------------------------------------------------------------------------------
Total Copied Skipped Mismatch FAILED Extras
Dirs : 1 0 0 0 0 0
Files : 1 1 0 0 0 0
Bytes : 851.20 m 851.20 m 0 0 0 0
Times : 0:00:13 0:00:13 0:00:00 0:00:00

Speed : 65230532 Bytes/sec.
Speed : 3732.521 MegaBytes/min.
Ended : 04 January 2013 10:10:57
[/CODE]

XP seems to be much slower than its predecessor. I know they are slightly different file sizes but the speed speaks for itself.

TBH as I run with such a small amount of resources I would sooner use XP over 7 yet XP feels much slower than 7 does as a VM on my MicroServer. Windows 2008 R2 feels much snappier than XP does. I need to ditch my XP machine really as these tests above prove 7 is not performing how it should.

The host is a HP MicroServer (N36L so the mk1 version).

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Glow 26.10 by Razvan Serea Glow provides detailed reporting on every hardware component in your computer, saving you valuable time typically spent searching for CPU, motherboard, RAM, graphics card, and other stats. With Glow, all the information is conveniently presented in one clean interface, allowing you to easily access and review the comprehensive hardware details of your system. Glow provides detailed information on various system aspects, including OS, motherboard, processor, memory, graphics card, storage, network, battery, drivers, and services. The well-organized format ensures easy access to the required information. You can export all the gathered data to a plain text file, facilitating sharing with others for troubleshooting purposes. No installation needed. Just decompress the archive, launch the executable, and access computer-related information. Glow runs on Windows 11 and Windows 10 64-bit versions. Glow 26.10 changelog: New Features The bootstrapping algorithm has been completely redesigned. The software can now launch directly without requiring TS Preloader. As part of this change, the startup splash screen displayed during initialization has been removed. In addition, spikes in CPU usage have been eliminated, resulting in a more stable architecture with significantly lower memory consumption. The Microsoft Office detection infrastructure within the Operating System section has been enhanced. Additional detection support has been added for Office C2R (Click-to-Run) installations. Furthermore, the license status evaluation system has been improved, and the priority order has been revised as follows: Licensed > Grace Period > Other (NOTIFICATIONS, EVALUATION, etc.). Glow now includes preliminary support for Wi-Fi 8 technology, allowing more detailed information to be displayed for Wi-Fi 8-compatible network adapters. Glow now provides full support for Bluetooth 6.2. Adapters supporting Bluetooth 6.2 can be analyzed in greater detail and with improved accuracy. The disk distribution view in the Disk section has been modernized, replacing the traditional table layout with a new 2×2 card-based design. The TS Custom Controls module has been updated to v26.7. Thanks to the new custom controls, all Türkaysoft applications now offer a more modern and consistent user interface aligned with Windows 11 design standards. Bug Fixes Potential line-ending handling issues in the Office detection code within the Operating System section have been resolved. Additionally, the output format has been standardized to UTF-8 to prevent character encoding issues and ensure consistent data processing. Several stability and file management issues within the Debugging infrastructure have been addressed. Problems that prevented new log files from being created after Debugging was disabled, as well as issues causing debug records to be lost, have been fixed. File deletion and reaccess issues that occurred after file locks were released have also been resolved. In addition, a bug that caused newly recreated log files to remain locked after deletion has been eliminated. Unnecessary blank lines within debug logs and the extra empty line that could appear at the end of log files have also been corrected. A shortcut key conflict caused by assigning identical hotkeys to both the DNS Test Tool and the Donation page has been fixed. The DNS Test Tool can now be accessed using CTRL + Shift + D, while the Donation page is available via CTRL + Alt + D. Changes The service responsible for providing the Public IP Address and Internet Service Provider information in the Network section has been updated to use the ipinfo.io infrastructure. This change improves the accuracy and consistency of the displayed data. (No external requests are made while Hiding Mode is enabled.) Some terms in the Dutch and Korean language files have been updated to make them clearer and more user-friendly. [TS Updater] Before the update process begins, users are now prompted to choose whether they would like to view the release notes. Note: Always unzip the program before using it. Otherwise you may get an error. Download: Glow 26.10 | 1.8 MB (Open Source) Links: Glow Homepage | Screenshot | Github Get alerted to all of our Software updates on Twitter at @NeowinSoftware
    • Maradona if hydration breaks had existed in Mexico 86.
    • The quantum search for Time's origin had an equally mind-boggling conclusion by Sayan Sen Image by Steve Johnson via Pexels A theoretical study from researchers at the University of Surrey suggested that the direction of time may not be fundamentally fixed in certain quantum systems. The work, published in Scientific Reports, examined how the “arrow of time” could emerge from microscopic physics and found that time-reversal symmetry can remain intact even in models used to describe processes such as energy loss and thermalisation. The arrow of time refers to the observed one-way direction from past to future in everyday life. In macroscopic processes, this is easy to see. Spilled milk spreads across a table and does not gather back into a glass, and heat flows from hotter objects to colder ones. These processes shape the common sense idea that time moves in a single direction. However, at the level of fundamental physics, many equations do not prefer a direction of time. Time-reversal symmetry means that the same physical laws can describe a system whether time moves forward or backward. This has made it difficult to explain why irreversible behaviour appears in the large-scale world even when the underlying rules do not require it. Dr Andrea Rocco, Associate Professor in Physics and Mathematical Biology at the University of Surrey, described this contrast: "One way to explain this is when you look at a process like spilt milk spreading across a table, it's clear that time is moving forward. But if you were to play that in reverse, like a movie, you'd immediately know something was wrong – it would be hard to believe milk could just gather back into a glass. However, there are processes, such as the motion of a pendulum, that look just as believable in reverse. The puzzle is that, at the most fundamental level, the laws of physics resemble the pendulum; they do not account for irreversible processes. Our findings suggest that while our common experience tells us that time only moves one way, we are just unaware that the opposite direction would have been equally possible." The study focused on open quantum systems, which are quantum systems that interact with a surrounding environment. This environment, often described as a heat bath, can exchange energy and information with the system. The researchers used this framework to study how a direction of time might appear even when the underlying physics does not enforce one. A key part of the analysis involved the Markov approximation. This is a simplification used in many models where the system is assumed not to retain memory of its past states. The idea is that changes depend only on the current state, not on earlier history. This is commonly used when studying thermalisation, which is the process where a system settles into equilibrium with its environment. The study also used concepts such as master equations, including the Lindblad and Pauli equations, which describe how probabilities of different quantum states change over time. Another related model discussed was quantum Brownian motion, which describes the random-like movement of a quantum particle interacting continuously with its environment. In these descriptions, a “memory kernel” can appear, which is a mathematical term that accounts for how past states influence current behaviour. The researchers found that applying the Markov approximation did not break time-reversal symmetry. Even when the system interacted with an effectively infinite heat bath, the resulting equations of motion remained symmetric in time. This meant that the same mathematical description could, in principle, run forward or backward in time without contradiction. The study further showed that standard frameworks used in open quantum systems, including quantum Brownian motion and master equations like the Lindblad and Pauli forms, could be written in a time-symmetric way. These equations are typically used to describe processes that look irreversible, such as dissipation and thermalisation, but the results suggested they can also be interpreted as allowing evolution in both time directions. Thomas Guff, Research Fellow in Quantum Thermodynamics, said: "The surprising part of this project was that even after making the standard simplifying assumption to our equations describing open quantum systems, the equations still behaved the same way whether the system was moving forwards or backwards in time. When we carefully worked through the maths, we found that this behaviour had to be the case because a key part of the equation, the "memory kernel," is symmetrical in time. We also found a small but important detail which is usually overlooked – a time discontinuous factor emerged that kept the time-symmetry property intact. It’s unusual to see such a mathematical mechanism in a physics equation because it's not continuous, and it was very surprising to see it appear so naturally." The researchers also noted that deriving a one-way arrow of time from time-reversal symmetric microscopic dynamics remains an open problem across fields such as thermodynamics, statistical mechanics, particle physics, and cosmology. Their results suggested that some standard descriptions of irreversible behaviour in open quantum systems may be better understood using a time-symmetric formulation of Markovianity. According to the study, processes such as thermalisation, which are usually treated as irreversible, could in theory be described in a way that allows evolution in either time direction under the same rules. This does not imply that time reversal occurs in everyday life, but rather that the underlying equations do not strictly enforce a single direction. Overall, the findings suggested that the perceived direction of time may emerge from how physical systems are modelled and approximated, rather than from a fundamental asymmetry in the laws themselves. The researchers noted that this perspective could have implications for ongoing work in quantum mechanics, thermodynamics, and cosmology on the origin of time’s arrow. Source: University of Surrey, Nature This article was generated with some help from AI and reviewed by an editor. Under Section 107 of the Copyright Act 1976, this material is used for the purpose of news reporting. Fair use is a use permitted by copyright statute that might otherwise be infringing
    • A bit premature... 100% Marketing. Bizarre.
  • Recent Achievements

    • Reacting Well
      BizSAR earned a badge
      Reacting Well
    • First Post
      AndreaB earned a badge
      First Post
    • Week One Done
      Huge Trailer earned a badge
      Week One Done
    • Week One Done
      Classifyskilleducation earned a badge
      Week One Done
    • One Month Later
      eurospharma62 earned a badge
      One Month Later
  • Popular Contributors

    1. 1
      +primortal
      581
    2. 2
      +Edouard
      182
    3. 3
      PsYcHoKiLLa
      75
    4. 4
      Michael Scrip
      73
    5. 5
      neufuse
      64
  • Tell a friend

    Love Neowin? Tell a friend!