[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6D8AF29@saturn3.aculab.com>
Date: Wed, 4 Jan 2012 09:57:01 -0000
From: "David Laight" <David.Laight@...LAB.COM>
To: "Jean-Michel Hautbois" <jhautbois@...il.com>,
<netdev@...r.kernel.org>
Subject: RE: TCP communication for raw image transmission
> I am currently working on a way to send raw images (~400*300 YUV
> 4:2:0) at a relative high speed (raw image and not compressed image
> due to specific codec issues).
> This would represent about 57MBps/sec on a 100Mbps ethernet link.
> This link is direct, nothing else will pass through it.
...
> I was thinking about using TCP socket (of course) ...
I'm not sure you get any benefit from using TCP (over UDP).
If any packets are lost (which on a dedicated network they
shouldn't be) then you probably can't stand the restransmit
delays - especially if the losses are systemic and repeated
in which case you'll occaisionally end up with very slow
throughput (when not enough packets are sent for the
out-of-sequence receives to request retransittions).
The TCP stack also has a series of 'features' that will
reduce the attainable throughput for this kind of traffic:
1) Nagle - easily turned off.
2) Slow start - only a global flag
3) Delayed acks - make 'slow start' more of a problem.
The code paths for UDP (sender and receiver) will be
much shorter, although you'll probably need to ensure
there is adequate buffering.
Also, it should be fairly easy to directly send the UDP
packets from withing the kernel completly bypassing the
normal UDP+IP parts of the network stack!
I know some people have done that completely in hardware
on some FPGA systems with slow cpus.
David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists