Re: [lwip-users] Throughput benchmark question - nasty ~1.5 second pauses

[address@hidden]

Am 06.05.2019 um 23:22 schrieb Dave Nadler:
> On 5/6/2019 3:12 PM, address@hidden wrote:
> > Am 05.05.2019 um 15:47 schrieb Dave Nadler:
> > > Hi all - Back to look at this delay issue. Update:
> > > I studied the driver and ST-provided FreeRTOS/LwIP/cmsis glue and all
> > > looks AOK,
> > > unlike the extremely buggy code ST provides for ST32F7xx series.
> > >
> > > Again, after a lost packet, the host (PC running Windows 10) issues a
> > > _*single*_ duplicate-ack and waits.
> > > LwIP receives the single duplicate ack and by design _*ignores it*_
> > > (tcp_in.c lines 1207-1227).
> > > LwIP takes two passes through slow_tmr (.5 sec intervals) before
> > > retransmitting the lost packet.
> > > Hence nasty >1 second delay.
> > >
> > > I tried patching LwIP to _immediately_ retransmit on a duplicate ack
> > > (line 1215):
> > >                if (pcb->dupacks >= 1 /* DRN kludge prevents 1+sec delays
> > > after lost packet, should be: 3 */) {
> > >                  /* Do fast retransmit (checked via TF_INFR, not via
> > > dupacks count) */
> > >                  tcp_rexmit_fast(pcb);
> > >                }
> > > Wireshark shows a TCP out-of-order packet, which it did not do unpatched
> > > (after the 1.5 sec delay):
> > >
> > > http://www.nadler.com/backups/20190503_Lwip_pause_kludgeFix.pcapng
> > >
> > > Is this OK? Or is there something wrong in tcp_rexmit_fast?
> >
> > No, fast_rexmit is supposed to kick in after 3 dupacks, not at the first
> > dupack.
>
>
> Thanks Simon, I can see that is the code's intent, except the PC never
> sends more than one dupack.
> Sorry if I wasn't clear, my precise question is:
> Why is tcp_rexmit_fast resulting in an out-of-order packet as reported
> by Wireshark?
> Is something wrong in tcp_rexmit_fast?

If I understood you right, the out-of-order packet is only shown if you
modify tcp_rexmit_fast to be called after the first dupack?

If so, wireshark probably just cannot handle the retransmission taking
place so soon with only one dupack and suspects someone has fiddled
around with the tcp stack instead of keeping to the specs and just marks
it as out-of-order... ;-)

Regards,
Simon