I installed Microsoft NDIS Intermediate sample driver and PCAUSA PcaSim
(passthru) on my Windows NT 4.0 (SP6) and I am surprised by the bandwidth
degradation. I tried to upload and download one big file from the FTP
server on my LAN and I saw that the both drivers include additional delay
during the receive of about 10%. During the file upload the additional
delay is neglecting, but during the download it is obvious. Does anybody
knows what is the source of this behavior?
Miodrag Bazdar
QuesCom S.A.
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
When you insert a NDIS Intermediate (IM) driver into the path between a NDIS
transport driver (such as TCP/IP) and the lower NDIS miniports that the
transport is bound to you will incur extra overhead.
I am not fully aware of the extra work involved within the NDIS wrapper
itself, but it is more then just a simple “jump” to the extra functions. In
addition, NDIS imposes a minimim requirement to “re-wrap” original NDIS
packets in a new packet descriptor (NDIS_PACKET). In addition, NDIS IM
drivers that are more then trivial (i.e., which compress/encode, etc) must
make complete copies of the packet data - which requires even more work.
I am supprised at the performance degradation that you observed. Normally it
is “measurable”, but not “significant”.
There are other approaches to packet filtering besides NDIS IM drivers. The
“NDIS-hooking” approach hooks certain functions in the NDIS wrapper and in
the NDIS transports Protocol Characteristics table. Having done this, the
NDIS-hooking driver’s “hook” functions are called in a much simpler manner
then in an NDIS IM driver.
The major “downside” of a NDIS-hooking driver is that on Windows NT, Windows
2000 and Windows XP the hooking mechanism is implemented using techniques
that are most often used in a debugger. Although these techniques are highly
reliable, their use in a commercial product might prevent WHQL acceptance
(if that is an issue for you).
Good luck,
Thomas F. Divine
PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - NDIS Intermediate - TDI Client/Filter
http: - http:
----- Original Message -----
From:
To: “NT Developers Interest List”
Sent: Thursday, November 22, 2001 12:22 PM
Subject: [ntdev] Intermediate NDIS driver Performances
> I installed Microsoft NDIS Intermediate sample driver and PCAUSA PcaSim
> (passthru) on my Windows NT 4.0 (SP6) and I am surprised by the bandwidth
> degradation. I tried to upload and download one big file from the FTP
> server on my LAN and I saw that the both drivers include additional delay
> during the receive of about 10%. During the file upload the additional
> delay is neglecting, but during the download it is obvious. Does anybody
> knows what is the source of this behavior?
>
> Miodrag Bazdar
> QuesCom S.A.
>
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com</http:></http:>
> ----------
From: xxxxx@pcausa.com[SMTP:xxxxx@pcausa.com]
Reply To: xxxxx@lists.osr.com
Sent: Thursday, November 22, 2001 7:28 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: Intermediate NDIS driver Performances
I am supprised at the performance degradation that you observed. Normally
it
is “measurable”, but not “significant”.
Me too. Normally, the only factor which significantly influences network
speed is internal packet processing as encryption or compression. It may
depend on CPU frequency but even on old Pentium 90 I haven’t noticed 10%
network speed degradation when encryption was turned off. Maybe there is
another problem (low memory and driver consumes too much which impacts whole
system?).
Strange. It would be interesting to know hw configuration (1 GHz Ethernet?
:).
The major “downside” of a NDIS-hooking driver is that on Windows NT,
Windows
2000 and Windows XP the hooking mechanism is implemented using techniques
that are most often used in a debugger. Although these techniques are
highly
reliable, their use in a commercial product might prevent WHQL acceptance
(if that is an issue for you).
Might prevent? Maybe there is a small chance they wouldn’t notice hooking
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
----- Original Message -----
From: “Michal Vodicka”
To: “NT Developers Interest List”
Sent: Thursday, November 22, 2001 2:16 PM
Subject: [ntdev] Re: Intermediate NDIS driver Performances
> > ----------
> > From: xxxxx@pcausa.com[SMTP:xxxxx@pcausa.com]
> > Reply To: xxxxx@lists.osr.com
> > Sent: Thursday, November 22, 2001 7:28 PM
> > To: xxxxx@lists.osr.com
> > Subject: [ntdev] Re: Intermediate NDIS driver Performances
> >
> > The major “downside” of a NDIS-hooking driver is that on Windows NT,
> > Windows
> > 2000 and Windows XP the hooking mechanism is implemented using
techniques
> > that are most often used in a debugger. Although these techniques are
> > highly
> > reliable, their use in a commercial product might prevent WHQL
acceptance
> > (if that is an issue for you).
> >
> Might prevent? Maybe there is a small chance they wouldn’t notice hooking
>
>
Yes, certainly the use of debugger technoques might be overlooked, and the
technique is used in successful commercial products.
However, it would be bad not to mention up front that WHQL certification as
a potential problem…
In some cases hooking is the only solution that works.
Thos
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> that are most often used in a debugger. Although these techniques are highly
reliable, their use in a commercial product might prevent WHQL acceptance
(if that is an issue for you).
This is very bad that MS did not officially support NDIS hooks.
IM driver (completely virtual adapters based on real ones in some way, maybe not 1-to-1) seems to be overkill for many tasks.
IM can be necessary for load balancing or such, but for firewalls? Sorry, even stateful firewalls would live OK with NDIS hooks.
Max
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> ----------
From: xxxxx@storagecraft.com[SMTP:xxxxx@storagecraft.com]
Reply To: xxxxx@lists.osr.com
Sent: Thursday, November 22, 2001 8:38 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: Intermediate NDIS driver Performances
> that are most often used in a debugger. Although these techniques are
highly
> reliable, their use in a commercial product might prevent WHQL
acceptance
> (if that is an issue for you).
This is very bad that MS did not officially support NDIS hooks.
IM driver (completely virtual adapters based on real ones in some way,
maybe not 1-to-1) seems to be overkill for many tasks.
IM can be necessary for load balancing or such, but for firewalls? Sorry,
even stateful firewalls would live OK with NDIS hooks.
For w2k and above NDIS filter driver is a good solution where 1-1 is
sufficient (should be for firewalls). They solved the worst problem,
installation and the mess with virtual adapters and bindings. To write hook
driver it is necessary to understand NDIS well and the result driver is very
similar to IM driver. Why MS should support two equivalent solutions? Hook
drivers are superior in environment where are problems with installation as
w9x and NT4 OSes.
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com