TCP data retransmission

[masscat]

After playing with DSFTP I noticed that the download speed (DS to PC) was about 10 times less than the upload speed (PC to DS).

After some investigation, it was apparent that dswifi was sending out all non-acknowledged data in each TCP packet it sent. This included data that the DS had already sent but the PC had not yet got round to sending the acknowledge for, thereby wasting bandwidth.

To experiment with a solution I did a quick hack of dswifi to only send new data, i.e. not previously sent data. The resulting upload and download speeds are now of the same order. For those who are interested you can get a patch file against the dswifi cvs (dated 2006-10-05) with the hack. To install the patch change into the dswifi directory and run "patch -p0 <path/to/patchfile". It was experimental and may break TCP.

[sgstair]

Hiya

 

Yes, you are correct in your observation that the DS resends a lot of data; and this is something I'll be addressing in my rewrite (as it stands, the current version of sgIP will probably not be maintained further)

you are also correct that the patch will likely break TCP - it looks like it may break if there's some data loss, or a few other conditions it looks like.

(this is actually probably better addressed by sending large blocks of data at once, though I probably have some code that makes this a bit less efficient too)

Anyway, it's nice to see people playing around with it, though I promise the next version will be a lot better.

 

-Stephen

[masscat]

I have seen a case where 1 byte does not get transmitted in sequence, resulting in the need for the 1.5 second retransmit timeout to happen before it is sent. So anybody playing with the hack take care.

 

Looking forward to the next dswifi release.