Hello! Thanks a lot for the help. You are great guys! The problem was that the Nagle's algorithm wasn't really disabled... Now everything works perfect. Thank you! Best regards On Fri, 08 Apr 2011 1
I'm assuming that lwIP is the sender, i.e. 192.168.10.40 (why does no one ever include this information when sending packet captures?!) but please let me know if I've got that wrong. The delay betwee
Hi, I found a strange problem related to Nagle-algorithm but possibly caused by host operating system. My application is as follows: - host sends payload data to my lwIP-driven device in packets of 1
I agree with your interpretation of the Nagle algorithm, and wonder why we don't currently implement it correctly - I haven't got the lwIP source to hand, so can't really comment on that at the momen
While investigating the tcp throughput on my LWIP implimentation, I noticed a distinct stop & restart occurring at a regular 200ms interval. Furthur investigation led me to LWIP's implimentation of N
Or it’s simply a problem with your (OP’s) PC. I’ve used wireshark since it was Ethereal and never had a crash. Bill From: address@hidden [mailto:address@hidden On Behalf Of Radouch, Zdenek Sent
Yea, I agree. It makes sense to just create a flag that will support other options like this in the future. TL1 interfaces disable NAGLE. Ed Attachment: els.vcf Description: Card for Ed Sutter
Ø Wireshark does not work - it crashes on capturing. This is for sure a Windows-problem… I seriously doubt it. I don’t use Windows, but I use Wireshark all the time and the versions that came wi
Hi all! I'm using LWIP on an application where I send various amounts of data. Now I have the problem that the transmission is quite slow sometimes. Please find attached a wireshark protocol for bett
Hello all, While investigating the tcp throughput on my LWIP implimentation, I noticed a distinct stop & restart occurring at a regular 200ms interval. Furthur investigation led me to LWIP's implimen
Hello all, I think it can go into the wishlist; can you name an application where disabling it is wishful? How about keep-alive on a per-socket basis? I would opt for using tcppcb->flags to control t
Hello... I'm using the sockets interface, and I was wondering if anyone has ever considered being able to disable the NAGLE algorithm on a per-socket basis? Ed Attachment: els.vcf Description: Card f
In my architecture, when I need an interrupt process (like for handling Rx) the Interrupt process is just triggering a handler process. The handler process and any other process from the driver have
I think tcp_output() is called every time an rx segment is processed for a pcb, even if it doesn't contain data but only an ack. This is to,achieve throughput like you want. You just cannot rely on i
That's my point, I thought it would be totally unpredective. But after some certain amount of data is periodically queued, the RTT starts to go down again and the throughput is achieved. That is wha
Ok, so the application *never* calls tcp_output() but you leave this completely to the stack? That might work somehow, but will lead to totally unpredictive performance, as you have measured. Also, e
2014-12-08 19:47 GMT+01:00 address@hidden <address@hidden>: As it's always better to know than to guess, why don't you check wih wireshark? Simply because Wireshark does not work - it crashes on capt
As it's always better to know than to guess, why don't you check wih wireshark? If windows does not accept (i.e. ACK, in TCP language) packets any more, you should be able to see that. Or at least se