Board index FlightGear Development New features

Defensive moderation of MultiPlayer position reports

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Re: Defensive moderation of MultiPlayer position reports

Postby MariuszXC » Tue Jul 06, 2021 8:30 pm

amue wrote in Tue Jul 06, 2021 9:54 am:(Position) MP packets are already time stamped and old/late packets are filtered albeit late in the pipeline in FGAIMultiplayer::update() after the whole packet has been processed in FGMultiplayMgr::ProcessPosMsg() .
Maybe an earlier filtering can be done in FGMultiplayMgr::ProcessPosMsg() when the timestamp is decoded.


And that was the point, the time stamp present is not readily accessible, which makes the early packet pass/discard decision difficult, and doing it late costs processing for a packet which, as you said, will be later filtered anyway.
Also, the time stamp you mentioned is 'sim time' which, if I understand the idea correctly, is perfect to re-create behaviour of a local representation of a remote player, but it is not the same as network 'time' (packet sequence order) although they are related (but also during replay? i don't know for sure..).

While I have your attention I would like to ask a question which relates to the same source file, but not to the topic. Yet I do not want to spam the board with another topic for a possibly trivial question. So, here goes. We have this original code in ProcessPosMsg:
Code: Select all
for (unsigned i = 0; i < 3; ++i)
    motionInfo.position(i) = XDR_decode_double(PosMsg->position[i]);
SGVec3f angleAxis;
for (unsigned i = 0; i < 3; ++i)
    angleAxis(i) = XDR_decode_float(PosMsg->orientation[i]);
motionInfo.orientation = SGQuatf::fromAngleAxis(angleAxis);
for (unsigned i = 0; i < 3; ++i)
    motionInfo.linearVel(i) = XDR_decode_float(PosMsg->linearVel[i]);
for (unsigned i = 0; i < 3; ++i)
    motionInfo.angularVel(i) = XDR_decode_float(PosMsg->angularVel[i]);
for (unsigned i = 0; i < 3; ++i)
    motionInfo.linearAccel(i) = XDR_decode_float(PosMsg->linearAccel[i]);
for (unsigned i = 0; i < 3; ++i)
    motionInfo.angularAccel(i) = XDR_decode_float(PosMsg->angularAccel[i]);

If we rearrange the code like that:
Code: Select all
SGVec3f angleAxis;

#pragma omp parallel for
for (unsigned i = 0; i < 3; ++i) {
    motionInfo.position(i) = XDR_decode_double(PosMsg->position[i]);
    angleAxis(i) = XDR_decode_float(PosMsg->orientation[i]);
}
 
motionInfo.orientation = SGQuatf::fromAngleAxis(angleAxis);
 
#pragma omp parallel for
for (unsigned i = 0; i < 3; ++i) {
    motionInfo.linearVel(i) = XDR_decode_float(PosMsg->linearVel[i]);
    motionInfo.angularVel(i) = XDR_decode_float(PosMsg->angularVel[i]);
    motionInfo.linearAccel(i) = XDR_decode_float(PosMsg->linearAccel[i]);
    motionInfo.angularAccel(i) = XDR_decode_float(PosMsg->angularAccel[i]);
}


1. would there be any ill effects, assuming the #pragma omp.. is ignored?
2. would there be any side effects related to thread safety if handling of the 'for' loops was indeed passed to a pool of OMP threads as pragmas direct?
INOP
MariuszXC
 
Posts: 1061
Joined: Tue May 18, 2021 5:38 pm
Location: Europe
Callsign: SP-MRM
Version: 2020.4
OS: Ubuntu 16.04

Re: Defensive moderation of MultiPlayer position reports

Postby amue » Wed Jul 07, 2021 6:45 am

MariuszXC wrote in Tue Jul 06, 2021 8:30 pm:And that was the point, the time stamp present is not readily accessible, which makes the early packet pass/discard decision difficult, and doing it late costs processing for a packet which, as you said, will be later filtered anyway.
Also, the time stamp you mentioned is 'sim time' which, if I understand the idea correctly, is perfect to re-create behaviour of a local representation of a remote player, but it is not the same as network 'time' (packet sequence order) although they are related (but also during replay? i don't know for sure..).

No, the time stamp in MP packets is wall clock time.

1. would there be any ill effects, assuming the #pragma omp.. is ignored?
2. would there be any side effects related to thread safety if handling of the 'for' loops was indeed passed to a pool of OMP threads as pragmas direct?

As far as I can see, no and no, but...
you wouldn't gain much (if any) by multithreading such small loops. The loops have a small loop count (=3) and they actually don't do much computational time wise.
amue
 
Posts: 92
Joined: Tue Apr 03, 2018 10:13 am

Re: Defensive moderation of MultiPlayer position reports

Postby MariuszXC » Wed Jul 07, 2021 10:10 am

amue wrote in Wed Jul 07, 2021 6:45 am:As far as I can see, no and no, but...
you wouldn't gain much (if any) by multithreading such small loops. The loops have a small loop count (=3) and they actually don't do much computational time wise.


Thank you.
It was more a thought experiment, but on the other hand _any_ speedup counts in my book, esp. when I can employ other cores, which are lying bored doing nothing otherwise.
Also, there are only two loops instead of six, which also scalps a couple of unnecessary instructions.
INOP
MariuszXC
 
Posts: 1061
Joined: Tue May 18, 2021 5:38 pm
Location: Europe
Callsign: SP-MRM
Version: 2020.4
OS: Ubuntu 16.04

Previous

Return to New features

Who is online

Users browsing this forum: No registered users and 7 guests