|
From: | address@hidden |
Subject: | Re: [lwip-users] inet_chksum.c misbehaving with compiler optimisation? |
Date: | Tue, 22 Nov 2011 21:13:20 +0100 |
User-agent: | Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 |
FreeRTOS Info wrote:
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).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.
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?
Simon
[Prev in Thread] | Current Thread | [Next in Thread] |