Re: [lwip-users] How to check send state?
Karl Karpfen wrote: OK, so let me ask this in an different way: Currently I do have data to be sent available in main loop only. How can I enqueue these data into the lwIP-ISR-context correctly so that it can be transmitted without problems? To do that you'd either need to lock interrupts and then call into lwIP (so that you are absolutely sure your ethernet interrupt does not call lwIP code while running it from the main loop) or put your data on a list and soft-trigger an interrupt on the same priority. However, the standard way to handle this is to let the interrupt pull packets off the MAC, put them on a list and let lwIP run from the main loop, too. This way you only need to make the pbuf and mem(p) functions thread-safe, which can be achieved by setting SYS_LIGHTWEIGHT_PROT==1 (plus defining the SYS_ARCH_PROTECT macros correctly) and LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT==1 (to allow the TX-finished interrupt to free PBUF_RAM pbufs from ISR). Currently I'm doing it as described at http://lwip.wikia.com/wiki/Raw/TCPin section Sending TCP data which seems to be wrong for my case... I only get an empty page with this link: This page needs content. You can help by adding a sentence or a photo. Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] How to check send state?
2014-09-17 9:08 GMT+02:00 Simon Goldschmidt goldsi...@gmx.de: Currently I'm doing it as described at http://lwip.wikia.com/wiki/Raw/TCPin section Sending TCP data which seems to be wrong for my case... I only get an empty page with this link: This page needs content. You can help by adding a sentence or a photo. Sorry, it is http://lwip.wikia.com/wiki/Raw/TCP http://lwip.wikia.com/wiki/Raw/TCPin , I forgot the space between the link and the following word in. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] How to check send state?
Karl Karpfen wrote: Currently I'm doing it as described at http://lwip.wikia.com/wiki/Raw/TCPin section Sending TCP data which seems to be wrong for my case... There's nothing wrong with what's described at http://lwip.wikia.com/wiki/Raw/TCP. What's wrong is that your lwIP calls into lwIP from interrupt context and you call it from your main loop. This is not allowed, that's all. Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Context of poll and recv?
Hi, this is a follow-up to How to check send state? but I start a new discussion since it is a new question: I'm trying to enqueue some data into lwIP's send queue that are generated from within my applications main-loop (which is not allowed). Now my solution is to just set a flag and then fetch and enqueue the data out of lwIPs thread context. This is done once periodically within my poll-function (specified by tcp_poll()) and once immediately from within my recv-function (specified with tcp_recv()). My question: are both running in same IRQ-context or are they triggered by different ones so that filling the send buffer this way would lead to troubles too? A check if previously enqueued data are fully send of course is implemented. Thanks for all your kind help :-) ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] How to check send state?
OK, got it - thanks :-) 2014-09-17 11:10 GMT+02:00 Simon Goldschmidt goldsi...@gmx.de: Karl Karpfen wrote: Currently I'm doing it as described at http://lwip.wikia.com/wiki/Raw/TCPin section Sending TCP data which seems to be wrong for my case... There's nothing wrong with what's described at http://lwip.wikia.com/wiki/Raw/TCP. What's wrong is that your lwIP calls into lwIP from interrupt context and you call it from your main loop. This is not allowed, that's all. Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP retransmission flooding at end of stream
goldsi...@gmx.de wrote Which version of lwIP are you using? Do you know that we support TCP window scaling by now (LWIP_WND_SCALE)? Indeed, i forgot this one. Its the version provided by the STM32CubeMX tool. Diff shows its identical to LWIP 1.4.1. I didn't knew that. I guess you refer to patch 7858? I will apply it. goldsi...@gmx.de wrote - I decreased the TCP timer intervals from 250 ms to 10 ms. A even higher rate tends to produce a lot of retransmissions. You should really not need to do this! I rather expect more problems than anything being solved. Especially when your main issue is sending data, not receiving. I've tested again with 250 ms - The only difference in the behavior seems to be a much lower transmission rate. I achieve about 200 kB/s. Krzysztof Wesołowski wrote I am not sure why you decided to go in such extreme direction with your changes. We are almost able to saturate 100MBit connection (8 MB/s) and upload about 2MB/s from SD Card on STM32F407 with RMII attached PHY (Some Micrels KSZ...) Are you using some WiFi in your setup? With Ethernet networks we only needed to tune memory in lwipopts, and there was no need to change types and/or polling interval. Have you benchmarked if the need for optimization really is within LwIP related code? I've started about a month ago porting our STM32F1 based board to the new MCU. The old design had a WizNet W5300 Ethernet IC, implementing the TCPIP Stack in HW. Therefore I'm absolutely not sure, my changes are going in the right direction. However, initially I struggled on very high roundtrip times and a low throughput of about 5 kBit/s. The PC seemed to resend unacknowledged packets after about 200 ms. Also, I'm using the tcp_poll callback to en-queue new data to the stack, in the context of the tcp_thread. For both reasons it seems natural to reduce the intervals. On the other hand, having a bigger SND_WND allows less memory management, outside of the stack, which seems to be quite efficient. Now i can achieve 2 MBit/s (until the error occurs) so yes it seems to be influenced by the stack. (5 kB - 70 kB was achieved, due to the zero copy driver) On the other hand, I guess there still several other regions for improvements. Thanks! -- View this message in context: http://lwip.100.n7.nabble.com/TCP-retransmission-flooding-at-end-of-stream-tp23275p23294.html Sent from the lwip-users mailing list archive at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Context of poll and recv?
Karl Karpfen wrote: [..] My question: are both running in same IRQ-context or are they triggered by different ones so that filling the send buffer this way would lead to troubles too? A check if previously enqueued data are fully send of course is implemented. That *totally* depends on your lwIP port. However, that port has to ensure lwIP code is not executed in parallel, so you should be safe (unless your port does not follow this rule). Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Context of poll and recv?
Great, thanks! :-) :-) :-) 2014-09-17 12:16 GMT+02:00 Simon Goldschmidt goldsi...@gmx.de: Karl Karpfen wrote: [..] My question: are both running in same IRQ-context or are they triggered by different ones so that filling the send buffer this way would lead to troubles too? A check if previously enqueued data are fully send of course is implemented. That *totally* depends on your lwIP port. However, that port has to ensure lwIP code is not executed in parallel, so you should be safe (unless your port does not follow this rule). Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] How to check send state?
There's nothing wrong with what's described at http://lwip.wikia.com/wiki/Raw/TCP. What's wrong is that your lwIP calls into lwIP from interrupt context and you call it from your main loop. This is not allowed, that's all. Thank you Simon Wiki 1 users 0 ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Failed to send TCP data
Your code is too long for me to try to figure out which API you are using and follow your approach. In case you are using the raw API, please check the wiki, and then your code, and if something is not clear then come back to us. I'll try to help http://lwip.wikia.com/wiki/Raw/TCP ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP retransmission flooding at end of stream
Is this the (in)famous ST-lost-frames bug again ? Translation: is your port running on an RTOS with an Rx task fired from Eth interrupt and taking only the first frame out of the chip ? ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Context of poll and recv?
Hi Karl,
I'm not trying to teach you how to do things, but I need to ask you if
there is any reason why you can't rise a flag in your eth rx interrupt
and run all lwIP code from the main loop ? (zero latency ?)
Mine (sort of):
void eth_input(ifc)
{
do {
if(!flag)
break;
p = pbuf_alloc();
get frame;
netif-input(p, ifc);
} while(more frames);
}
main()
{
while(1){
eth_input(myeth);
}
}
void rxint()
{
ack;
set flag;
}
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP retransmission flooding at end of stream
Sergio, Michael Steinecke wrote: The FW Library bug in the Ethernet IRQ, eating fast packets is fixed. So no, this does not seem to be the standard STM issue... Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP retransmission flooding at end of stream
/ The FW Library bug in the Ethernet IRQ, eating fast packets is fixed./ So no, this does not seem to be the standard STM issue... Oh, I see, missed that part. Should we believe the vendor ? (terrified face) Anyway, here are my 2 cents: - Frame 16: bad FCS on ARP response from MCU to PC, why ? - Your DHCP on UDP port 5, turn it off, just in case, you don't seem to be using it - Frame 2094: Yes, 2058's ACK has been seen, but 2057's not. Then, Seq#s jump at sometimes more than 1460, so some frames were lost, some not. - Frame 2162(3,5) ARP request is not seen by lwIP, frame loss You are definitely having an event that triggers frame losses. Where is it, I can tell. You said this is a custom board, I had once something like this where my driver went out of sync with the eth chip by incorrectly reading available bytes. Please run known to work code first, this looks to me like an eth driver problem - You say you are using tcp_poll() to enqueue data. Don't do that if you aim for performance, that is just to avoid state machines on connection closures and some other good stuff, not for streaming data. You should start sending your data from your tcp_recv() parsing the request and then keep steady sending from your tcp_sent() According to lwip_stats there is no memory leak and no packet drop Well, lwIP can only count *packet* drops, not *frame* loss. And memory leak is tricky, is it possible you are freeing a wrong pointer or in the wrong place ? Try sending and freeing at the same place, that is tcp_sent(), let tcp_poll() aside for now. Check the web server or smtp client sending functions. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
