|From:||Enrico Murador - Research & Development - CET|
|Subject:||Re: [lwip-users] inet_chksum.c misbehaving with compiler optimisation?|
|Date:||Wed, 23 Nov 2011 14:52:50 +0100|
|User-agent:||Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20111103 Thunderbird/3.1.16|
As Simon said, if checksum calculation is the most time consuming
task in lwIP,|
maybe without optimization the ethernet driver is fast enough to never see more
than one packet at a time; could it be that only with optimization the driver has to
handle more than one packet in the DMA queue, and it fails to do it for some reason?
Sorry if I'm wrong, I'm not so confident with TCP/IP and LwIP, hope it could help anyway...
On 22/11/2011 22.29, FreeRTOS Info wrote:
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._______________________________________________ lwip-users mailing list address@hidden https://lists.nongnu.org/mailman/listinfo/lwip-users
|[Prev in Thread]||Current Thread||[Next in Thread]|