On Monday, December 17, 2007 Alexander Pevzner wrote: > 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.
Yes; in high-performance scenarios Windows select() is a disaster. It is quite possible that your approach would yield some results, too - but I did not check it. I got pulled into this when the guys trying to send these 100K UDP packets per second already tried some IO completion approach and told me that it did not work, so I just took it at face value and did not even try anything Windows-fancy myself. But it is a useful thing to keep in mind - thank you for telling us! Though it is, of course, equally possible that even though this works for 16 mbit/s or even 16 mbyte/s stream, there would be some problem with a gigabit (and besides, in your case the problem was to receive this data, whereas we had to send it, which might be exposing a whole different set of bugs in Winsock implementation :-) Best wishes - S.Osokine. 17 Dec 2007. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Pevzner Sent: Monday, December 17, 2007 7:01 AM To: [email protected] Subject: Re: [p2p-hackers] MTU in the real world 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 _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
