Re: udp packet drops when size exceeds mtu

Carefully check the values you return for OID_GEN_MAXIMUM_FRAME_SIZE
and OID_GEN_MAXIMUM_TOTAL_SIZE and if you actually support them.

AFAIK, TCP does not make use of the maximum possible frame size but
UDP does.

Stephan

On Thu, 7 Feb 2002 8:47:22, xxxxx@wipro.com wrote:

Hello,

I am currently maintaining a NDIS Mac lan-emulation driver for an
underlying ATM 622Mbps adapter for NT4. During udp data transfer of size
greater than mtu size, applications (like ttcp -u) do not receive any
packets. Perfmon shows huge number of IP reassembly errors. But if the
packets are below the mtu size and in case of TCP traffic of any packet
size, everything works fine.

As same ttcp application can receive TCP traffic passed up by the driver, I
am not sure if the bug lies in the driver.

Can any one tell me if there are any known limitations of Microsoft’s
UDP/IP stacks in case of high data rates. If any one has faced simillar
problems, please tell me how to improve the receiver’s rate.

Regards,
Vinay.


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

Get NDIS Tester and run it against your driver:

ftp://ftp.microsoft.com/services/whql/ndis/

“ndt391.exe” is good for W2K.

Test Kits page is here:

http://www.microsoft.com/hwtest/testkits/default.asp?kit=network

Stephan

On Fri, 8 Feb 2002 5:2:1, xxxxx@wipro.com wrote:

Thanks for replying Stephan.

I checked the values for the OIDs, but my amateur eye, didn’t catch any
thing wrong. So here’s the values that I am returning. The MTU size is
9180.

case OID_GEN_MAXIMUM_LOOKAHEAD:
genericUlong = 9180 - ETHER_HEADERSIZE;
break;
case OID_GEN_MAXIMUM_FRAME_SIZE:
genericUlong = 9180 - ETHER_HEADERSIZE;
break;
case OID_GEN_MAXIMUM_TOTAL_SIZE:
genericUlong = 9180;
case OID_GEN_TRANSMIT_BUFFER_SPACE:
genericUlong = 9180 * 8;
break;
case OID_GEN_RECEIVE_BUFFER_SPACE:
genericUlong = 9180 * 8;
break;
case OID_GEN_TRANSMIT_BLOCK_SIZE:
genericUlong = 9180;
break;
case OID_GEN_RECEIVE_BLOCK_SIZE:
genericUlong = 9180;
break;
case OID_GEN_CURRENT_LOOKAHEAD:
genericUlong = 9180 - ETHER_HEADERSIZE;
break;

Now, the docs say something about OID_GEN_RECEIVE_BLOCK_SIZE returning
values identical to OID_GEN_MAXIMUM_LOOKAHEAD, in case the “driver supports
multipacket receive indications”. What does multi-packet receive
indications mean?

Can any one tell me, if any of the values that I am returning are wrong and
are causing UDP packets greater than MTU size to be dropped.

Thanks,
Vinay.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Stephan Wolf
Sent: Thursday, February 07, 2002 7:57 PM
To: NT Developers Interest List
Subject: [ntdev] Re: udp packet drops when size exceeds mtu

Carefully check the values you return for OID_GEN_MAXIMUM_FRAME_SIZE
and OID_GEN_MAXIMUM_TOTAL_SIZE and if you actually support them.

AFAIK, TCP does not make use of the maximum possible frame size but
UDP does.

Stephan


On Thu, 7 Feb 2002 8:47:22, xxxxx@wipro.com wrote:
>
>Hello,
>
>I am currently maintaining a NDIS Mac lan-emulation driver for an

>underlying ATM 622Mbps adapter for NT4. During udp data transfer of size

>greater than mtu size, applications (like ttcp -u) do not receive any

>packets. Perfmon shows huge number of IP reassembly errors. But if the
>packets are below the mtu size and in case of TCP traffic of any packet
>size, everything works fine.
>
>As same ttcp application can receive TCP traffic passed up by the driver,
I
>am not sure if the bug lies in the driver.
>
>Can any one tell me if there are any known limitations of Microsoft’s
>UDP/IP stacks in case of high data rates. If any one has faced simillar
>problems, please tell me how to improve the receiver’s rate.
>
>Regards,
>Vinay.


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

I assume the missing “break” in this message is actually there in the code.

++PLS

-----Original Message-----
From: xxxxx@wipro.com [mailto:xxxxx@wipro.com]
Sent: Thursday, February 07, 2002 5:00 PM
To: NT Developers Interest List
Subject: [ntdev] Re: udp packet drops when size exceeds mtu

Thanks for replying Stephan.

I checked the values for the OIDs, but my amateur eye, didn’t catch any
thing wrong. So here’s the values that I am returning. The MTU size is
9180.

case OID_GEN_MAXIMUM_LOOKAHEAD:
genericUlong = 9180 - ETHER_HEADERSIZE;
break;
case OID_GEN_MAXIMUM_FRAME_SIZE:
genericUlong = 9180 - ETHER_HEADERSIZE;
break;
case OID_GEN_MAXIMUM_TOTAL_SIZE:
genericUlong = 9180;
case OID_GEN_TRANSMIT_BUFFER_SPACE:
genericUlong = 9180 * 8;
break;
case OID_GEN_RECEIVE_BUFFER_SPACE:
genericUlong = 9180 * 8;
break;
case OID_GEN_TRANSMIT_BLOCK_SIZE:
genericUlong = 9180;
break;
case OID_GEN_RECEIVE_BLOCK_SIZE:
genericUlong = 9180;
break;
case OID_GEN_CURRENT_LOOKAHEAD:
genericUlong = 9180 - ETHER_HEADERSIZE;
break;

underlying ATM 622Mbps adapter for NT4. During udp data transfer of size

greater than mtu size, applications (like ttcp -u) do not receive any

packets. Perfmon shows huge number of IP reassembly errors. But if the
packets are below the mtu size and in case of TCP traffic of any packet
size, everything works fine.

As same ttcp application can receive TCP traffic passed up by the driver,
I
am not sure if the bug lies in the driver.

Can any one tell me if there are any known limitations of Microsoft’s
UDP/IP stacks in case of high data rates. If any one has faced simillar
problems, please tell me how to improve the receiver’s rate.

Regards,
Vinay.


You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@ticketmaster.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.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