Speed of plb_temac 3.00 on ML403
Ming Liu
eemingliu at hotmail.com
Tue Feb 13 06:18:03 EST 2007
Dear Jozsef,
>on the contrary: our whole design is built on the principle that with UDP
>you do not need too much handling/processing, and your data path can
>bypass the IP stack, the CPU, and with some work even the main memory.
>
>with TCP you (the os) have to take care of connection set up and tear
>down, acknowledgements, packet retransmission (and for that you need to
>save the packets until they are ack'ed!), etc. in return you get reliable
>data transmission, which is a must in many applications.
>
>however we don't need that. duplication or loss of a packet, or reordering
>of packets (which could happen when using UDP) would not be a critical
>problem for us. but these are mostly theoretical issues, they don't realy
>happen on our dedicated daq network (except for packet losses that we
>deliberately use as poor man's flow control).
In fact, in our application we also use UDP. I know UDP need less CPU
processing capability than TCP. However, just like what I measured, my UDP
performance is around 350Mbps and TCP performance is 270Mbps when
Jumbo-frame enabled. In my application, I have to use the CPU to process
the UDP or TCP packets. Then this "need not too much processing" results
the much lower performance as I listed above. :(
You said in your application the data path can bypass the IP stack, the
CPU, and with some work even the main memory. How can you achieve that?
Then who will process the UDP packets? If you add the work of processing
packets in, do you have some idea on how fast can your network achieve? I
believe it will be much lowered, right? :)
Thanks for your discussion.
BR
Ming
_________________________________________________________________
与联机的朋友进行交流,请使用 MSN Messenger: http://messenger.msn.com/cn
More information about the Linuxppc-embedded
mailing list