Wait 1 millisecond between duplicate packets

[lupyuen]

Hi: Thanks for adding the option for Duplicate Packets. Based on my testing, we need to insert 1 millisecond delay between the Duplicate Packets. (Should this be another option?)

Without Delay: U-Boot JH7110 boots slower (5.7 Mbps), with 2 TFTP Timeouts

Filename 'initrd'.
Loading: 711.9 KiB/s
Bytes transferred = 8100864 (7b9c00 hex)

With Delay (1 millisecond): U-Boot JH7110 boots faster (8.8 Mbps), with No TFTP Timeouts

Filename 'initrd'.
Loading: 1.1 MiB/s
Bytes transferred = 8100864 (7b9c00 hex)

This was tested on macOS over Wired Ethernet. Thanks :-)

cd ~/rs-tftpd
sudo cargo run -- \
  --duplicate-packets 2 \
  -i 0.0.0.0 \
  -p 69 \
  -d "$HOME/tftproot"

[altugbakan]

LGTM, just a few remarks.

[stappersg]

... is the intended effect putting the delay only between the packets, or before each packet?

That question trigger this question: What if a duplicated packet is actual a delayed packet? Longer version: What if a duplicated packet transmitted by TFTP server is for the TFTP client a packet is could catch on time? Anyway: I suggest that in addition to "--delay-time-between-duplicates" for an option like "--delayed-response-time". That option is indepented from --duplicate_packets. What it does is give a TFTP client time to get ready to recieve packet after it did request for a packet. ( I imagine an immature network driver available in the U-BOOT environment. ) Groeten Geert Stappers -- Silence is hard to parse

[stappersg]

Edits (sorry the previous hasty version)

On Sun, Oct 08, 2023 at 07:11:25AM -0700, Geert Stappers wrote: That question trigger this question:

That question did trigger this question:

What if a duplicated packet is actual a delayed packet? Longer version: What if a duplicated packet transmitted by TFTP server is for the TFTP client a packet is could catch on time?

What if a duplicated packet transmitted by the TFTP server is for the TFTP client a packet it could catch on time?

Anyway: I suggest that in addition to "--delay-time-between-duplicates" for an option like "--delayed-response-time". That option is indepented from --duplicate_packets. What it does is give a TFTP client time to get ready to recieve packet after it did request for a packet. ( I imagine an immature network driver available in the U-BOOT environment. )

Groeten Geert Stappers -- Silence is hard to parse

[lupyuen]

Hi @stappersg: I hope I understood your question correctly, suppose our tftpd sends this sequence of packets to the client:

1. Original Packet #1
2. Delay 1 millisecond
3. Duplicate Packet #1
4. Original Packet #2
5. Delay 1 millisecond
6. Duplicate Packet #2

Our question: If the client correctly receives Original Packet #1, will it handle Duplicate Packet #1 correctly?

Yes the TFTP Client should drop Duplicate Packet #1, because the Block Number is encoded inside the packet. We see this behaviour in curl:

$ curl -v --output initrd tftp://192.168.31.10/initrd
* Received last DATA packet block 1 again.
* Received last DATA packet block 2 again.

(Source)

Apparently U-Boot will drop Duplicate Packets too, because otherwise our Kernel Image would have been corrupted over TFTP and our device will fail to boot. (So far I haven't seen any boot failures due to corrupted Kernel Image)

Which leads to another question: Why don't we throttle the Original Packets and omit the Duplicate Packets?

1. Original Packet #1
2. Delay 2 milliseconds
3. Original Packet #2
4. Delay 2 milliseconds

We tried throttling tftpd to do the above, but it doesn't fix the TFTP Timeouts. (Details here)

So I agree with you, there seems to be a problem with the Network Drivers in some ports of U-Boot. (Maybe it's not responding to I/O Interrupts quick enough? Or it has run out of Network Buffers?)

[altugbakan]

LGTM! Thank you for testing it out.

[stappersg]

On Sun, Oct 08, 2023 at 11:12:02PM -0700, Lup Yuen Lee wrote: Stappers > What if a duplicated packet transmitted by the TFTP server > is for the TFTP client a packet it could catch on time? .... 1. Original Packet `#1` 2. Delay 2 milliseconds 3. Original Packet `#2` 4. Delay 2 milliseconds We tried throttling tftpd to do the above, but it doesn't fix the TFTP Timeouts. [(Details here)](https://lupyuen.github.io/articles/tftp2#throttle-tftp-server) So I agree with you, there seems to be a problem with the Network Drivers in some ports of U-Boot. (Maybe it's not responding to I/O Interrupts quick enough? Or it has run out of Network Buffers?)

What I think what could work 01. client sends request for packet #1 02. server gets request for packet #1 03. server waits (meanwhile client switches to recieve mode) 04. server sends packet #1 05. client processes packet #1 06. client sends request for packet #2 07. server gets request for packet #2 08. server waits (meanwhile client switches to recieve mode) 09. server sends packet #2 10. client processes packet #2 Who it is made working with "duplicates": 01. client sends request for packet #1 02. server gets request for packet #1 03. server sends packet #1 (meanwhile client switches to recieve mode) 04. server sends duplicate of packet #1 05. client processes packet #1 06. client sends request for packet #2 07. server gets request for packet #2 08. server sends packet #2 (meanwhile client switches to recieve mode) 09. server sends duplicate of packet #2 10. client processes packet #2 Answer of problem might be finding out time for steps 03 and 08. Groeten Geert Stappers -- Silence is hard to parse