>> >> Basically it works, i.e. the semaphore is eventually posted, but >> unbearably slow (delay of ca. 200ms for each frame). Without this >> callback, using NETCONN_COPY for netconn_write, the throughput is at >> least 120 times better. Thus I conclude that I have misused the >> callback function for something it is not designed for. On the other >> hand I do not find a better way to get a "done" trigger. Is there a >> better way or do I have to copy the outgoing data (which would violate >> the concept of a non-copy interface)?
>Is it slow because you're sending one packet, and then waiting for the >callback? >With TCP this could wait for a very long time (as you've >seen) as it needs the other side to ACK it before it can free the buffer and >call the callback. You could get around this by sending lots of buffers >without >waiting for the callback, and then freeing each one when its callback is >called. >Kieran Ok, thanks. This is an issue to be considered. In the meantime I have encountered another strange thing which might belong to the same topic. The piece of SW I'm talking about works as a client in an embedded device. If I delete a netconn after each 'netconn_write', I get out twice as many packets as if I let the netconn alive. This is independent of a callback and is also contrary to what I would have expected. I thought building up a connection is more time consuming than just writing to an existing one. So, what happens behind the scenes? Based on your explanation above, I could imagine that a) I'm just killing a connection prematurely, before all the handshaking is done (this lets the question open, how a callback - if registered - is called at all) and thus b) it's only by accident that I get the corret data at the server on my PC, and thus c) I am not allowed to delete a netconn after a successful 'netconn_write' and further d) a callback is mandatory because it's the only way to know when a netconn can be deleted. Actually I'm afraid of believing my own assumptions because it would all be dreadfully bad. What are the facts? Walter _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
