Bug 160019

Summary: Full-duplex Gigabit can not reach gigabit at both RX/TX same time
Product: Red Hat Enterprise Linux 3 Reporter: Robinson Tiemuqinke <hahaha_30k>
Component: kernelAssignee: John W. Linville <linville>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: davem, petrides
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-08-03 16:11:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Robinson Tiemuqinke 2005-06-10 01:33:33 UTC
Description of problem:
Full-duplex mode Gigabit can not reach near gigabit at both sending and 
receiving sides. Instead, the sum of sending and receiving reaches gigabit. 
The tests are ttcp tests on two HP workstation XW4200.

Case 1, only receiving, no sending.
  The sending speed is near 0MBytes/s, receiving speed is 110MB/s.

case 2, only sending, no receiving.
  The sending speed is near 110MB/s, receiving speed is near 0MB/s.

case 3, both sending and receiving at the same time.
  The sending speed is about 55MB/s, receiving at about 55MB/s.




Version-Release number of selected component (if applicable):


How reproducible:
Every time.
Not only on Redhat Enterprise Linux, but also on Fedora Core series.

Steps to Reproduce:
1. Install Redhat Enterprise 3 or 4 onto two HP Workstation XW4200, or similar 
machines with high PCI Bus speed. and connect the builtin Broadcom network 
cards with a crossover CAT6 cable. This way exclues the LAN Switch factor.

2. run ttcp on the two machines, either as sending role, or as receiving role.

3.test all the 3 cases in the "Description of Problem" section. and the 
results will be quite similar.
  
Actual results:


Expected results:
  When machines' gigabit(in full-duplex gigabit mode) in sending and receiving 
data at the same time, both the sending speed and receiving speed should be 
around 110MB/s. And the SUM of them should be 220MB/s.


Additional info:

 According to HP support technician, the HP workstation XW4200 has a PCI 
EXpress bus which support 2.5GB/s data transfer. "top" commands reports that 
machine box still have 80% Idle CPU cycles.

Comment 1 Ernie Petrides 2005-06-10 04:20:27 UTC
*** Bug 160020 has been marked as a duplicate of this bug. ***

Comment 2 David Miller 2005-06-10 05:26:28 UTC
Not true, the some should not be 220MB/sec.  You're forgetting
that the opposite direction of the transfer is consumed by ACK
packets.

So for the single transfer case you have:

SENDER --> DATA --> DATA --> DATA --> DATA --> DATA --> RECEIVER
SENDER <-- ACK  <-- ACK  <-- ACK  <-- ACK  <-- ACK  <-- RECEIVER

With the case of two transfers going at once you have:

Host1 --> DATA --> ACK --> DATA --> ACK --> DATA --> ACK Host2
Host2 <-- ACK  <-- DATA <-- ACK <-- DATA <-- ACK <-- DATA Host2

This is not a bug.


Comment 3 Robinson Tiemuqinke 2005-06-10 17:42:21 UTC
David Miller, Thanks for you quick reply.

But I've also tested the normal 100Mbits/s network cards in full-duplex modes. 
with two pairs of sending-receiving ttcp on two Redhat Linux hosts.

The results are: On each machine, the sending side speed is 12MB/s, receiving 
speed is also at 12MB/s. totally the SUM is 24MB/s, quite close to the 
capacity of 200Mbits/s(added sending and receiving sides).

The above is quite easy to reproduce, you can use two 100Mbits/s cards, or 
Gigabit works at 100Mbits/s fFull-duplex mode. The OS can be Redhat Enterprise 
Linux or Fedora Core, kernel can be 2.4 or 2.6. The results is exactly the 
same.



Comment 4 John W. Linville 2005-06-10 18:08:24 UTC
What NICs are you using (particular in the xw4200)?  Are they actually PCI-E?  
Or are they PCI(-X)? 
 
Please attach the output of running "sysreport" to this bug.  Thanks! 

Comment 5 John W. Linville 2005-08-03 16:11:22 UTC
Closed due to inactivity.  Please reopen when requested information becomes 
available.  Thanks!