DCS World and NetCode

[c0ff]

Wouldnt a dedicated server version of the sim help this?

 

A dedicated server can not alter the laws of signal processing theory. :)

 

Theoretically, dedicated server will have some CPU resources available to do more simulation or in this case network work.

 

But, I'm afraid, the most challenging thing we have to deal with now is the complexity of the product vs size of the team.

[macedk]

Also have a look at:

the isp's overselling lines and really crappy setup's.

Crappy cobber lines.

sub stations which die when it rains.

 

And this is very complex stuff ;) We(the client/server) are trying to sync all this up in REAL time and get it back to the client real time.

 

Then there is the end user factor which (head on the chopping block) is 75% of the problem.

tweaked systems

7 av protectors/spamfighters etc.

real time fps recorders/pc monitors etc

a cheap router (not end users real fault here)

the gem...on wifi connect along with 10 others due to no protection or just 10 kids sharing the connection..which is a 2Mbit/0.5Mbit looool. wifi is just not for this type of gaming and will ruin all other players experience period...so do not show with a wifi and say that yours work, its does not period. tough! but somebody must man up and try to kill this myth off once and for all :)

windows with real time index and defrag on etc.

And many many more...look at my self-made hacked and chopped windows....looks nice but has no place in the world of online play ;)

 

And we have no way of verifying that the end user has the house in order other than their word (which offers no guarantee at all).

 

Now.....you first port of call is that the game is faulty...well not true on this planet.

 

Is the quality of the game without merit ? no not at all but to be hornets it really counts for so little in terms of weirdness during the online game.

 

"but how do u xplain the missle going haywire or a building floating or other weird stuff(make up you own)? could it be due to one of the factors above aswell as being the game fault ? If yes then their is no going after the game as the sole culprit....

 

Remember we are trying to mimic an analog thing with digital means...

 

So rant/lecture complete for now.

Ed fanboy? nope / realist ? well at least i take it into account.

I can easily write "i see the same bug" but why it's bugging...well have no clue or where to begin pointing fingers.

 

What to do ?

Lets get a decent internet first...ok give me a planet full of money and labour and you will have it :)

Edited September 13, 2012 by macedk

[sobek]

Theoretically, dedicated server will have some CPU resources available to do more simulation or in this case network work.

 

Yes, certainly, my comment was only in context to the Nyquist theorem.

 

Btw. wouldn't it be more exact to call the effect intersymbol interference, since we're in the context of digital modulation?

 

I'm still having a hard time understanding what you meant, i suppose the problem is that the sampling frequency of your network data is variable, which means that once it goes below a limit, you get intersymbol interference and the predictor goes bonkers, right? Do you want to make the roll off filter scalable to the update frequency? Because i take it that you can't be transmitting completely unfiltered data right now.

[towsim]

A well developed extrapolation of a trajectory does not only depend on the net code. The network or any passed server cannot change the data of X/Y/Z and yaw, pitch and roll. The only small interference is an unreliable timing. But this does not explain warping.

We had, for example, a couple of decades before, an ISDN connection from Germany to USA as a flight simulator connection with 1 frame per 2 seconds and all disadvantages of a ISDN connection. It worked without warping. I admit, the result was not that impressive during turns. But the extrapolation was that clever, that all position, attitude and acceleration data were used to predict an assumed situation.

The basic value of all calculations is the time stamp when a position is calculated in a simulation. The time stamp dictates on the receiver side how to calculate an object position which is actually in the future. An interpolation (versus extrapolation) is not usable. This would cause a rubber string feeling for the pilot because of the latency between input a visible feedback.

By my experience and observations, the most bugs I had were wrong time stamps. This causes exactly the effect what we see as warping. I am not sure about the technology DCS uses for extrapolations . But I cannot imagine, that the data are sent without a time stamp.

Back to the network: an UDP frame contains normally a package counter, a time stamp and all data necessary to describe the object situation. If a UDP package is missed, doesn't matter, the object position can be predicted based on the last valid data. If a UDP package arrives not at the time when it should arrive, doesn't matter, the frame is used as information to calculate the position where the object should be at the moment. If the sequence of UDP packages is changed, doesn't matter, only the highest package counter frame is used for the extrapolation.

It is interesting to know, that never the actual frame data are used in an extrapolation. Every frame bases on an assumed position. By my personal observation, the warping is produced in the sending single simulator. It obviously arises when the single simulator is stressed with a high number of movable objects and/or particle processing. This increases the possibility, that a thread exeeds the maximum loop time of 2 ms because of increasing number of objects to be handled. In this situation it may happen that a switch to a different process/thread interrupts the function which assembles the time stamp and the current object data. If the time stamp is created i.e. with a value of 12345.6789 seconds and is then interrupted, the position data me be calculated 3 times meanwhile and the time is meanwhile 12345.7789 when the interrupted function gets the control back to fetch the position data. So time stamp and position do not fit together. If used, it would calculate a unrealistic high speed.

The assumption, that the warping is produced on the sender side is underlined by the observation, that all members in a multiplayer game see the same warp effect (because all receive the same destroyed data). But they never notice their own aircraft warping. Only other members see your aircraft warping.

It may be that I am totally wrong. But all indices point into the described direction.

Regards

Mike

[c0ff]

I'm still having a hard time understanding what you meant, i suppose the problem is that the sampling frequency of your network data is variable, which means that once it goes below a limit, you get intersymbol interference and the predictor goes bonkers, right? Do you want to make the roll off filter scalable to the update frequency?

 

What we get is not "intersymbol interference" which occurs in the analog/digital transformations.

The problem we have is time-domain aliasing, well known as stroboscopic effect. Aliasing gives a boost to high-frequency content in moves and rotations and sudden packet drops sometimes push the extrapolator into the wild.

Input data should be filtered (before sampling) with the variable cutoff frequency, which depends of packet send rate and takes into account possible packet loss.

 

DCS uses a complex and unique algorithm (developed by me and YoYo for LockOn) for extrapolation, which allows for close formation flying over internet.

But obviously, it requires more tuning for bad network conditions.

 

But, I repeat, the most challenging problem for us now is the overall complexity of the product vs size of the team.

[sobek]

What we get is not "intersymbol interference" which occurs in the analog/digital transformations.

 

Well, i got confused at where the aliasing was happening, but i got it now, it's in the speed/angular speed signals.

 

Input data should be filtered (before sampling) with the variable cutoff frequency, which depends of packet send rate and takes into account possible packet loss.

 

At least i got that right.

Edited September 14, 2012 by sobek