Serguei Osokine wrote: > I mean, if the socket would try to block, then some extra time > would be spent on select() calls (as I saw happening when I tried to > call the blocking sendto() only after select() was giving me the go- > ahead signal; this was only increasing the thread overhead without > affecting the sendto() timing or CPU use). And if the socket would > not try to block, then what is the difference between blocking and > non-blocking timing, right?
Please note, select() usage is extremely expensive on Windows. I was working on a video streaming software, and in my tests I was sending a 16 mbps stream using ~1K UDP datagrams, from Linux server to Windows client. Both client and server had a very similar architecture - a finite state machine, rolling loop around select(). I have noticed a very high CPU usage at Windows client - about 15%, while at Linux server side CPU usage was about 0%, regardless of very similar API usage pattern, After replacing select() at the Windows side with a combination of WSAEventSelect() and WSAWaitForMultipleEvents(), the CPU usage went down to 3%. It was quite acceptable, so I had no time to investigate any further. There are also other interesting issues with UDP handling by Windows. In particular: * by default, receive buffer is exceptionally small. I had to increase it up to 64K (by setsockopt( ... SOL_SOCKET, SO_RCVBUF ...)), to avoid massive packet loss. * even after that, GUI activity could interrupt a receiver for enough time to loose a number of packets. Increasing task priority helps a lot, but even a realtime task can be interrupted by Windows for a very noticeable time, though it doesn't happen too often. * my network bandwidth estimation algorithm measured a delay between subsequent packets reception. It yields quite good accuracy, but sometimes received packet gets stuck inside of Windows network stack for a hundreds of microseconds, even on idle system. Unfortunately I had no time to investigate, so I just had to filter out inaccurate measures. _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
