.png "jhanekom"){kind=avatar}
Cool, those are some interesting results. I think we have pretty much ruled out network drivers as a possibility here: the chances of both e1000 and bnx2 having the exact same flaw that - apparently - only occurs on your particular machine are pretty remote.
It's time we dive a little deeper into the logs and setup. For this you'll need to get onto the console of the machine, I suspect remote administration with SSH will be your best bet. You'll need to start "Remote Tech Support" in the security profile configuration screen first, then SSH into the box using something like PuTTY. (Note: I think the default settings shuts it down again after a few minutes, which is a good thing.)
Once in the remote administration shell, run the following commands and post the results:
esxcfg-nics -l
esxcfg-scsidevs -a
esxcfg-vswitch -l
esxcfg-mpath -L (note: uppercase "L")
For ESXi: the last 20 or so lines of "grep vmkwarning /var/log/messages"
For ESX: the last 20 or so lines of /var/log/vmkwarning
Also scan through the text of "grep vmkernel /var/log/messages | less" (for ESXi, or just /var/log/vmkernel for ESX) for any messages that appear around the time that you encounter the problem. I don't think it's necessary to post 1000 lines from two weeks ago, mostly just stuff that's pertinent now. This may not necessarily be network-related, but could help identify a root cause.
Finally, if you've not done so yet - and I know this might sound silly but you've not mentioned it yet - please replace the cables and give it another go. I appreciate that the problem did not occur with Windows 7 on it, but it would make the voices stop 
Thanks for the feedback, reason I asked for the storage bits as well is that sometimes issues around the underlying storage can have a weird impact in high-load situations. At first glance, that doesn't appear to be the case here.
I'm not exactly sure when the problem occurred, but there are some potentially "interesting" "memory" events around the time the NIC is connected. From other posts these memory events are possibly processor-related, rather than memory.
Some questions:
Was the NIC physically disconnected at the times the logs indicate?
If available, at what time were you conducting the test?
You're confident that you tested on the NC382T (Broadcom) as well? I ask because I've had cases in the past where I just changed the adapter order in the vSwitch properties, and the VM would not move to the new "preferred" NIC unless I unlinked the NIC from the vSwitch or disconnected/reconnected the VM.
Having looked at the output of "esxcfg-nics -l", I can see that the current Intel NIC that is connected is the Intel 1000 GT Desktop adapter. Doing some searching about the silicon on that NIC (Intel 82541GI), I can find quite a few Linux-related problems with it. Though ESX is not Linux-based, a lot of the hardware drivers share elements with Linux counterparts. (That particular NIC is also not on the ESX HCL.)
The other Intel NIC is also a bit weird - the MAC address only varies in the last nibble, which usually indicates a dual-port NIC, yet I can see they're on completely seperate busses and use different silicon. Odd. Regardless, it's also a lower-end desktop NIC and also does not appear to be on the HCL.
Next steps:
Please can you re-test with the HP NC382T? Use esxtop networking screen ("n") to confirm that the VM is actually bound to either vmnic1 or vmnic2
What is the memory situation on the machine? Please open esxtop, switch to the memory screen ("m"), copy & paste what's displayed
Finally, please try adding a vmxnet3 adapter to the VM and test using that again
(I realise this is a lot of "testing" - appreciate the time you're putting into this! Hope we can get this solved, otherwise support is going to ask you to start over )
Has anyone foud a solutions for this problem.
We are experiencing the same issue withe the dropdowns in the Vm graphs.
We have not found anything that explains this behaviour.
We are running Citrix servers on thos hosts and the end users complain about hickups in their sessions. So when they type something it lags behind for a couple of seconds and then goes on.
We are using a SUN 600 blade chassis with 10 Gb Nem modules.
We ar now testing on a Hp DL380 G7 with a 10Gb adapter and are seeing simular behaviour.
When we are connecting only 1 Gb modules we don't see the problem.
Any help will be greatly appreciated.