On Fri, Jan 05, 2001 at 03:09:45PM +0100, Christian Gennerat wrote:
> kernel 2.4.0.15mdk + change-speed patch ed.2 + irnet.v5 patch
>
> on irnet2 (Libretto 50) irtty=/dev/ttyS0
> - netserver
> - ping irnet1
> on irnet1 (Libretto 100) toshoboe-2.13
> - batch with netperf -H irnet2
[...]
> when netperf is working with default data, ping make no error, sometimes one error.
> when netperf is working with a zipped file, ping make many errors
[...]
> 64 octets from 1.2.0.187: icmp_seq=115 ttl=255 time=1979.6 ms
> wrong data byte #0 should be 0x17 but was 0x1616 df 54 3a ee b6 7 0
> 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25
>26 27
> 28 29 2a 2b 2c 2d 2e 2f
When you use compressed data, as netperf send only zero, you
are mostly testing the speed of the compression and you don't really
saturate the link. With uncompressed data, on the other hand, you are
stressing the IrDA link.
The fact that the packet managed to come back to the ping
application means that the header were correct (IP recognise that it
was an ICMP packet with the right IP address), but the payload is
corrupted.
If you look within IrNET, you will see that the transmit and
receive path are pretty lean and the data is not copied or modified. I
don't really think the IrDA stack would do that as well.
Which leaves us with the hardware... I've seen enough weird
things with the Wavelan to believe I should blame the hardware...
But please prove me wrong...
Jean
_______________________________________________
Linux-IrDA mailing list - [EMAIL PROTECTED]
http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda
