After the second evaluation I have been carrying out various tests to compare the output characteristics of the current TCP implementation of Haiku against the one with my patches applied. I shared the links to my patches on the mailing list. They comprise of all ticket numbers in the range 13629 - 13634 [ Trac link ].
This is a companion discussion topic for the original entry at https://www.haiku-os.org/blog/a-star/2017-08-14_gsoc_2017_tcp_optimization_report_5/
These tests are interesting, not necessarily showing what we could hope in improvement, but still they’re precious because we lhave not that much metrics about our network stack behavior so far.
BTW, could you commit these results files in your github too, I fear that a link to Google Drive could be lost easily, while your GSoS github repository wont (ownership transfer at GSoC end is planned.
Regarding the rasberry pi used for your test, maybe trying with a different OS than Linux with another network stack implementation could be useful, in particular to stress the fast retransmits response. RaspBSD maybe?
We also know that Haiku’s TCP stack start to show some slowness after a long uptime. DOes some of your tests were about robustness too, after lot of tcp transfers already made?
Would be nice to see some graphs along with how to (re)produce them.
@Diver : I will surely include graphs. I was planing to do so in the first place but I am just a little stuck with my college exams. They will be over by 23rd. Hopefully soon after that I will include the graphs.
And @phoudoin thanks for the suggestion. I will commit the result files to my github. Will checkout RaspBSD as well.
Actually none of my tests were about robustness in the sense you describe it. Will include those as well but will have to wait till the end of my college exams.