Trying to optimize LLE wifi sync...

< HLE, wifi, netplay: recent developments and ideasOptimizing wifi, take two >

Trying to optimize LLE wifi sync...
Jul 21st 2023, by Arisotura

In the previous post, I mentioned I had an idea to optimize LLE wifi. I've been experimenting, but for now, nothing really conclusive came out of it.

Basically, if you remember your local multiplayer 101, this is how it goes:

The CMD frame isn't sent immediately, there is always a variable delay before. In a real world setting, you'll want to ensure your wifi channel isn't being used before sending stuff, so that's what the delay is. However, the CMD frame and subsequent reply frames use the 802.11 duration field to reserve the needed timeslot for the entire CMD exchange, so that everything can be pretty tight.

Since version 0.9.5, melonDS uses a synchronization mechanism to ensure this works smoothly. It is actually fairly simple: each frame that is sent has a timestamp attached to it, that is used to keep things in sync. Clients may not run ahead of the host -- when they receive a frame from the host, they know how much they need to catch up, when to start actually receiving that frame, and in the case of a CMD frame, how long they can run ahead before waiting for another frame. And the host discards stale reply frames to prevent itself from running too far ahead. All fine and dandy.

However, I observed that local multiplayer exchanges aren't as tight as I thought before. In most games, the host only sends a CMD frame once per video frame (that is, once every ~16.67ms). Pictochat is a bit different -- it does send CMD frames every ~4ms, but it also does that thing where it polls 3 or 4 clients per frame in a rolling order, so it amounts to a pretty similar thing anyway.

This means that in our case, with the current sync mechanism, clients will spend a whole lot of time waiting for a CMD frame, then having to catch up a whole lot while the host is waiting for reply frames. From a performance standpoint, this is far from ideal -- it largely negates the benefits of multi-core CPUs.

I came up with two ways to work around this, and experimented with them, but so far they both have issues.

The first way would be to abuse the pretty generous CMDCOUNT window games use when sending a CMD frame. I thought that in theory it should be possible to send the CMD frame to clients early, and even have the clients send their reply early as soon as possible, and delay the actual emulation of the CMD/reply/ack exchange until the end of the CMDCOUNT window, and thus things would run more smoothly.

In practice, however, there's a limit as to how far this can be taken. In NSMB MvsL, the CMD/reply/ack exchange needs to occur before the next VBlank or the game will slow down. Other games, like Mario Kart, exhibit stability issues like random disconnects.

In a way, I guess this makes sense -- delaying CMD frames a lot kinda tells the game that the wifi network is really busy.

The second way would be to let clients run freely for a given amount of time after the end of a CMD/reply/ack exchange, so that when the next CMD frame is received, there's much less catching up to do.

But this has its own set of issues too: it requires being able to predict when the next CMD frame will be sent. In general, CMD frames are sent at a fairly predictable interval, but for whatever reason a CMD frame may be sent earlier than expected (for example, if a retransmit is required). In such a situation, what do we do if the client has already run past the point that frame was supposed to be received? This ends up causing cascading problems no matter how you deal with it.

Working out the exact circumstances that may cause a CMD retransmit could make this a viable path, but I'm still not too confident about it.

In the end, I don't know. Maybe HLE is going to be better for this, I don't know.

6 comments have been posted.

< HLE, wifi, netplay: recent developments and ideasOptimizing wifi, take two >

Christopher says:
Jul 22nd 2023

Nice Idea like wifi support.

^.^ says:
Jul 22nd 2023

I'm sure you will figure it out 😉

Julian says:
Jul 24th 2023

i hope someday you can make it work with real nintendo ds console

Generic aka RSDuck says:
Jul 27th 2023

local wireless with a real console with probably never be reality or more than a proof of concept.

Fluffy Squirrel03 says:
Aug 13th 2023

I mean, you never know. I'd like to see a proof of concept first, that would already be quite interesting. Bit irrelevant but I was also wondering if it was possible to mimic the NFC connections of an Amibo to a 3DS or Switch, thereby creating a fake Amibo that we can modify on the fly.

Pedi says:
Jan 28th 2024

Boa bro