FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [December 2012 Threads] Free TCPIP and retransmissionPosted by taxalb on December 13, 2012 Hello, I'm working with the FreeTCPIP stack provided with the demo for the RX62N processor and I've some doubts on the internal ack and retransmission policy.
In the FreeRTOS web site the description says that this stack is an improvement of uIP that removes the limitation of a single packet outstanding on the network - is that right?
Does it means that I can receive more than one poll request and send more than one packet before receiving an ack? If so, when after the transmission of a packet I receive a retransmission request, should I send only the last packet sent (as stated in the uIP source code) or all the packets sent after the last ack?
Thanks in advance for any help or suggestion!
RE: Free TCPIP and retransmissionPosted by Richard on December 15, 2012 There are two ways speed improvements are achieved. I don't recall which was used in your particular case.
The slow speed comes from the fact that uIP will wait for one packet to be acked before sending another, and Windows (and other desktop) computers will wait around 200ms before acking a packet.
The easiest way to get around this is to trick the other end to send an ACK immediately by sending each outbound packet twice. If transmissions are done using a DMA then this is the best method as it introduces little or no CPU overhead at the cost of a few more bytes on the wire.
Other demos increase the MSS size to double the true MSS value, then in the network driver split oversized packets into two packets where the maximum size of the packet is the true MSS value. This has two effects, first it double the amount of data that can be outstanding at any one time and second it ensures the other end of sends an ACK immediately that the second packet is received.
In both cases the internal sequencing of waiting for an ACK before sending the next packet is not changed.
Regards.
RE: Free TCPIP and retransmissionPosted by Alberto Tasso on December 17, 2012 Thank you very much for your answer
Regards
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|