On Sat, 27 Oct 2012 16:31:59 +0100 Simon Wilkinson <simonxwilkin...@gmail.com> wrote:
> I do believe that we can make the current RX implementation > significantly faster - and that this will aid both bulk and metadata > operations. However, it is unlikely that we can ever reach the raw > performance of TCP, especially when TCP is aided by in-kernel DMA > splitting packet decoding across multiple cores, and by specialised > firmware in the network cards themselves. Yes, I meant to respond to this part of the 'RX Performance' talk in Edinburgh, but I forgot about it by the time to ask questions came around. I'm sure something UDP-based can be faster than TCP given certain conditions. But since so many pieces of networking software and hardware give TCP special treatment and optimizations, practically speaking, I find it unlikely to meet or exceed TCP bandwidth for many real-world scenarios with existing equipment. That is, until Rx becomes popular enough that devices start to have e.g. hardware acceleration for Rx. That doesn't sound very likely. It's possible for a UDP-based protocol to behave very well, and in some situations exceed TCP. I don't think Rx should be such a protocol, since I think we should be focusing on making filesystems instead of researching flow control. Er, not that current speed improvements are unwelcome; it should be faster, but spending the time making it TCP-fast just seems like wasting time reinventing TCP. (Random tidbit: the original request for this project was to use a userspace UDP-based bulk transfer protocol. The only reason I didn't go for that was because it lacked a kernel interface.) -- Andrew Deason adea...@sinenomine.net _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
