You're right still there're lazy fruits for optimizations (like expanding MTU), but there're still a lot of limitations e.g. TCP and IP packets options (especially first one). You're able get them from socket stack only via set/getsockopt system calls.Sasquatch wrote:But a drop from, let's say 500 KB/s, to only 10% of that is not normal. Even if you would go from one network stack to another, you should not have an overhead of 90%. Usually, an overhead of 10% is normal. I don't have much experience with other network stacks, but every computer runs TCP/IP, so that should not be the problem for the TS. And it doesn't explain why it's fast from the start, but slows down later.Hachiman wrote:It could be if NAT engine being the TCP/IP stack communicating with HOST network stack by Ethernet or other type of packets, instead of operating with socket interface (which massively interact host TCP/IP stack)Sasquatch wrote: NAT isn't that slow. It's only a tiny bit slower, because of the additional translation step, but shouldn't be any slower than when you use a router for your internet connection for the Host, compared to direct connection and NAT on the Guest.
About fading speed, it isn't really fade I've admired wave character, that could be influenced by connections that not closed (waiting to be closed), actually select and WSAWaitForMultipleEvents are sensitive to number of serviced connections.
