Archivovaná správa #71 diskusnej skupiny virtualized_ecs_users@2rosenthals.com | spä? do zoznamu |
|
---|
On 2009-12-09, at 18:28:29, Lewis G Rosenthal wrote:I was able to successfully connect a CAT-6 straight through between a workstation and the ThinkPad. The interesting discovery I made was that even though I have power management at a bare minimum, evidently, while on battery power, my wired NIC is throttled down. The best I could get (no TAP driver) was about 480Mbps on battery. Plugged into AC, however, I was able to eek out >830Mbps.
Hi, Doug...
Hi Lewis...
On 12/09/09 05:35 pm, Doug Bissett thus wrote :
On 2009-12-09, at 14:01:33, Lewis G Rosenthal wrote:Indeed, I thought of the auto-sensing circuitry, but don't know if the T43 or the new Intel chip (still trying to get GenMAC to work with it) - an 82567LF-2 - do auto-sense. The switch surely does, which is why I no longer stock crossover cables. :-)
...snip...
I'll have to fashion myself a CAT-6 crossover to eliminate the switch from the equation.)Most modern switches, and NICs, will automatically reverse the wiring,
if they think you might be using the wrong cable. Just try a normal
cable.
I did my tests with a standard cable (probably CAT5) that is about 5
feet long. No trouble with not using a crossover cable.
My tests using the B57 driver were just as abysmal under AC as they were under battery power (no TAP driver loaded). That said, on the ThinkPad I got similar results to what I saw on the server, so I suspect it is just a poorly written device driver base from Broadcom (different versions, but similar lack of optimization). Does anyone have an NDIS2 driver running at close to 1Gbps?Thanks. I'm going to test on a couple other networks and systems available to me, as well. I, too, am normally sitting behind a 100Mbps secondary switch on this segment of the LAN or going wireless. However, the native B57 NDIS2 driver dropped off to under 500bps (that's bits, not Bytes!) vs GenMAC running the NDIS5 driver (without IJFW and IPX on the wire).Has anyone else seen this type of performance hit cuased by the TAP driver?No, but my switch, and router, only run at 100 Mbs, so I may not have
noticed a speed reduction. I will see if I can hook it direct from my
desktop to my T43, and see what happens (may be tomorrow, before I get
a chance).
Okay, first some information:<snip>
Test boxes:
Asus M3A78-EM motherboard, using GENMAC with a Realtek 8168 NIC 10EC:8168.
IBM ThinkPad T43 (1871-W8M), using GENMAC with a Broadcom NIC
14E4:167D. This machine also has an Intel wireless 8086:4224, which
was radio off for the testing.
Both systems are running eCS 2.0 Silver, using NETBIOS over TCP/IP. The
T43 doesn't have the TAP driver installed. The M3A78-EM did not have
VBOX installed when I started, and the T43 has never had it installed.
Both systems also have Virtual PC installed, with the bridge driver. I
never actually ran VBOX on the M3A78-EM, before doing the tests. I am
using NETIO126.
Test results:If you used a CAT-5 cable vs a CAT-5e or a CAT-6, this might account for the results. Also, without locking the NICs down to 100Mbps, and with no 100Mbps switch in between, they might be trying to shift up to 1000Mbps, which will likely fail over a CAT-5 connection, causing them to resend and/or renegotiate. It's hard to tell without seeing the actual packets.
=======================
Test 1: No TAP$ on either side.
TCP connection established.
Packet size 1k bytes: 8558 KByte/s Tx, 8507 KByte/s Rx.
Packet size 2k bytes: 11468 KByte/s Tx, 11505 KByte/s Rx.
Packet size 4k bytes: 11478 KByte/s Tx, 11378 KByte/s Rx.
Packet size 8k bytes: 11483 KByte/s Tx, 11505 KByte/s Rx.
Packet size 16k bytes: 11483 KByte/s Tx, 11161 KByte/s Rx.
Packet size 32k bytes: 11486 KByte/s Tx, 11380 KByte/s Rx.
NetBIOS connection established.
Packet size 1k bytes: 2664 KByte/s Tx, 3664 KByte/s Rx.
Packet size 2k bytes: 8592 KByte/s Tx, 11090 KByte/s Rx.
Packet size 4k bytes: 11252 KByte/s Tx, 11130 KByte/s Rx.
Packet size 8k bytes: 11313 KByte/s Tx, 11341 KByte/s Rx.
Packet size 16k bytes: 11397 KByte/s Tx, 11399 KByte/s Rx.
Packet size 32k bytes: 11425 KByte/s Tx, 11432 KByte/s Rx.
UDP connection established.
Packet size 1k bytes: 9204 Byte/s (99%) Tx, 8752 KByte/s (0%) Rx.
Packet size 2k bytes: 148 KByte/s (99%) Tx, 8994 KByte/s (0%) Rx.
Packet size 4k bytes: 58843 Byte/s (99%) Tx, 0 Byte/s (100%) Rx.
Packet size 8k bytes: 0 Byte/s (100%) Tx, 0 Byte/s (100%) Rx.
Packet size 16k bytes: 0 Byte/s (100%) Tx, 0 Byte/s (100%) Rx.
Packet size 32k bytes: 0 Byte/s (100%) Tx, 0 Byte/s (100%) Rx.
Test 2: Tap$ on client side (M3A78-EM) only.
TCP connection established.
Packet size 1k bytes: 7762 KByte/s Tx, 8236 KByte/s Rx.
Packet size 2k bytes: 7881 KByte/s Tx, 8653 KByte/s Rx.
Packet size 4k bytes: 7959 KByte/s Tx, 9176 KByte/s Rx.
Packet size 8k bytes: 7997 KByte/s Tx, 10743 KByte/s Rx.
Packet size 16k bytes: 7954 KByte/s Tx, 11393 KByte/s Rx.
Packet size 32k bytes: 7980 KByte/s Tx, 11400 KByte/s Rx.
NetBIOS connection established.
Packet size 1k bytes: 2705 KByte/s Tx, 3731 KByte/s Rx.
Packet size 2k bytes: 6244 KByte/s Tx, 7519 KByte/s Rx.
Packet size 4k bytes: 6527 KByte/s Tx, 8182 KByte/s Rx.
Packet size 8k bytes: 7325 KByte/s Tx, 10064 KByte/s Rx.
Packet size 16k bytes: 7836 KByte/s Tx, 11270 KByte/s Rx.
Packet size 32k bytes: 7904 KByte/s Tx, 11174 KByte/s Rx.
UDP connection established.
Packet size 1k bytes: 7656 KByte/s (7%) Tx, 4532 Byte/s (99%) Rx.
Packet size 2k bytes: 8328 KByte/s (0%) Tx, 12619 Byte/s (99%) Rx.
Packet size 4k bytes: 11039 KByte/s (0%) Tx, 66999 Byte/s (99%) Rx.
Packet size 8k bytes: 11097 KByte/s (0%) Tx, 62 KByte/s (99%) Rx.
Packet size 16k bytes: 0 Byte/s (100%) Tx, 0 Byte/s (100%) Rx.
Packet size 32k bytes: send(): No buffer space available
===============================
For some reason, UDP seems to have a problem, so I think you can
discount what that test says, in both cases.
The really interesting numbers are in TCP, and NETBIOS, with and
without the TAP driver installed. Sending seems to be limited to what I
see with my 100 Mbs hub in the network. With a direct connection, and
no TAP driver, send and receive seem to be about the same. The
interesting thing is that receiving doesn't seem to be affected by
whatever is slowing down sending.
As an aside, I discovered that the MPTS in eCS 2.0 Silver has added aFor the record, I *hate* that M$ LLA nonsense. If I have no static address and no DHCP server, then by g-d, I don't want a fake IP address. If I get a bunch of machines together to chatter amongst themselves, they're either statically assigned or one of them is running DHCP. IMO LLA is more trouble than it's worth, and a real hassle for our stack to deal with, on top of everything else.
feature to install LLAeCS.EXE into \MPTN\BIN\MPTSTART.CMD, every time
it runs (even if you don't change anything). This took me on a wild
goose chase for a while, since LLAeCS.EXE hangs at boot, unless I start
it much later than in MPTSTART.CMD.
This is somewhat limited testing, but I think that it shows that theNote mine... :-(
TAP driver does limit send speed to something near 100 Mbs, even when
using a gigabit NIC. In different configurations, the results could be
different.
I never tried wireless, but I will do that, when I find some time toGood luck getting the TAP driver to bind to the wireless NIC. The trick which Andy showed me (and this was under VPC, before we had VBox) was to keep it bound to the wired NIC, and enter a static route to allow traffic to bounce back and forth off of the wired interface to the wireless. To get this right, you really need to "think like a packet," as a friend of mine likes to say. Also, this arrangement obviously doesn't work in a bridged environment (all of my tests were bridged). We might want to try a NAT configuration, I guess...
play with it again.
Prihlási?: Nap??a?,
Súhrn,
Index. Odhlási? Mail na ListMastera |