gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > sgIP_TCP: either buggy or awkward

#171995 - PypeBros - Thu Jan 07, 2010 5:40 pm

I've never seen a TCP implementation behaving like dswifi, and chances are that it might explain the "data losses" and deadlocks I'm experiencing with my homebrew. The dswifi code I'm using is a bit old (dkp-r21, tagged "2005-2006"), so I've compared my version (2005-2006) against the latest version in devkitpro and did not noticed significant changes in the TCP protocol handling.

I've got a snapshot of a wireshark capture highlighting the problem, to help explaining my concern.

The first oddity is that the DS seems to ACKnowledge everything from the PC, including pure ACKs (that is, packets with 0 bytes of data). I added a filtering rule to get that noise out of the trace, so you won't see it on the screenshot.

Moreover, it doesn't look to take all ACKs into account when sending a packet, but only the oldest one ... E.g. if you look closely at lines 4060 & 4061 on the screenshot, the DS clearly received some ACK from the PC, since it increases the sequence number (and transmit new data). However, while the PC said "I got everything up to byte #101796", the DS keeps starts transmission from byte #100633 (that is, 256 bytes farther).

My code use non-blocking sockets and tries to send 256 bytes every 5/60th second, rolling back if transmission couldn't be done properly. (I'll tripple-check it, just in case) ...

Has anyone observed this before ? If not, I plan to study Sg Stair's code to figure out how I could improve it.
_________________
SEDS: Sprite Edition on DS :: modplayer

#172003 - TwentySeven - Fri Jan 08, 2010 8:25 am

Yes, its well known that his implementation is .. wobbly.

He promised us a brand new TCP stack was in the works a fair while ago.

The UDP stack seems A-Ok though, and some wifi with broken bits is much appreciated compared to no wifi at all.

#172010 - wintermute - Fri Jan 08, 2010 2:17 pm

Slight rant to start, these things drive me up the wall.

Firstly, it's best if you use the latest tools, bugs have been fixed, improvements have been made and it's pretty much impossible to verify any problems you may report.

Secondly dswifi is a separate library dependent only on libnds and has no relation to the devkitARM version. The latest version is 0.3.11, 2005-2006 is utterly meaningless as a version number (it's also 2010 now :p).

Thirdly devkitPro is a vendor of toolchains and libraries, we have no version numbers and support platforms other than the DS.

dswifi is indeed a touch wobbly in places and is in need of an update or two. Sgstair has been talking about a major rewrite for quite some time but Microsoft keep him quite busy.

Recently I've been considering using uIP as a basis for a rewrite but obviously I have a million and one other things occupying my time. Any help you could offer in improving dswifi would be greatly appreciated.

Probably the best way to start is to make contact with sgstair - he's usually around #dswifi on irc.blitzed.org but patience will be required. There are also a number of knowlegable users in #dsdev on the same irc server.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#172012 - sgstair - Fri Jan 08, 2010 8:58 pm

(And I should mention, there were some ACK bugs that have been fixed in a more recent version - which might include what you're seeing. Not significant changes, but subtle ones.)
I will take a look at your capture though.

-Stephen
_________________
http://blog.akkit.org/ - http://www.akkit.org/dswifi/

#172013 - sgstair - Fri Jan 08, 2010 9:18 pm

Huh, ok - so there's just a screenshot.

There is probably a congestion issue here, due to packet loss, some iffy logic, and outgoing message queuing; If you look further back in the trace then yes, there is almost certainly an ack at 100337, 100633, 100889

This is an issue that I recognize wasn't designed for, and one of the many reasons I want to rewrite the library :)
Probably the best way to handle this particular issue is to only allow one outgoing message per endpoint in the outgoing queue; But the current circular buffer isn't designed for it; Some logic to only keep one message queued could be written, but it would be tricky to synchronize. I have been planning on going with a much different approach in the rewrite.

Presently the stack will send packets when you Send(), when it gets an Ack, and additionally on a timer from time to time. Since it's sending (up to) 1400 byte messages they can actaully take a nontrivial time to post (~6ms to send at 2mbit) - not to mention the wifi HW might retry if the other end didn't acknowledge it (or it loses that packet). You might see the problems leading up here :) The transmit buffer is big enough to hold a dozen packets or so, so this sort of lag can be pretty bad. Fortunately the TCP stack is pretty reliable (doesn't lose data), unfortunately though there are issues like these that hurt performance.

It is a bit of a minefield, there are a lot of reasons I'd like to scrap the current lib and write a new one; the only reason I can't is time - too busy doing other stuff.

-Stephen
_________________
http://blog.akkit.org/ - http://www.akkit.org/dswifi/

#172019 - PypeBros - Sat Jan 09, 2010 12:27 pm

Thanks for your time.
@wintermute: don't get me wrong here: I post this here to improve my knowledge of how things evolved, because I am myself seasoned with network stacks and would love to help by improving sgstair's one if I can. I just don't want to do useless job.

Quote:
probably a congestion issue here, due to packet loss, some iffy logic, and outgoing message queuing;


Wisely said. Most so I observe this mostly because there was a delay between decision of ACK'ing and transmission of the ACK that is higher than expected. Thanks for your details on the internals of the lib. I'll study them with more care after the dishes are washed ;)

Quote:
Fortunately the TCP stack is pretty reliable (doesn't lose data)

The third-pass on my own code was the correct one: I finally found the reason of data losses. There is indeed still performance issues (upload being 30% of the download bandwidth) but that's something i can live with. Sending more data at a time also reduce the effect of such "useless" retransmissions.
_________________
SEDS: Sprite Edition on DS :: modplayer

#172020 - sgstair - Sat Jan 09, 2010 2:22 pm

You're welcome to ask me further questions if you like; And if you want to help maintain the lib, you are most probably welcome, provided you have a sufficient grasp of coding ;)

As has been said, I would like to rewrite the whole thing next; I'm not particularly proud of it, as it is my first network stack - I've made plenty of mistakes (and have plenty of ideas on how to do things better).
However, I don't have time to sink into it presently, and probably won't for another few months, And when I do it will take another few months to actually accomplish anything, so there is still an imminent use for some improvements if you're interested.

-Stephen
_________________
http://blog.akkit.org/ - http://www.akkit.org/dswifi/