On Sun, 11 Feb 2007, Ming Liu wrote: > In the end, it shows 996Mb/sec, which means the throughput is 996Mbps(almost > gigabit), right?
yes.. :) > However I don't think this result is so meaningful because it bypass the > processing for TCP/UDP packets. In the practical implementation, that's not > possible. The TCP/UDP packets have to been processed, right? In fact, this 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). but all theese might be off topic on this list.. > almost gigabit speed is just a representation of the Gigabit ethernet > capability while the bottleneck of the system is not there. So I still need > to solve my practical unsatisfying performance in my design. :( at least it will probably help you narrowing the problem down.. good luck! -- mazsi ---------------------------------------------------------------- strawberry fields forever! [EMAIL PROTECTED] ---------------------------------------------------------------- _______________________________________________ Linuxppc-embedded mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
