Jaroslav Ovtsyn <firstname.lastname@example.org> wrote:
This is a multi-part message in MIME format.
We’re facing exactly the same performance problem and just like you we
didn’t notice any improvements after switching to release 6.2.1. We’re
Embedded Planet’s EP405PC Board, 200MHz, 64MB RAM. The highest FTP
rate that we could reach was only about 0.7-0.8 MByte/sec - way below
I think this needs to be corrected:
– 0.8 MByte/sec is reached when a file is transferred into the target’s RAM
disk using FTP.
– around 2MByte/sec is reached when the data are dropped by the target
immediately after receiving.
In my test setup - the target is on the receiving side of a TCP/IP
connection, while the host transmits data non-stop - the transfer rate drops
significantly every few seconds. I attribute this behavior to a TCP flow
control mechanism; they probably have some sort of a back-off algorithm to
cope with network congestions.
I tried to increase TCP TX/RX buffers using setsockopt(), but the system
caps them at around 20K. Any idea how could I do that ?
It sounds like packets are being dropped and retransmitted. Try
tuning the recvspace parameter, e.g.
sysctl -w net.inet.tcp.recvspace=8192
You might get some more clues as to what’s going on by running
netstat -ptcp and netstat -pip.
Werners original post was posted to two groups, and the thread continued
in the other group…
In any case, the throughput you’re seeing is way below what you should
be getting. Can you post the output of “nicinfo” after running some
ftp tests? Also, what is the Rev. number written on the 405 chip
that you are using?
This is what’s written on the chip:
And this is what I get from “nicinfo” (nothing suspicios, huh?) :
Everything looks normal here.
PPC405 on-chip EMAC Ethernet Controller
Physical Node ID … 0010EC 000000
Current Physical Node ID … 0010EC 000000
Media Rate … 100.00 Mb/s full-duplex UTP
MTU … 1514
Lan … 0
I/O Port Range … 0xEF600800 → 0xEF6008FF
Hardware Interrupt … 0xC
Promiscuous … Disabled
Multicast … Enabled
Total Packets Txd OK … 35828
Total Packets Txd Bad … 0
Total Packets Rxd OK … 160037
Total Rx Errors … 0
Total Bytes Txd … 2364640
Total Bytes Rxd … 237865911
Tx Collision Errors … 0
Tx Collisions Errors (aborted) … 0
Carrier Sense Lost on Tx … 3
FIFO Underruns During Tx … 0
Tx deferred … 0
Out of Window Collisions … 0
FIFO Overruns During Rx … 0
Alignment errors … 0
CRC errors … 0
I was also adviced by QNX support people to add two more options: “-c1”
“cache=1”, although it didn’t help much as I mentioned. That’s the
io-net -c1 -d ppc405 … -p tcpip cache=1 &
It’s been 2 months since this message was posted (no
Does it mean the problem has been resolved?
Embedded Software Designer
Ottawa, ON, Canada
“Werner Benz” <> email@example.com> > wrote in message
news:b08gtj$la7$> firstname.lastname@example.org> …
Hello PowerPC users,
one intention to participate as beta-tester for QNX6.2.1 is to get a
re-designed devn-ppc405.so, announced from german QNX-Support group.
Now we built the BSP’s, images for different PPC405 boards (Walnut,
MIP405 from MPL AG and proprietary hardware with PPC405), running with
newest release, but there is no change in ethernet performance. The
bandwidth that we could reach via QNET is about 2MByte/sec, we expect
rates above 6MBytes/sec (7.5MByte/sec measured with Linux on PPC405).
Does anyone test the ethernet performance on other PowerPC boards with
QNX release? Which data rates could you reach?
One point to the devn-ppc405.so:
calling the usage info tells following:
io-net -d ppc405 [option[,option …]] … &
deviceindex Only attach to this instance of the on-chip
verbose Disable emission control of message output. ←
this mean: be verbose?
TITLE:Embedded Software Specialist
ADR;HOME:;;33 Denham Way;Stittsville;ON;K2S 1H5;Canada
LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:33 Denham =
Way=3D0D=3D0AStittsville, ON K2S 1H5=3D0D=3D0ACanada