vxWorks IP/UDP stack performance problem
James Chen
Our analysis shows that a "sendto" takes about 420us on Motorola8260
and 720us on 860. This measurement is done with only vxWorks tasks
running (i.e. our own application tasks are not running).
Our application is processing calls, and each call has 2 sendto. We need
to do 90 calls every 20ms. You can see we are in trouble already (e.g. 8260
can only do around 47 sendto in 20ms.)
I am looking for ideas to improve the performance. I have read some of
the postings in this news group. I'm going to try ideas like:
1. use loan buf not bcopy in the ethernet driver;
2. don't do netJobAdd when tNetTask is already processing receiving packets;
3. maybe try to disable INTR once an INTR occurs, and use tNetTask to process
all ethernet frames (i.e. polling), although this will increase the INTR
latency;
4. bypass the IP stack all together when sending packets by invoking
the driver's send;
5. I'm not sure about zbuf (eliminating copy from application to socket layer),
since I have read different opinions about it;
Any suggestions, comments or sharing of your experiences are greatly appreciated.
Thanks in advance,
James
Keith Arner
> We have a problem with the performance of vxWorks IP/UDP stack.
> Our analysis shows that a "sendto" takes about 420us on Motorola8260
> and 720us on 860. This measurement is done with only vxWorks tasks
> running (i.e. our own application tasks are not running).
If you use send() instead of sendto(), you might be able to squeeze a
little performance out. When you do a sendto(), the IP stack will
basically do a connect() internally, then send the packet, then
unconnect it (though it doesn't call connect() to do this).
If you connect() your socket first, you essentially are able to move the
connect() logic outside the loop. Note, however, that if you are sending
packets to several distinct addresses, you'd need to maintain a socket per
address, and add logic to figure out which socket to use. Of course, this
additional logic might slow things back down to your previous performance
levels. Your mileage may vary.
Also, if you connect() your socket and receive an ICMP unreachable packet
for that address, the *next* write on that socket (e.g. the one following
the failed send) will return an error. At that point, the only way to
clear the error is to close the socket (and re-open a new one, if you need
to).
Oh, and as a pre-emptive strike: yes, you can connect() a UDP socket, even
though UDP is not connection oriented. When you connect() a UDP socket,
you are basically just declaring the address to which you will be sending
packets.
Keith
Demrala Rood
I think first to know where is the problem instead of going straight
to try things in the ethernet driver. Why don't you try measuring the
time of sendto when sent to 127.0.0.1? If is still big, then leave the
driver alone because its not to blame. I don't think anything you list
is going to help and some of them will maybe make it worse.
dr
Claudio Potenza
> We have a problem with the performance of vxWorks IP/UDP stack.
> Our analysis shows that a "sendto" takes about 420us on Motorola8260
> and 720us on 860. This measurement is done with only vxWorks tasks
> running (i.e. our own application tasks are not running).
I did the very same measurement on a 8260 (using the motFcc driver)
and saw something like 200-300 usec to do a sendto.
Things that you can do to improve:
1) Do you have instruction and data cache turned on? (I had)
2) you can turn off computation of UDP cheksum (there is
an ioctl code to do this)
3) ?????
I can tell you that in my project in the end I decided to preformat
the IP and UDP header header and send the packet as raw ethernet
packets using the ifstruct->if_output function.
This way I obtained something around 70-80 usec per send
James Chen
On 8260, from INTR to socket receive complete it
takes 800us for SCC and 332us for FCC.
It takes the same amount of time (100us) from INTR
to pushing up to IP stack in both SCC and FCC driver.
I don't understand why there is almost 500us
difference
between a FCC packet and a SCC packet processing
in the IP stack even thought both driver (mux) layer
takes the same amount of time.
This test is done with only vxWorks tasks running. I
made sure there was no other IP traffic, no serial
INTRs.
Another observation (or surprise) is the mblk memory
copy in the driver layer. It takes around 200us just
to do a copy in the SCC driver, but only 40us in the
FCC driver. This doesn't make any sense. Both piece
of code is executed on the same power PC???
Thank you for sharing your experiences.
cpot...@onetel.net.uk (Claudio Potenza) wrote in message news:<2025ac82.02041...@posting.google.com>...
Hwa Jin Bae
enabled memory?
--
Hwa Jin Bae
mailto:h...@pso.com
http://www.pso.com