Re: [lwip-users] inet_chksum.c misbehaving with compiler optimisation?

[FreeRTOS Info]

On 22/11/2011 20:13, address@hidden wrote:
> FreeRTOS Info wrote:
>> Just in case anybody is watching this thread:
>>
>> As unlikely as this all seems, having previously isolated one file, I
>> have now isolated it to a single function: lwip_standard_chksum().
>>
>> I have the entire applicatino running at maximum optimisation, except
>> this function, and everything is happy.
>>
>> Put the lowest optimisation on just this single function (which is now
>> in its own file), and the network works, but with a lot of corruption on
>> the wire.
> Like Kieran and Stephen, I wouldn't rule out the possibility of a timing
> issue, too. Especially since checksumming was the most time consuming
> task in lwIP when I last benchmarked (aside of memcpy, but I guess you
> haven't changed the amount of optimization of memcpy in your tests as it
> often comes precompiled with the C library).
> 
> Nevertheless, to prove the function fails, why don't you run a test on
> random data comparing the results of the optimized checksum function
> with a non-optimized version? You can even let that test run for a while
> if you put the two functions into the same binary. If it's a compiler
> bug or anything in that area, this test should show it.
> 
> BTW: what do mean with 'a lot of corruption on the wire', invalid
> checksums or more errors?

Ok, as would hopefully be expected, checksumming dummy arrays produces
the same result with and without the function in question being
optimised.  That is good, so I should stop going down that dead end.
Thanks for the suggestion, I should have thought to do that myself, doh!

> BTW: what do mean with 'a lot of corruption on the wire', invalid
> checksums or more errors?

There were inexplicable frames in the log of an unknown protocol.
Wireshark was attempting to decode them as xyz or whatever protocol
(nothing I had heard of), but when I looked into the frames using
wireshark they were corrupt anyway.  That was quite concerning, and
first lead me to look at the driver code (which is still looking like a
good candidate).

I have attached the logs as they look now, and they don't show any
strange data at all, but do show the problem with retransmissions.
Good.pcap is without optimisation in the checksuming, bad.pcap is with
optimisation in the checksumming.  192.168.0.200 is the target.

I would be grateful if you could elaborate on the timing theory.  I
presume it is because the speed is causing a resource to be exhausted,
but where shall I look first.  I checked the stats array some time back,
and could not see any error counts incremented.  I also tried to get
some debug prints out, but unfortunately the target I have does not make
that easy without the CPU being held in debug state for the entire print
out (I could write a UART driver and shove the message out there though).

The DMA buffers are squeezed into 16K of RAM.  I could try increasing
those, but there is very little room.

Regards
Richard.

bad.pcap
Description: Binary data

good.pcap
Description: Binary data