FPS position update packets come through in bulk.

Yes, you should stamp your packets with time/tick information. You can use this to reject out-of-order updates, and/or you can store the server-supplied (and client-predicted) into a ring buffer to produce smooth visual movements.

Are you using UDP?
Are you planning on using an interpolation or extrapolation scheme?
Do you have client-side movement prediction?

Some network APIs don't send the data right away, if you're only sending very small packages. Instead it buffers them until the package has a decent size. This is done to minimize the overhead of each package. To avoid this, you should be able to either tell the network API not to do that, or you can flush the connection. I can't say exactly how you should do this without knowing what language you are using.

BUT as you mentioned yourself: you're supposed to work around it even if you send the packages one at a time, latency can still make your game appear jumpy in no time Instead you should simulate/predict what the user is doing. Instead of sending each update, you should only send each player action. When the player starts moving forward, send a message to the server, that the player is mowing forward, and let each client simulate the entire movement, until the player stops moving forward. This should keep all clients in sync, and allow for smooth movement.
You ought to correct the player position once in a while as well, in order to avoid a minor difference on the server and a client, means the difference between bouncing into a wall, or not. This can be done with every player action update.

they arive more or less 10 at a time causing player models to apear very jumpy

First, if you use TCP, your problem is likely not setting TCP_NODELAY. Check the forum FAQ for more info on that.


Second, virtual machines tend to be time sliced on the host CPU, and often introduce siginficantly more jitter than "native" hardware; leading to most VMs not being useful for real-time uses. However, as long as you don't over-tax the hardware, you can often be OK for development purposes. For example, I have a Core 2 with 4 hyper-threaded cores. I give 4 "virtual" cores to a linux VM, and make sure to not use more than 2 hyper-threaded cores on the Windows host side, and they will play nice.

Thnx for the replies. in response to some of youre questions. Ive written the server in java and i use UDP. I have a tcp ip connection that runs in paralal but its idle pretty much always. It mostly gets used to send chat messages etc. As for time slicing the CPU. my cloud server plan states that i get a CPU for myself so that should not be a problem. interpolation or extrapolation scheme? can you please explain the difference . And then about flushing, I dont have the java API docs open in front of me but i dont recall a flush method anywhere usefull. How would i flush out UDP packets in java?

[color="#1C2837"]my cloud server plan states that i get a CPU for myself so that should not be a problem.

[color="#1c2837"]This means that, for a machine with X hardware threads, they will not have more than X customers. That does not mean that the VM system will always schedule your CPU resources. We've seen that just running under a hypervisor will increase scheduling jitter from 3 ms (raw linux box) to 30-80 ms (virtualized guest on otherwise unloaded linux box).
[color="#1c2837"]Under really high load, we've seen hosts like Amazon ECC reach scheduling jitter of 1500 ms (that's 1.5 seconds).

[color="#1c2837"]Try this program in your VM:

http://www.enchantedage.com/scheduling-latency

Also, other things may cause your program to stutter. The Java GC, for example -- if you generate an inordinate amount of garbage.

You might want to measure the outgoing packets at the point of sending by using tcpdump.

Thnx. Im going to test with that app when i get home from work tonight and il let know.

EDIT: Sorry but im still new to the world of linux and ive never realy touched c code. What should I use to build the app in your link? The only thing ive used so far for getting new apps is yum install wich sounds very tasty and makes me go "YUM!" every time i type it.

Thnx. Im going to test with that app when i get home from work tonight and il let know.

EDIT: Sorry but im still new to the world of linux and ive never realy touched c code. What should I use to build the app in your link? The only thing ive used so far for getting new apps is yum install wich sounds very tasty and makes me go "YUM!" every time i type it.

The app has instructions in the comment at the top:

[font=Verdana, sans-serif][color=#FF0000]build with g++ -o calclat calclat.cpp -lrt[color="#ff0000"]
[/font]If you don't have g++, you may need to "yum install g++" or something similar.

OK

I have tested with that app. Latency varies between 250 and 400 ms!
I dropped my cloud server and I ordered a dedicated server from iweb. Just waiting for the instalation to be completed thank you for your time!

On 9/20/2011 at 12:30 AM, EternityZA said:

interpolation or extrapolation scheme? can you please explain the difference

Interpolation: Filling In the In-Betweens

Let's say that you have some packet drops, or out of order delivery, or just receive a bunch at the same time. In any case, you'll generally want to go ahead and use the latest known value and ignore any that never arrive, or are already out-dated by another update by the time they do. Now lets say that at 20 updates per second, you've lost several updates. As a result, one of your entities has moved a bit in the mean time. Now this is probably not enough to make much of a difference to game-play mechanics, but it's enough to be visually jarring if you just snap it to the new position (it'll look "jittery", especially if this keeps happening).

You might choose to interpolate the displayed position from the last displayed position to the last known correct position, by calculating progressive in-between positions for each frame rendered. This won't get the entity to the last known correct position as fast as possible, but it will keep it close, and always approaching it in a smooth manner.

Extrapolation: Predicting the Next Values

Let's say you're uncomfortable with the idea that not only might your displayed position lag a little behind the known correct position, but even the latest known position always lags behind the actual current position (as known by the server).

You might choose to analyze the previous updates and use your knowledge to extrapolate the state that the server probably knows now, by predicting how the state has most likely been changing over time, given recent conditions. If you're generally successful, this will cut down on apparent network lag significantly, but will become even more jittery whenever your extrapolated values have diverged from the actual values sent.

Hybrid Approach

To tackle both issues, you could extrapolate future state, and interpolate current displayed state towards that. If you tune both sides of the system up really well, you can theoretically keep your entity position right-on most of the time, with the occasional awkward (although smooth) correction, as actual conditions change unpredictably.

To tackle both issues, you could extrapolate future state, and interpolate current displayed state towards that.

That's pretty much what EPIC does.

My dedicated server got installed. And that fixed the scheduling problem completely . of course now im left with that little jitter that doesnt affect gameplay much but is visualy unpleasing. I will for now use interpolation to fix that simply because it seems simpler and im just starting out .

Thnx for all the help.

btw its not much but you can check out what i have so far at www.distantmelody.net/blood-tactics. WSAD for movement, left mouse for fire, space for jump (and wall jump), enter to chat.

I think it’s quite serious situation if you receive 10 update at once. It means, update delivery time between clients to server to client will take 0.5 second.
You need to find out where it came from.

Firstly check latency between client and server. If latency is more than 0.5 second, timestamping will be good solution.

However you need to check out where that problem came from like client’ can’t send correctly or server couldn’t receive correctly or server can’t send correctly or client can’t receive correctly.

Please check network traffic and CPU usage on host OS of Virtual box. I think it’s unnecessary to check on Guest OS side.

of course now im left with that little jitter that doesnt affect gameplay much but is visualy unpleasing.

Have a shared time for your network game and use that to tag updates. Use a few tens of ms to buffer and sort received updates before processing them. This reduces the jitter you see on each client.