On Sat, 22 Nov 2014 13:06:15 EST erik quanstrom <quans...@quanstro.net> wrote: > On Fri Nov 21 12:31:13 EST 2014, ba...@bitblocks.com wrote: > > This paper is well worth reading: > > http://groups.csail.mit.edu/ana/Publications/PubPDFs/1988Analysis%20TCP%20P > rocessing%20Overhead.pdf > > > > While the traditional BSD implementation uses mbufs that complicate things, > actual tcp processing can be done quite cheaply. > > - ignores tcp checksum -- it alone will take a couple cycles per byte.
They factored out path common to all IP, to measure TCP's overhead. tcp checksum is basically IP checksum. > - ignores locking > and i believe they've used the BKL to avoid locking any data structures > , otherwise > how could they process ip in 61 instructions? actually there's proof o > f this in the > timer instruction count -- 17. that's not enough to acquire a lock. Again, matching an incoming packet to find its PCB is common to all so they didn't put this in tcp overhead computation. As long as you run IP, you pay the other costs for any protocol. > - asserts that 300 instructions of x86 code -> 400 instructions of risc code, > conservatively > absolutely not if one of them is rep; movb (which they appear to use) Can't speak to this. > in short, i see signs that this paper is not realistic. I think it is very realistic. They modified standard bsd stack (I don't know its present state but back when I worked on it, it needed to be simplified quite a bit). > furthermore, this sunny picture assumes an environment where tcp isn't giving > any > benefit. if you're not retransmitting a bit, you're not getting anything out > of tcp. If you use TCP you benefit from its near universality, dealing with long fat pipes, bandwidth adjustment, selective ack etc. My point was that even with all its complexity, tcp's processing overhead can be fairly low for the common case. I haven't looked into why on the RPi plan9's tcp performance is about 30-40% of that on linux (which works near wire speed). For the local case it doesn't matter much in any case.
