NDISPROT sample performance (once again)

Hello,

Once again problem with NDISPROT sample from DDK. I've just built that
example and did some tests. I've only increased a SEND_PACKET_POOL_SIZE
RECV_PACKET_POOL_SIZE and MAX_RECV_QUEUE_SIZE values so that I have no
more problems with loosing packets when reading.
The big problem is performance I got with 9k frames average speed 350
MBps (sustained write and read) but maximum about 650 Mbps. Why that
values are so different and how to improve the code to get better
performance, more close to 1 Gbps. I have to get all the packet I do not
want to discard any of them.

Regards,
Bartek

Stephan
Fri May 19 05:32:42 CDT 2006

There are just so many possible reasons to take into account. For
instance, the NIC driver usually has some interrupt moderation
algorithm in order to avoid "one interrupt per frame" interrupt storms.

But interrupt moderation often also implies some latency, i.e. there is
a small time gap between a frame being sent or received and the
"complete" call to the protocol.

See if there are some NIC parameters that can be set in order to
improve performance.

Also, does your test program send frames back-to-back or does it wait
for some acknowledgement from the peer station? The latter usually
implies latency, which can degrade overall throughput a big time.

Sorry, but all these problems have been experienced, analyzed, and
solved before. You are kind of trying to reinvent the wheel.

Stephan
---
misiu wrote:
> Hello,
>
> Once again problem with NDISPROT sample from DDK. I've just built that
> example and did some tests. I've only increased a SEND_PACKET_POOL_SIZE
> RECV_PACKET_POOL_SIZE and MAX_RECV_QUEUE_SIZE values so that I have no
> more problems with loosing packets when reading.
> The big problem is performance I got with 9k frames average speed 350
> MBps (sustained write and read) but maximum about 650 Mbps. Why that
> values are so different and how to improve the code to get better
> performance, more close to 1 Gbps. I have to get all the packet I do not
> want to discard any of them.
>
> Regards,
> Bartek

misiu
Fri May 19 10:09:07 CDT 2006

Stephan Wolf [MVP] wrote:
[...]
>
> Sorry, but all these problems have been experienced, analyzed, and
> solved before. You are kind of trying to reinvent the wheel.

Maybe that is right. So where I could find the solution or even some
advices for sending and receiving raw frames with 1 Gbps speed on the
assumption that my hardware is fast enough?


Best regards,
Bartek

Stephan
Fri May 19 18:09:47 CDT 2006

misiu wrote:
> Maybe that is right. So where I could find the solution or even some
> advices for sending and receiving raw frames with 1 Gbps speed on the
> assumption that my hardware is fast enough?

Hmm, well, as I said before the TTCP tool with UDP (usually the -u
parameter) should get to 1 Gbps. Try WSTTCP or some other
implementation of TTCP for Windows.

If you do not have a TTCP for your sending device and/or need to save
and analyze the data sent by your device the maybe simply use a sniffer
like Ethereal or Packetyzer to capture the data and write it to a file.
These tools AFAIK support several capture file formats and most of them
are well documented.

If you need to also establish some communication between your sending
device and the Windows machine, you could run the sniffer on a second
machine in order to avoid loosing frames. Connect all three to the same
GigE switch and set the switch to "analyze" or "mirror" mode on the
sniffer port in order to be able to catch all traffic.

Stephan

Pankaj
Sat May 20 01:53:16 CDT 2006

I had problem with dropped incoming packets with NdisProt. The way i solved
it (with advice from Thomas F Divine) is that i queue around 32 requests for
receiving incoming packets and then use ReadFileEx function to
asynchronously receive packets. As soon as i receive the packet, i queue
another request to try and keep enough pending reads to receive all the
incoming packets.

I did not test on Gigabit though, only 100Mbps.

Another thing you may want to see is your CPU usage. If you max out on CPU
then you will anyways drop packets.

--
Pankaj Garg
This posting is provided "AS IS" with no warranties and confers no rights.


"misiu" <misiu75@onet.eu> wrote in message news:e4k2q5$brj$1@news.onet.pl...
> Hello,
>
> Once again problem with NDISPROT sample from DDK. I've just built that
> example and did some tests. I've only increased a SEND_PACKET_POOL_SIZE
> RECV_PACKET_POOL_SIZE and MAX_RECV_QUEUE_SIZE values so that I have no
> more problems with loosing packets when reading.
> The big problem is performance I got with 9k frames average speed 350
> MBps (sustained write and read) but maximum about 650 Mbps. Why that
> values are so different and how to improve the code to get better
> performance, more close to 1 Gbps. I have to get all the packet I do not
> want to discard any of them.
>
> Regards,
> Bartek