I'm trying to grab lap data from InSim, to display in LRA, my replay analyser.
For this I need LFS to send MCI packets, at a fairly high rate (every 100 ms or less). These should give me the car's position and speed. Together with a timestamp, these will enable a basic analysis of the lap.

The problem I have encountered is that the packets arrive at irregular times, sometimes in bursts of 5 or more within the same millisecond. This is in single player, so there's only 1 car per packet.

That means they are useless for my purpose -- there is no timestamp in the packet, so I have to use the time of arrival as the sample time. It looks like LFS is buffering the packets, and sends them only when it has some "spare time". (My PC is very old.)

My question is: would using UDP help for this problem? Until now, I used only TCP.

You could try using UDP for the position updates, although it seems that your program might require that the packets arrive in the correct order, which UDP does not guarantee.

It sounds like the culprit may be the Nagle algorithm, which improves network efficiency by sending packets in batches. You can learn more about Nagle on the WinSock FAQ.

Another option might be to to use OutSim or OutGauge packets, which do include a timestamp when they are sent.

Quote from DarkTimes :

You could try using UDP for the position updates, although it seems that your program might require that the packets arrive in the correct order, which UDP does not guarantee.

Yep. Either the packets must arrive at regular intervals in the correct order, or they must carry an LFS timestamp.

Quote :

It sounds like the culprit may be the Nagle algorithm, which improves network efficiency by sending packets in batches. You can learn more about Nagle on the WinSock FAQ.

That seems a likely cause. The page you link to also explains that it's unwise to turn Nagle off, plus that it's not even guaranteed to work. Looks like MCI packets are not going to be of any use for me.

Quote :

Another option might be to to use OutSim or OutGauge packets, which do include a timestamp when they are sent.

I'll have a try. The data from OutSim and OutGauge combined would provide enough lap data, and I'll have to re-order the packets when they arrive.

Thank you for a quick and helpful reply. Much appreciated.

Quote from wsinda :

That seems a likely cause. The page you link to also explains that it's unwise to turn Nagle off, plus that it's not even guaranteed to work. Looks like MCI packets are not going to be of any use for me.

post removed, sorry, it was pointless, because Nagle applies to sending packets and not receiving them.

Quote from wsinda :

For this I need LFS to send MCI packets, at a fairly high rate (every 100 ms or less). These should give me the car's position and speed. Together with a timestamp, these will enable a basic analysis of the lap.

MCI packets are sent in batches, as there can be 8 MCI packets for a single update instances on a 32 car grid. Remember, MCI packet can only contain 8 car updates, not the full grid of potentially 32 cars. So when you do get an update, it might just be from the same batch and the detail should still be good and most up to date when using a local connection. (To localhost or to a computer on the LAN.)

Quote from Victor :

post removed, sorry, it was pointless, because Nagle applies to sending packets and not receiving them.

LFS is sending them, so you'll feel it on the other end when you receive them too. (This is epsically true in local connections.)

myeah but i meant, nalge is only for sending packets. Since LFS sends the packets, LFS must use TCP_NODELAY. A receiving program does not have to use that option, unless of course it wants to send to LFS without delay. But that's not wsinda's situation.

Quote from Victor :

myeah but i meant, nalge is only for sending packets. Since LFS sends the packets, LFS must use TCP_NODELAY. A receiving program does not have to use that option, unless of course it wants to send to LFS without delay. But that's not wsinda's situation.

Well played sir.

After some more thinking, I've come to the conclusion that MCI packets are useful after all. I wrote:

Quote from wsinda :

Either the packets must arrive at regular intervals in the correct order, or they must carry an LFS timestamp.

It turns out that LFS generates the packets at a constant rate (= the rate that is requested in the IS_ISI message). I compared samples from RAF files with MCI packets of the same hotlap, and it appears that LFS reliably creates the packets at that fixed rate. I had assumed that the game engine would only make a "best effort" to produce the requested rate, but it seems that packet generation really is part of its schedule.

So, the arrival may not be at regular intervals, but the creation is. And that is precisely what I need for my purpose.

Quote from wsinda :

After some more thinking, I've come to the conclusion that MCI packets are useful after all. I wrote:
It turns out that LFS generates the packets at a constant rate (= the rate that is requested in the IS_ISI message). I compared samples from RAF files with MCI packets of the same hotlap, and it appears that LFS reliably creates the packets at that fixed rate. I had assumed that the game engine would only make a "best effort" to produce the requested rate, but it seems that packet generation really is part of its schedule.

So, the arrival may not be at regular intervals, but the creation is. And that is precisely what I need for my purpose.

Quote from Dygear :

MCI packets are sent in batches, as there can be 8 MCI packets for a single update instances on a 32 car grid. Remember, MCI packet can only contain 8 car updates, not the full grid of potentially 32 cars. So when you do get an update, it might just be from the same batch and the detail should still be good and most up to date when using a local connection. (To localhost or to a computer on the LAN.)

That's what I said ... just apparently not quite as eloquently.