NDIS acting 'bursty' to my miniport (Slow network))

OSR_Community_User · May 3, 2009, 10:47pm

Hi all,

I’m working on an NDIS 5.1 miniport. Browsing, transfers et al works, but very sluggish for the media. I’m seeing about 1MByte/Sec transfers when it should be about 100MByte/Sec. A little spelunking on the wire shows a dozen full, quick sends, then HUGE DEAD TIMES (300~800mSec!), then repeat.

More detail…

There’s a pattern: Tracing huge transfers shows NDIS is acting ‘bursty.’ That is, in random samplings in the middle of a huge file transfer, there is a consistent pattern: About a dozen full packets are QUICKLY sent over the wire via my MpSendPackets(); the Rx end quickly indicates all packets in the order sent. All looks good, then there is a KILLER 300~800 MILLISECONDS OF DEAD TIME (YAGG!). Then, one or two small packets go back the other way, and the bursty process repeats. I’m sure the dead time is not in my MP: All sends and indications are completed, quick and tidy.

Here’s the setup:

The network is symmetric; the same miniport and HW on both ends of the wire
My MP tells NDIS its an 802.3 MP (but the electrical is not 802.3 compliant)
MP is NDIS 5.1 running on XP
MpSendPackets() copies network payload, calls NdisMSendComplete() with the call.
There’s nothing fancy going on, really…

Darn it, I must be overlooking something simple… (The forest is in the way of the damn trees!)

Any thoughts? Things that come to my (tired, frustrated, worn-out) mind:

An OID issue: Like somehow I’m telling NDIS I’m a snail-net
Packet serialization/corruption problem: NDIS quietly (and SLOWLY) corrects it
Maybe I should indicate with NdisMEthIndicateReceivePacket() not NdisMEthIndicateReceive()?

As always, I appreciate any and all perspectives,
Ryan

James_Harper · May 3, 2009, 11:00pm

> Hi all,

I’m working on an NDIS 5.1 miniport. Browsing, transfers et al works,
but very
sluggish for the media. I’m seeing about 1MByte/Sec transfers when it
should
be about 100MByte/Sec. A little spelunking on the wire shows a dozen
full,
quick sends, then HUGE DEAD TIMES (300~800mSec!), then repeat.

More detail…

There’s a pattern: Tracing huge transfers shows NDIS is acting
‘bursty.’ That
is, in random samplings in the middle of a huge file transfer, there
is a
consistent pattern: About a dozen full packets are QUICKLY sent over
the wire
via my MpSendPackets(); the Rx end quickly indicates all packets in
the order
sent. All looks good, then there is a KILLER 300~800 MILLISECONDS OF
DEAD TIME
(YAGG!). Then, one or two small packets go back the other way, and the
bursty
process repeats. I’m sure the dead time is not in my MP: All sends and
indications are completed, quick and tidy.

Here’s the setup:

The network is symmetric; the same miniport and HW on both ends of
the wire

My MP tells NDIS its an 802.3 MP (but the electrical is not 802.3
compliant)

MP is NDIS 5.1 running on XP

MpSendPackets() copies network payload, calls NdisMSendComplete()
with the
call.

There’s nothing fancy going on, really…

Darn it, I must be overlooking something simple… (The forest is in
the way
of the damn trees!)

Any thoughts? Things that come to my (tired, frustrated, worn-out)
mind:

An OID issue: Like somehow I’m telling NDIS I’m a snail-net

Packet serialization/corruption problem: NDIS quietly (and SLOWLY)
corrects
it

Maybe I should indicate with NdisMEthIndicateReceivePacket() not
NdisMEthIndicateReceive()?

As always, I appreciate any and all perspectives,

Where is your tracing taking place? I would first try tracing at both
ends of the network, maybe your receive interrupt isn’t being called in
a timely manner so you aren’t noticing the ACK packets…

James

Maxim_S_Shatskih · May 4, 2009, 4:32am

> Any thoughts? Things that come to my (tired, frustrated, worn-out) mind:

An OID issue: Like somehow I’m telling NDIS I’m a snail-net

Packet serialization/corruption problem: NDIS quietly (and SLOWLY) corrects it

Maybe I should indicate with NdisMEthIndicateReceivePacket() not NdisMEthIndicateReceive()?

the driver’s state machine hangs, NDIS detects it and resets the driver after a timeout
(as James noticed) packets do arrive properly, but the ISR/DPC are delayed to this large time

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Pavel_A1 · May 4, 2009, 5:49am

Can it be that you return NDIS_STATUS_RESOURCES in the send handler?
Also, as Maxim suggested, do you see resets?
( assuming this is not a PHY specific issue that causes packet
loss or corruption that you don’t see on the mac level )
Have you tested with a simpler protocol than IP, or with ndistest,
to detect problems on lower level?

Good luck,
– pa

xxxxx@cruzio.com wrote:

Hi all,

I’m working on an NDIS 5.1 miniport. Browsing, transfers et al works, but very sluggish for the media. I’m seeing about 1MByte/Sec transfers when it should be about 100MByte/Sec. A little spelunking on the wire shows a dozen full, quick sends, then HUGE DEAD TIMES (300~800mSec!), then repeat.

