- This topic has 1 reply, 2 voices, and was last updated 18 years ago by
.
-
Posts
-
I noticed following strange behaviour when WinpkFilter is used in conjuction with several NICs (Ethernet: Realtek 8139, 3COM 3C940 WLAN: Broadcom BCM4318, Texas Instruments ACX100).
When continously sending UDP packets using blocking sockets, e.g. performing a throughput benchmark with TTCP, the sendto() calls return immediately and result in a bogus throughput of 30 – 60 MB/s, whereas only a small fraction of the packets passed to the sockets interface are indeed transmitted by the adapter. The larger fraction of the packets gets lost in the network stack. The bogus rates at which the sokets interface consumes the UDP packets (30 – 60 MB/s as stated above) do not depend on the maximal bandwith of the underlying NIC, they were observed when sending through the two Ethernet NICs (connectesd to a 100 Mbit Switch) as well as when sending through the two WLAN NICs (802.11b mode).
This behaviour is independent of the machine WinpFilter is running on, it is also independent of the UDP packet size and it doesn’t play any role whether WinpkFilter ist just installed (i.e. driver ndisrd is running in idle mode) or actively in use, e.g. by the PassThrough demo application.
However, uninstalling WinpkFilter restores normal UDP sockets behaviour. That means, the sockets interface accepts UDP packets at a rate which does not exceed the possible bandwith offered by the underlying NIC and packets aren’t dropped by the network stack. On a 100 Mbit network, UDP achieves a throughput around 11,5 MB/s and on a 802.11b WLAN around 800 KB/s. These values are marginally below the theoretical throughput of the corresponding network.
It seems that WinpkFilter turns blocking UDP sockets in a nonblocking mode where they accept as many packets as many the CPU can process. The larger fraction of these packets then gets dropped by the network stack because of overfull buffers. Only when using an Intel PRO/100B Ethernet NIC (the 5th card I tested), the UDP sockets behave the normal way, but only when WinpkFilter is running in idle mode. When the PassThrough demo application gets activated on this NIC, the UDP sockets again turn into nonblocking absorbers which drop the greatest part of the passed packets.
As you can see, I peformed tests with 5 NICs and only when using one of them and having WinpkFilter in idle mode the UDP sockets interface behaved normally.
It is interesting to note that when using TCP no strange behavior of WinpkFilter was observed on any of the NICs. I know that TCP uses flow and congestion control, but monitoring a TCP session with Ethereal revealed that there weren’t any retransmissions or duplickate ACKs. That means there weren’t any data pieces which got lost in the network stack in contranst to using UDP.
I hope, that someone can give a reasonable explanation of this phenomenon and maybe suggest a workaround. Usually an application can expect that all UDP packets it passes to sendto() get transmitted by the NIC, especially when there is any other network traffic originated by the same machine.
Many thanks in advance, Max.
WinpkFilter has an internal packet pool for 500 packets. This size was chosen according real networking requirements and can be changed. If this pool is too large it is just waisting of memory, if it is too small it may decrease real network performance. In your test cases these 500 packets were not enough for such high sending rate and many packets were just dropped by WinpkFilter.
TCP is very different from UDP, it won’t send more packets than fit in maximum window size before receiving receipt confirmation. So such situation like you got with UDP is not possible.
- You must be logged in to reply to this topic.