ran a simple TCP throughput test on Linux+smoltcp: smoltcp writing, Linux reading. on my laptop the throughput is approx. 2 Gbps. that's without window scaling or jumbo frames, just good old 1500 byte Ethernet frames and 65k socket buffers (smoltcp-side).
-
Show this thread
-
The bottleneck appears to be *squints at `htop`* dumpcap?! Okay let's try this again. *squints at `perf top`* *drumroll* smoltcp::wire::ip::checksum::data, the TCP/IP one-complement checksum function, at 6% overhead O_o
2 replies 1 retweet 15 likesShow this thread -
Really, with functions like copy_user_enhanced_fast_string and tcp_recvmsg and _raw_spin_lock_bh occupying the `perf top` it's not me who is being slow :P
1 reply 1 retweet 7 likesShow this thread -
Correction: I screwed up and gave the read() syscall a buffer that's too small, with a large buffer I have 8% in smoltcp::wire::ip::checksum::data and 8% more in __memmove_avx_unaligned_erms which is basically just as good
2 replies 1 retweet 11 likesShow this thread -
If Linux is sending instead of receiving I get 4 Gbps instead of 2.5 Gbps, probably because it doesn't have nf_conntrack overhead anymore
1 reply 2 retweets 9 likesShow this thread -
"You can't use a memory-safe language to write a high-performance TCP/IP stack" they said, meanwhile there are exactly zero occurences of `unsafe` in smoltcp
4 replies 36 retweets 127 likesShow this thread -
Replying to @whitequark
That claim smells bad. Why should anything a TCP stack does be memory-unsafe?
1 reply 0 retweets 1 like -
But memory-unsafety doesn't make things fast. Rather it precludes optimizations. *sigh*
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.