UDP packet not sent --- test results

[Rolf Schroedter]

Greg's suggestion to exercise all packet sizes lead to
the following results with RTEMS4.6b + LEON(open_eth):

Test:
- For SIZE = MIN to MAX
       send NUM packets of SIZE bytes

Result:
- There are a few "magic boundaries" of UDP packet sizes
     982, 1238, 1366, 1430, 1462
- Adding a 42 byte overhead on the wire (according to ETHEREAL):
     1024, 1280, 1408, 1472, 1504
     0x400, 0x500, 0x580, 0x5C0, 0x5E0

1. Stable results if NUM is not too small (I used NUM=19).
2. When the size crosses "magic boundaries" (downwards or upwards)
    then the output stalls (no more data is sent).
3. No problems for UDP packet sizes below 982 (1024 on the wire)
    have been observed.
4. The output also stalls after a while when sending UDP packets of
    random sizes.

It would be great if somebody could try to reproduce the problem
with another ethernet hardware.

Thanks,
Rolf.

gregory.menke at gsfc.nasa.gov wrote:

> Rolf Schroedter writes:
>  > gregory.menke at gsfc.nasa.gov wrote:
>  > > Ah, I see- thats a different problem.  In your udpclose function, you
>  > > call the various rtems_ info functions.  If you call them before and
>  > > after the packets are lost, are the lost packets being properly
>  > > counted?
>  > > 
>  > > Its not inconceivable theres a bug in the driver, but I would not
>  > > suspect one in the IP stack itself.
>  > > 
>  > Hallo Gregory,
>  > unfortunately I'm not able to reply to you from home.
>  > Your gsfcrelay4.gsfc.nasa.gov blocks my web.de
> 
> Our email system does very strange things sometimes, sorry about that.
> 
> Unless I'm mistaken, the log doesn't show the packet tx count at the
> driver- which I think is what we need for a hint as to where the
> packets are being lost.  You have the tx count at the application
> layer- so thats what the driver's count will compare to.
> 
> Given your simple topology, I'm suspecting the driver.  Could you
> write a program to exercise all packet lengths between say ~100 to
> ~1450, so we can see if there are periodic trouble spots?
> 
> I'm in the middle of the run-up to a major deliverable, so I can't
> devote much time this week.  Next week will be a big relief... and
> I'll be happy to help then.   :)
> 
> Gregm
> 
> 

-- 

---------------------------------------------------------------
Rolf Schroedter
German Aerospace Center
Institute of Space Sensor Technology and Planetary Exploration
D-12489 Berlin, Rutherfordstrasse 2
Tel/Fax:  (+49) (30) 67055-416/384
Email:    Rolf.Schroedter at dlr.de
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tcp_config.h
URL: <http://lists.rtems.org/pipermail/users/attachments/20031113/2b2c7ac1/attachment-0001.h>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rtems_tudp.c
URL: <http://lists.rtems.org/pipermail/users/attachments/20031113/2b2c7ac1/attachment-0001.c>