2009-02-18 11:19:50     netperf results

Document created by Aaronwu Employee on Aug 15, 2013
Version 1Show Document
  • View in full screen mode

2009-02-18 11:19:50     netperf results

Servaes Joordens (NETHERLANDS)

Message: 69570   

 

I did some test with netperf and netserver.

 

netserver runs on a fast PC with SUSE 10 and a 100Mb network card.

netperf is run from the blackfin device (tcm-bf537bp).

 

Recv Socket Size bytes = 256

Send Socket Size bytes = 16384

Send Message Size bytes = 16348

Elapsed Time secs. = 10.01

Throughput 10^6 bits/sec = 6.84

 

I guess the recv buffer is to small?

QuoteReplyEditDelete

 

 

2009-02-18 11:49:22     Re: netperf results

Servaes Joordens (NETHERLANDS)

Message: 69572   

 

I also tested the other way around:

 

netserver on blackfin device.

netperf on a fast PC with Suse 10 with 100Mb network card.

 

Recv Socket Size bytes = 87380

Send Socket Size bytes = 16384

Send Message Size bytes = 16348

Elapsed Time secs. = 10.35

Throughput 10^6 bits/sec = 5.24

 

 

 

netserver on blackfin device.

netperf on a fast PC with Suse 10 with 1000Mb network card:

 

Recv Socket Size bytes = 87380

Send Socket Size bytes = 16384

Send Message Size bytes = 16348

Elapsed Time secs. = 10.35

Throughput 10^6 bits/sec = 7.34

 

 

 

netserver on blackfin device.

Also tested with netperf on a laptop with a 100Mbit card and Suse 10:

 

Recv Socket Size bytes = 87380

Send Socket Size bytes = 16384

Send Message Size bytes = 16348

Elapsed Time secs. = 10.00

Throughput 10^6 bits/sec = 46.56

 

 

QuoteReplyEditDelete

 

 

2009-02-18 16:45:46     Re: netperf results

Mike Frysinger (UNITED STATES)

Message: 69584   

 

describe the exact hardware you're using on the Blackfin device

 

assuming you're using the on-chip mac, what kernel options are you using exactly for it ?

QuoteReplyEditDelete

 

 

2009-02-19 04:30:13     Re: netperf results

Servaes Joordens (NETHERLANDS)

Message: 69622   

 

I attached the config file.

 

 

 

config

QuoteReplyEditDelete

 

 

2009-02-19 04:35:43     Re: netperf results

Servaes Joordens (NETHERLANDS)

Message: 69623   

 

hardware:

 

blackfin device: tcm-bf536bp of Bluetechnix

a Netgear 5port Gigabit switch (model GS105)

A Dell Dimension 8400 (dual core) with two network cards 100Mb and 1000Mb (I enable and disable the network cards depending on the test I perform) installed SUSE10

 

my laptop:

Dell Inspiron 9300 with a 100Mb network card and SUSE 10

QuoteReplyEditDelete

 

 

2009-02-19 12:45:04     Re: netperf results

Mike Frysinger (UNITED STATES)

Message: 69648   

 

that doesnt say what is being used on the Blackfin part.  presumably you're using the on-chip mac, but your config doesnt actually select any PHY driver, nor does the tcm parts include a PHY on the module itself.

QuoteReplyEditDelete

 

 

2009-02-22 13:57:17     Re: netperf results

Servaes Joordens (NETHERLANDS)

Message: 69728   

 

Mike,

 

So how do I select or write a PHY driver? The phy is something my hardware engineer put on assuming it is compatible with other PHY's.

 

I also tested my current kernel on a cm-bf537 combined with a development board of bluetechnix. I got excellent results with that configuration. The only relevant difference with the tcm-bf537bp on our hardware is the PHY, so this confirmes your suggestion on the PHY driver.

 

Could you please help me getting started on selecting the appropriate PHY driver? Where are the phy drivers located in the distribution? Is there a wiki on this subject?

 

regards,

Servaes

QuoteReplyEditDelete

 

 

2009-02-23 05:48:27     Re: netperf results

Servaes Joordens (NETHERLANDS)

Message: 69748   

 

Mike,

 

This is the relevant part of the startup messages of the kernel:

 

arch/blackfin/mach-bf537/boards/tcm_bf537.c:bfin_get_ether_addr: Setting Etherne

t MAC to a random one

bfin_mac_mdio: probed

