Time difference between two received packets in NDIS Intermediate Driver

Hi,
I am working on a 1:2 IM driver. I will be receiving the same message (Redundant frames) on both my adapters. Could any one please guide me on how to calculate the time difference between the reception of two redundant frames in my NDIS IM driver.

Any help would be highly appreciated. Thanks!

With Regard,
Subashini

DISCLAIMER:

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.


Perhaps I don?t understand what you want but it seems trivially obvious to
me that you would just timestamp the packets in your protocol receive path.

In NDIS5 you could first check the packet OOB data to see if the NIC
Miniport was nice enough to timestamp the frame for you. On this is the
aptly named NDIS_GET_PACKET_TIME_RECEIVED() macro.

If you do not trust that this time is relevant and/or correlated to between
the packet streams well enough for your needs then of course you could
always ask the system for the current ?time? with NdisGetCurrentSytemTime().

You might just be best to assume you have to collect a timestamp for each
frame yourself (saved in your own protocol private data in the packet or
netbufferlist). On NDIS6x systems that translate between NET_BUFFER and
NDIS_PACKET at various points, I suspect (not verified, however) that the
OOB data viewed from NDIS5 drivers might not end up with the time-received
OOB being filled in. I don?t recall that NDIS6 has an equivalent ?OOB?
property associated with a NET_BUFFER_LIST for a receive timestamp (perhaps
someone else can correct this statement if needed).

Of course, once you have both frames ?in hand? you can just simply calculate
the difference between them. This completely ignores the issues (specific
to your application, whatever it might be) of identifying which frames from
each stream (adapter) are ?matched? and thus need to be compared.

Good Luck,

Dave Cattley

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Subashini
Venkatapathy ,Chennai
Sent: Friday, September 04, 2009 6:11 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Time difference between two received packets in NDIS
Intermediate Driver

Hi,

I am working on a 1:2 IM driver. I will be receiving the same message
(Redundant frames) on both my adapters. Could any one please guide me on how
to calculate the time difference between the reception of two redundant
frames in my NDIS IM driver.

Any help would be highly appreciated. Thanks!

With Regard,

Subashini


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

DISCLAIMER:


The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its
affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect
the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of
this message without the prior written consent of the author of this e-mail
is strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. Before opening any mail and
attachments please check them for viruses and defect.



Ah, yes a DuplicationManager. We’ve done a 2:2 IM in NDIS5.x and a 1:2 IM on NDIS6.x. First what is your philosophy on duplicate packets? Ours is we would rather drop a packet than have any duplicates, which is fine for TCP/IP but has problems with Multicast/Broadcast that must be taken care of in the applications that use them.

Unless you have both ports connected to the same HUB the only duplicate packets should be Multicast/Broadcast, even with the NICs confiured to promiscuous. When connected to switches you will not get all Multicast on both adapters unless you have your driver sends the join group packets on both adapters.

We gave up on the trying to time stamp packets and finding it’s mate. Unless the NIC does the receive timestamp, which we found most NICs don’t, doing the timestamp yourself in the IM will cause a lot on packets to have the same timestamp whenever there is a burst of packets or even a moderate load. Finding the mate to any packet is akin to “Where’s Waldo?”.

The simplest method for Multicast/Broadcast is to have a method for knowing the connect status of your NICs and choose one to be primary. Whenever both NICs are connected and good, pass the primary packets up and drop them on the secondary. Your method needs to let your IM know when the primary NIC is not good so the packets on the secondary can be passed up. Your method must also consider how to handle packets when the primary comes back good, there is an overlap that needs to be handled.

Good luck.

Larry C

Thank you so much for your guidance. Yes Larry, this is for managing the duplicate packets. In my case i have to drop a packet if the duplicate packet is received within 0.5ms else i have to pass the duplicate packet also to the TCP/IP layer. Would you please tell me what would be the best way to handle this scenario.

I missed to add that i am working on NDIS 5.1. Thanks!

With Regards,
Subashini

What it means is that you need to have 0.5ms of ‘memory’ in your receive
path so that you can detect that a packet ‘has already been received’ within
the memory window.

I do not recommend that you actually keep the packet since you most often
will be hanging on to resources that are limited and owned by the underlying
NIC.

How you ‘compare’ the packets is up to you. Obviously the most costly
comparison is a equality test of every octet. A suitable hash function
might be chosen in a trade-off of space vs. computation. If you are only
concerned with IP packets (and not ARP, LLC, IPX, etc.) then taking
advantage of the IP header is probably wise. A hash (or copy) of the IP
header ought to be enough to consider a packet a ‘duplicate’ and that is
very likely (actually, required) to be in the first NDIS_BUFFER of an
NDIS_PACKET.

There are many possible ways to organize the ‘memory’ for this function.
Keep in mind that every packet received will have to be ‘inserted’ into this
‘memory’, even if it is a duplicate. Also keep in mind that every packet
will cause a ‘search’ of this ‘memory’ and so both of those operations need
to be efficient. Lastly, you will need to age entries in the ‘memory’ and
remove those that are no longer within the 0.5ms window.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hcl.in
Sent: Saturday, September 05, 2009 10:29 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Time difference between two received packets in NDIS
Intermediate Driver

Thank you so much for your guidance. Yes Larry, this is for managing the
duplicate packets. In my case i have to drop a packet if the duplicate
packet is received within 0.5ms else i have to pass the duplicate packet
also to the TCP/IP layer. Would you please tell me what would be the best
way to handle this scenario.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

A long time ago I used KeQueryPerformanceCounter to stamp packets and correlate between multiple adapters. You have to be aware that the value of the counter is current CPU dependant. The documentation mentions that you should “use this routing as infrequently as possible”, but if you have to compare and contrast with the past 500us of packets, I doubt that KeQueryPerformanceCounter would be your bottleneck.

Collecting statistic in IM driver could not be accurate in any way because this result could be depends on hardware configuration and in some way on software configuration too. The best way of course put statistic stuff in NIC card. But probably it would be in the next generation of network cards.

Igor Sharovar