More detail…

There’s a pattern: Tracing huge transfers shows NDIS is acting ‘bursty.’ That is, in random samplings in the middle of a huge file transfer, there is a consistent pattern: About a dozen full packets are QUICKLY sent over the wire via my MpSendPackets(); the Rx end quickly indicates all packets in the order sent. All looks good, then there is a KILLER 300~800 MILLISECONDS OF DEAD TIME (YAGG!). Then, one or two small packets go back the other way, and the bursty process repeats. I’m sure the dead time is not in my MP: All sends and indications are completed, quick and tidy.

Here’s the setup:

The network is symmetric; the same miniport and HW on both ends of the wire

My MP tells NDIS its an 802.3 MP (but the electrical is not 802.3 compliant)

MP is NDIS 5.1 running on XP

MpSendPackets() copies network payload, calls NdisMSendComplete() with the call.

There’s nothing fancy going on, really…

Darn it, I must be overlooking something simple… (The forest is in the way of the damn trees!)

Any thoughts? Things that come to my (tired, frustrated, worn-out) mind:

An OID issue: Like somehow I’m telling NDIS I’m a snail-net

Packet serialization/corruption problem: NDIS quietly (and SLOWLY) corrects it

Maybe I should indicate with NdisMEthIndicateReceivePacket() not NdisMEthIndicateReceive()?

As always, I appreciate any and all perspectives,
Ryan

Pavel_A1 · May 4, 2009, 6:21am

NDIS will not fix corruption or change packet order.
And yes, NdisMIndicateReceivePacket is recommended
for ndis5 drivers, rather than NdisMEthIndicateReceive.

regards,
–pa

Pavel A. wrote:

Can it be that you return NDIS_STATUS_RESOURCES in the send handler?
Also, as Maxim suggested, do you see resets?
( assuming this is not a PHY specific issue that causes packet
loss or corruption that you don’t see on the mac level )
Have you tested with a simpler protocol than IP, or with ndistest,
to detect problems on lower level?

Good luck,
– pa

xxxxx@cruzio.com wrote:
> Hi all,
>
> I’m working on an NDIS 5.1 miniport. Browsing, transfers et al works,
> but very sluggish for the media. I’m seeing about 1MByte/Sec transfers
> when it should be about 100MByte/Sec. A little spelunking on the wire
> shows a dozen full, quick sends, then HUGE DEAD TIMES (300~800mSec!),
> then repeat.
>
> More detail…
>
> There’s a pattern: Tracing huge transfers shows NDIS is acting
> ‘bursty.’ That is, in random samplings in the middle of a huge file
> transfer, there is a consistent pattern: About a dozen full packets
> are QUICKLY sent over the wire via my MpSendPackets(); the Rx end
> quickly indicates all packets in the order sent. All looks good, then
> there is a KILLER 300~800 MILLISECONDS OF DEAD TIME (YAGG!). Then, one
> or two small packets go back the other way, and the bursty process
> repeats. I’m sure the dead time is not in my MP: All sends and
> indications are completed, quick and tidy.
>
> Here’s the setup: - The network is symmetric; the same miniport and
> HW on both ends of the wire - My MP tells NDIS its an 802.3 MP (but
> the electrical is not 802.3 compliant)
> - MP is NDIS 5.1 running on XP
> - MpSendPackets() copies network payload, calls NdisMSendComplete()
> with the call.
> - There’s nothing fancy going on, really…
>
> Darn it, I must be overlooking something simple… (The forest is in
> the way of the damn trees!)
>
> Any thoughts? Things that come to my (tired, frustrated, worn-out) mind:
> - An OID issue: Like somehow I’m telling NDIS I’m a snail-net
> - Packet serialization/corruption problem: NDIS quietly (and SLOWLY)
> corrects it
> - Maybe I should indicate with NdisMEthIndicateReceivePacket() not
> NdisMEthIndicateReceive()?
>
>
> As always, I appreciate any and all perspectives,
> Ryan

OSR_Community_User · May 4, 2009, 4:45pm

My thanks to James, Maxim, Pavel…

<> To make a long story short, my PCI BAR mapping methods were wrong. My call to MmMapIoSpace() requires MmWriteCombined caching flag. (I did NOT figure that out on my own!)

Using MmWriteCombined instantly remedied performance issues. (Yep, the network hardware is kind of a write-only, push model kind of thing. Very insteresting stuff.)

My apologies to all, as I erroneously believed the problem as an NDIS/MP problem, not a hardware access problem.

I’ll do my best to make it up to you,
Ryan

Pavel_A1 · May 5, 2009, 7:03am

xxxxx@cruzio.com wrote:

<> To make a long story short, my PCI BAR mapping methods were wrong. My call to MmMapIoSpace() requires MmWriteCombined caching flag. (I did NOT figure that out on my own!)
> Using MmWriteCombined instantly remedied performance issues. (Yep, the network hardware is kind of a write-only, push model kind of thing. Very insteresting stuff.)

It’s quite unusual…
– pa