Opened 21 months ago
Closed 21 months ago
#2584 closed enhancement (fixed)
Reduce the fixed 250ms ack delay
Reported by: | Zlatin Balevsky | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 0.9.42 |
Component: | streaming | Version: | 0.9.41 |
Keywords: | Cc: | ||
Parent Tickets: | Sensitive: | no |
Description
See https://trac.i2p2.de/ticket/1939#comment:14 for background on how this was discovered.
I performed 5 test runs in the testnet with each value below with a 25MB file. It is interesting to see how up to a point reducing the value increases the speed.
ack delay(ms) | speeds (kb/s)
===================
300 | 150, 125, 119, 156, 166
250 | 169, 147, 142, 168, 179
200 | 192, 198, 214, 156, 198
150 | 179, 296, 332, 204, 212
100 | 166, 212, 222, 274, 196
50 | 88, 123, 76, 86, 250
I ran a t-test and there is less than 1.3% chance the difference between the 250ms and 150ms samples occurred by chance.
https://www.statisticshowto.datasciencecentral.com/probability-and-statistics/t-test/
https://help.libreoffice.org/Calc/Statistical_Functions_Part_Five#TTEST
It's hard to say to what extent this reflects the conditions in the live network, but I think it's worth considering a reduction in the ack delay.
Subtickets
Change History (2)
comment:1 Changed 21 months ago by
comment:2 Changed 21 months ago by
Milestone: | undecided → 0.9.42 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Good research, no objection to 150.
As noted in the code comments, for loopback connections if the buffer gets overrun then we start choking, which I believe is what you're seeing with a delay of 50.
In 2ec35a4caf7e2622fd5aa9e8c4edc6c3aff9c80f to be 0.9.41-7
Some more data points if anyone wants to do better analysis:
250ms:
151, 137, 169, 150, 176, 150, 189, 198, 149, 170, 175, 259, 216, 151, 153
150ms:
183, 192, 244, 239, 227, 277, 252, 188, 254, 223, 259, 249, 201, 251, 246