lkml.org 
[lkml]   [2004]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: TG3: very high CPU usage
Hi,

At 12:43 AM 25/01/2004, JG wrote:
>box1 was sending, box2 receiving:
>box1 # ttcp -t -l 65536 -v -b 2097152 -s -D -n100000 192.168.0.3
>ttcp-t: -2036334592 bytes in 1247.57 real seconds = 1768.00 KB/sec +++
>ttcp-t: -2036334592 bytes in 30.01 CPU seconds = 73492.73 KB/cpu sec

urgh, those are terrible numbers!

>now the opposite, box2 was sending, box1 receiving:
>box2 ttcp # ttcp -t -l 65536 -v -b 2097152 -s -D -n100000 192.168.0.2
>ttcp-t: -2036334592 bytes in 153.82 real seconds = 14339.52 KB/sec +++
>ttcp-t: -2036334592 bytes in 28.61 CPU seconds = 77085.45 KB/cpu sec

better, but still terrible.

even an old Pentium3 @ 500MHz here is capable of pushing GbE wire-rate (i
just tested this using a Tigon2).

>i thought the cable could be defective because of the results, but i
>tested with another machine (windows xp, 100mbit card) and both up and
>download speed via ftp (from both boxes!) was at about 8-9MB/s. so no
>problem with the cable and it seems also no problem with 100mbit, but as
>soon as i connect the two tg3 cards together with 1000mbit, one direction
>is slow (cable is gbit certified and worked with 2.4 kernels without any
>problem).

actually, this isn't necessarily the case.

Fast Ethernet only uses 1 pair of wires each for Tx/Rx (4 wires), whereas
copper GbE uses 2 pairs each for Tx/Rx (8 wires).
it may be the case that your cable has some bad connections on the pins
only used for 1000baseT.

>as i already mentionend in a previous email, the errors on the tg3 cards
>are quite high, but only in RX:
>box1:
>RX packets:18585312 errors:102500 dropped:0 overruns:0 frame:102598
>TX packets:12435471 errors:0 dropped:0 overruns:0 carrier:0
>box2:
>RX packets:6864695 errors:202162 dropped:0 overruns:0 frame:204652
>TX packets:10049776 errors:0 dropped:0 overruns:0 carrier:0

on a x-over cable, you should NEVER have any errors.
if this is indeed simply an x-over cable, then i'd replace it and try again.

(note that for 1000baseT you don't need to worry about whether the cable is
x-over or not; 1000baseT on most NICs/switches will auto-detect the parity
anyway..).

Broadcom have a tool on their web site called "BACS" which can take
advantage of some of the neat stuff in the PHY used on these boards. one
of the tests it can do is to check the quality of the cable and report any
problems it sees; it can run a signal/noise test on each pair.

FYI, doing a "Cable Analysis" on a single port of a BCM5703 here connected
to a switch (not x-over) with a ~1 metre patch cable shows:
Distance (m): ~1
Margin (dB): 5.132
Frequency Margin (MHz): 41.382


cheers,

lincoln.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:00    [W:0.115 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site