bfin_mac: attached PHY driver [Generic PHY] (mii_bus:phy_addr=0:01, irq=-1, mdc_

clk=2500000Hz(mdc_div=19)@sclk=100MHz)

bfin_mac bfin_mac.0: Blackfin on-chip Ethernet MAC driver, Version 1.1

 

regards,

Servaes

QuoteReplyEditDelete

 

 

2009-02-23 13:14:41     Re: netperf results

Mike Frysinger (UNITED STATES)

Message: 69765   

 

so it's using the generic phy driver.  you should make sure there isnt a better phy driver available for whatever phy you actually have on there.

 

are you testing TCP or UDP ?  can you see if there's a difference between the two ?

QuoteReplyEditDelete

 

 

2009-02-23 14:04:33     Re: netperf results

Servaes Joordens (NETHERLANDS)

Message: 69766   

 

We use a micrel PHY type KS8721

 

It is set to 100Mb/Half duplex through auto-negotiation although the phy is capable to have 100Mb/Full duplex.

 

I started to debug the register settings of the phy driver to see if I can detect some strange behaviour.

 

 

QuoteReplyEditDelete

 

 

2009-02-24 08:42:51     Re: netperf results

Phil Wilshire (UNITED STATES)

Message: 69811   

 

Hi Servaes,

 

There are a couple of other parts using this PHY

 

see

 

linux-2.6.x/drivers/net/arm/at91_ether.c

 

and

 

linux-2.6.x/drivers/net/fec.c

 

Hopefully you may find some answers there.

 

regards

 

 

 

  Phil Wilshire

 

 

QuoteReplyEditDelete

 

 

2009-02-25 09:01:38     Re: netperf results

Servaes Joordens (NETHERLANDS)

Message: 69888   

 

Thanks Phil,

 

I will take a look at it. I also did some debugging. The conclusion is that the phy is unwilling to go into full duplex mode with 100Mb.

I am still searching for a reason why it does not want to go into full-duplex mode. I am afraid it has something to do with hardware.

 

I think the reason for the extremely low throughput with a fast PC is that the PC sends an acknowledgement directly. The phy has to switch between sending and receiving and therefore chrashin the throughput. With a slower PC (my laptop) the acknowledge will take some more time. There will be less switches between sending and receiving, so the troughput will be better than wil a faster PC. Please note that this is my theory, I still have to check it with a packet sniffer.

 

Do you have any ideas howto change some timing properties of the socket connection to tune the communication for half-duplex ethernet.

 

regards,

 

Servaes

QuoteReplyEditDelete

 

 

2009-02-25 09:28:59     Re: netperf results

Michael Hennerich (GERMANY)

Message: 69893   

 

A PHY typically features 2 or 3 Mode Pins. The state of these pins during reset define if the PHY is in Autonegotiation Mode, Full-Duplex or Half-Duplex.

 

Check the PHY datasheet and compare against your schematics.

 

You should get similar results - see below:

 

michael@mhenneri-D02:~/Documents> cat netperf.sh

#!/bin/bash

cases="TCP_RR TCP_CRR TCP_STREAM UDP_RR UDP_STREAM"

 

echo Executing Netperf on machine $2 - Netserver runs on $1

rsh -l root $2 'version;cat /proc/cpuinfo; cat /sys/class/net/eth0/device/modalias'

for i in $cases

do

echo -------------------------------------- Now running Netperf: $i --------------------------------------

rsh -l root $2 'netperf -H ' $1 '-t' $i

d

 

 

 

michael@mhenneri-D02:~/Documents> ./netperf.sh 10.44.2.88 10.44.2.45

Executing Netperf on machine 10.44.2.45 - Netserver runs on 10.44.2.88

kernel: Linux release 2.6.28.6-ADI-2009R1-pre-svn6123, build #10238 Tue Feb 24 17:08:51 CET 2009

toolchain: bfin-uclinux-gcc release gcc version 4.1.2 (ADI svn)

user-dist: release svn-7786, build #3480 Tue Feb 24 17:08:07 CET 2009

processor : 0

vendor_id : Analog Devices

cpu family : 0x27c8

model name : ADSP-BF537 500(MHz CCLK) 125(MHz SCLK) (mpu off)

stepping : 3

cpu MHz : 500.000/125.000

bogomips : 989.18

Calibration : 494592000 loops

cache size : 16 KB(L1 icache) 32 KB(L1 dcache-wb) 0 KB(L2 cache)

