devkitPro

Will consider a patch yes, though messing with those paths could break something and it's not like there's an easy way to test and be sure :) I would like to rewrite the lib, with the point of essentially rewriting it, not just getting it to work. Oddly enough when I started all of this I tried to ...

Well, as you alluded to earlier, UDP is your best option, as it doesn't have any of this mess :) and it's not -that- hard to synchronize and make your own datastream reliable. I have a good number of ideas for how I want the new implementation to work, the problem is mainly that the existing one was ...

Heh, yeah, it's worse than I remember. I thought there was a "Send immediately" flag implemented for some reason. The system doesn't do terribly much in the update, so 5ms should still be practical, you can probably live with that. May mess up sensitive timing around vblank though, if you have any ...

Yeah, there are certainly still some serious issues in the sgIP TCP implementation, though it does generally work reasonably well. I've been meaning to go back and rewrite it for quite some time now. I'll try to take a closer look at this segment and see if there is a serious problem that can be ...

Yes, it is coincidence. Nothing in dswifi is synchronized to vblank. (with the exception of a failsafe in arm7, that checks for packets and fixes the wifi interrupt if it broke) DSWifi notifies the arm9 via an interrupt (through fifo code) every time a packet comes in, so it's not even limited to ...

No. For the simple reason that the lib doesn't keep more than the MSS in transit at any given time. So doing so would effectively cap the transfer speed at 1/3 what it is, for latency-bound connections.

Like I said, many things need to be improved

-Stephen

Haha, don't take me too literally there :) I have a couple of ideas about the TCP slowdown, and have for quite some time. The lib isn't doing anything outright "bad" per se, just a lot of things that could be done better. To be specific, I think it's the combination of the following elements causing ...

Ok, for the record I'm stupid :) What I said in the last post is in fact the opposite of the truth, I'm not sure how I misremebered it so badly; Yes, I see the possibility exists for the wifi timer interrupt to interrupt the wifi update from the fifo, which isn't protected and is a very clear race ...

Heh, This thread is full of all sorts of crackpots :) Please go back and reread the fifo code. interrupts are always disabled when callback functions are called, this was a very important design feature to allow stuff like this to work properly. Whatever it is your patch has done, it certainly hasn ...