dbank-A/B : cache/cache

icache setup : 4 Sub-banks/4 Ways, 32 Lines/Way

dcache setup : 2 Super-banks/4 Sub-banks/2 Ways, 64 Lines/Way

board name : ADI BF537-STAMP

board memory : 65536 kB (0x00000000 -> 0x04000000)

kernel memory : 64504 kB (0x00001000 -> 0x03eff000)

 

platform:bfin_mac

-------------------------------------- Now running Netperf: TCP_RR --------------------------------------

TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.44.2.88 (10.44.2.88) port 0 AF_INET

Local /Remote

Socket Size Request Resp. Elapsed Trans.

Send Recv Size Size Time Rate

bytes Bytes bytes bytes secs. per sec

 

16384 87380 1 1 10.00 4053.09

16384 87380

-------------------------------------- Now running Netperf: TCP_CRR --------------------------------------

TCP Connect/Request/Response TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.44.2.88 (10.44.2.88) port 0 AF_INET

Local /Remote

Socket Size Request Resp. Elapsed Trans.

Send Recv Size Size Time Rate

bytes Bytes bytes bytes secs. per sec

 

16384 87380 1 1 10.00 1140.39

16384 87380

-------------------------------------- Now running Netperf: TCP_STREAM --------------------------------------

TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.44.2.88 (10.44.2.88) port 0 AF_INET

Recv Send Send

Socket Socket Message Elapsed

Size Size Size Time Throughput

bytes bytes bytes secs. 10^6bits/sec

 

87380 16384 16384 10.00 90.05

-------------------------------------- Now running Netperf: UDP_RR --------------------------------------

UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.44.2.88 (10.44.2.88) port 0 AF_INET

Local /Remote

Socket Size Request Resp. Elapsed Trans.

Send Recv Size Size Time Rate

bytes Bytes bytes bytes secs. per sec

 

106496 106496 1 1 10.00 5493.85

124928 124928

-------------------------------------- Now running Netperf: UDP_STREAM --------------------------------------

UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.44.2.88 (10.44.2.88) port 0 AF_INET

Socket Message Elapsed Messages

Size Size Time Okay Errors Throughput

bytes bytes secs # # 10^6bits/sec

 

106496 65507 10.01 1446 0 75.73

124928 10.01 1446 75.73

 

 

QuoteReplyEditDelete

 

 

2009-02-26 11:59:24     Re: netperf results

Servaes Joordens (NETHERLANDS)

Message: 70019   

 

Problem solved!

 

It was a hardware problem: a missing pull-up resistor on the MDIO pin on the phy.

The maximal communication speed on MDIO was reduced by the missing resistor, because it takes more time to pull up the electrical level on a rising edge.

 

I solved the problem by changing the communication speed with EMAC_SYSCTL  MDCDIV.

 

Thanks for helping!

QuoteReplyEditDelete

 

 

2009-04-06 13:23:03     Re: netperf results

Rob Maris (GERMANY)

Message: 72269   

 

Another software workaround is given by selecting the Realtek Phy driver for Micrel's 8721. Upon an inquiry, Micrel regrets however that they cannot mention a compatible driver among the drivers that are selectable. Nevertheless they suggested that Realtek would be closest.

 

Indeed, when I select Realtek PHY, the PHY tends to operate reliably in Full Duplex mode (without pull-up). However, the boot log still shows [Generic PHY]. Therefore I compared the binary images between build without any specific PHY support, and with Realtek support. The images are different (the Realtek version saves approx. 1000 bytes).

 

I am working with trunk sources. Here I didn't find an option EMAC_SYSCTL, MDCDIV.

QuoteReplyEditDelete

 

 

2009-04-16 12:20:25     Re: netperf results

Rob Maris (GERMANY)

Message: 72762   

 

Regarding limitation of MDIO communication speed: The exact place to change this is in a source file:

 

.../drivers/net/bfin_mac.c

 

#define MDC_CLK 1250000

 

This would half the management-I/O speed. Note that MDIO/MDC is a sort of I2C-bus.

 

BTW: the utilization of a dedicated PHY driver as stated in the previous post was only partially OK.

QuoteReplyEditDelete

 

 

2009-04-20 20:23:06     Re: netperf results

Mike Frysinger (UNITED STATES)

Message: 72914   

 

i guess we could push the speed down into the board resources if people actually want/need to change the speed

Attachments

Outcomes