Jump to content
🛡️FORUMS ARE IN READ-ONLY MODE Read more... ×
Sign in to follow this  
rekrul

MaxSizeGuaranteed

Recommended Posts

Question to BIS/coders:

From the manual:</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">

Maximum size of guaranteed packet in bytes (without headers). Small messages are packed to larger frames.Guaranteed messages are used for non-repetitive events like shooting.

Default: 512 <span id='postcolor'>

Would it be better to lower this? Few ppl should have problems sending 1024 bytes packets or maybe even more but wouldn't that cause 'bursts' of actions as you have several actions placed in the same frame? Can anyone from BIS comment on how big the UDP payload normally is? Is it 512?

As I gather, if you set the size too small, the server has to fragment the UDP packets and the client has to put them together again (wich takes time).

If you make it too big, will it collect more UDP packets and send it together (if so will it defragment the UDP packets to fill it up?) or will it just use one IP frame per UDP packet?

e.g: (IP headers not in calculation)

MaxSizeGuaranteed=512

Udp #1: 128 bytes

Udp #2: 256 bytes

Udp #3: 64 bytes

Udp #4: 256 bytes

Will the IP packet #1 be Udp #1-3 (448 bytes) and Udp #4 will be in IP packet #2 (possibly with others) or will IP packet #1 be Udp #1-3 + a fragmented Udp #4 (64 bytes) and IP packet #2 is fragemented Udp #4 (192 bytes) + possibly other Udp packets? Or will IP packet #1 be Udp #1, IP packet #2 is Udp #2 and so on? If so, will the IP packet be the size of MaxSizeGuaranteed + IP header or the actual size of the UDP payload + IP header?

I had my server running MaxSizeGuaranteed=1024 but I kept experiencing that when I played I would see enemy running towards me move to the left, then teleport back at the start, then teleport to the right or sometimes just teleport from left to right (very small distances ofcourse but enough to make me miss). I know that this has something to do with the prediction code and my crappy ISP but I would like to know how this works so I can minimize it.

Any (helpful :) comments from BIS would be most grateful.

-Rekrul

Share this post


Link to post
Share on other sites

Rekrul... good explanation of this issue wink.gif

I would like to know the same thing from BIS... along with detailed information about the other Bandwidth management settings. We have a lot to spare but OFP doesn't seem to want to utilize it all. :confused:

Share this post


Link to post
Share on other sites

Have you notices...BIS has never replied to this question? Because of their crappy network code, they probably don't have an answer. I've email them and posted a few times on this board for an answer as well...but,,,no answer. I have a T-3 at night, and in the day, I use a T-1 (redundant backup)..I would love to know the best settings for the flashpoint.cfg. What is the lowest level of server you can have to host the game, etc...For such a fun game, the support is crap. Since they now have a government contract, this game is going to go down hill..

Quibbly

66.64.6.28 (Quibblys Game domain, pure T-3)

Share this post


Link to post
Share on other sites

Well you have to realise that they most likely can't answer these types of question(s) off hand and have to check their own documentation for it. If that was their only job, I'd complain but this is actually an extra service on their behalf. It's not many games you'll have the coders themselves answer for you and they do have a day job too wich I bet is usually more than 8 hrs a day.

I'll just bump this thread until their conscience kicks in and they check it. smile.gif

-Rekrul

Share this post


Link to post
Share on other sites

I remember a message by one of the developers (might have been Suma) saying that they added a number of settings to help fine-tune the network code, but that they didn't have any good data yet on what the best settings would be.

At least they added a way to change the parameters, even if they don't know what the best settings will be in any given environment.

Share this post


Link to post
Share on other sites

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">As I gather, if you set the size too small, the server has to fragment the UDP packets and the client has to put them together again (wich takes time).

If you make it too big, will it collect more UDP packets and send it together (if so will it defragment the UDP packets to fill it up?) or will it just use one IP frame per UDP packet?

<span id='postcolor'>

This option (as explained in docs) servers only to merge small messages together (up to the limit you give). Setting it low does not result in packet fragmentation, the only result is that small packets are not merged together, resulting in higher packet header overhead.

This merging is done on game message level, before UDP packets are formed. More small messages are merged, but only if size of the result is smaller or equal to the limit you set.

There is different setting for guranteed and nonguranteed messages.

Nonguranteed messages are used for unit/vehicle state like:

- position

- orientation

- velocity

- animation state

...

- internal state (including AI, like combat level)

- overall dammage

- state of controls (ailerons, brakes, peddals, driving wheel)

All events are trasmitted as guranteed messages, this includes:

- shooting

- reporting hit

- commands

- text chat messages

Share this post


Link to post
Share on other sites

Thanks for your answer Suma!

Like a godsend, my home ISP has now a kickass connection to my server at the office, so I'll try lowering the size a bit and see how much of a toll it takes on CPU (as the bandwidth isn't any prob).

Still with my 40-50 in ping now I get 'teleporters' but I guess this goes under 'nonguaranteed'? Also Suma, do you have any 'preditction' code or similar that those of us with low ping can turn off?

I keep getting enemy (and humanplayers too btw, but that could be _their connection) moving 4-5m in 1/10th of a second and I have very little PL if I try continous ping (~1% PL), do you have any idea what this could be?

Since this merging is just for smaller messages, I guess this isn't used in larger battles (with 5-10 on each side) where I'm having problems. Could it be the CPU? I usually only have 5-6 ppl on and the monitor says ~25 fps.

Also, do you know the average OFP packetsize is so I can try a continous ping and see if the PL rises, or is there much variations here (sorry, I'm too lazy to put up a packetsniffer smile.gif

-Rekrul

(Edited by Rekrul at 2:33 pm on Dec. 20, 2001)

Share this post


Link to post
Share on other sites
Guest

Just helping you bump.

But you should just run a sniffer or some other traffic measuring device to find the answer for yourself...

Share this post


Link to post
Share on other sites

Guess I have to.

Problem is that we've reworked the entire network and I'm setting up an AMD XP machine to run it on soon, and I'll have a packetsniffer on that one as well, but I'm too busy at work these days to spend even more time on this. Besides I have to get my client back up and working again wich takes its time too due to annoying long OFP reinstalls. smile.gif

-Rekrul

Share this post


Link to post
Share on other sites
Guest

Yeah, know what you mean. I guess Suma and co. are also busy... smile.gif

It'd be interesting to find out your results, though.

Share this post


Link to post
Share on other sites

I rechecked your question and I am not sure what is still left open for answering.

I will answer this:

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">Since this merging is just for smaller messages, I guess this isn't used in larger battles (with 5-10 on each side) where I'm having problems. <span id='postcolor'>

It is just the opposite. The large the batlle is, the bigger number of messsages is being sent, while their size is unchanged - message size has nothing to do with battle size. Therefore there will be more message merging in large battles (and bigger bandwidth conservation achived).

If still something needs to be answered, please formulate a new (and if possible short) question.

Share this post


Link to post
Share on other sites

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Suma @ Jan. 18 2002,18:03)</td></tr><tr><td id="QUOTE">I rechecked your question and I am not sure what is still left open for answering.

I will answer this:

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">Since this merging is just for smaller messages, I guess this isn't used in larger battles  (with 5-10 on each side) where I'm having problems. <span id='postcolor'>

It is just the opposite. The large the batlle is, the bigger number of messsages is being sent, while their size is unchanged - message size has nothing to do with battle size. Therefore there will be more message merging in large battles (and bigger bandwidth conservation achived).

If still something needs to be answered, please formulate a new (and if possible short) question.<span id='postcolor'>

(argh, didn't noticed you had replied.)

Yeah it was just my failed logic kicking in. I figured with large battles you'd get more big messages, but ofc that isn't logic.

1. My most important question is how to minimize 'teleporting' as I mentioned earlier. I can have an enemy AI running towards me, first go a bit left then the next 1/10th of a second it running the complete opposite direction and moved several meters to the right. I can guess why it happends but not how to remove/minimize it. This can happend when I have 40 ping to the server and serverfps is ~30+. (The server is a P3-500 on a 34mbit line with very little load, the client is a Athlon 1.4ghz with 384kbps DL speed(cable)).

2. What's the average size of the guranteed msg packets? Is this usually what you set MaxSizeGuranteed to or what? If it's high will this cause the teleporting (as you get several actions in one packet insted of several updates (packets) but higher packet load)? Or are the packetsizes very fluctuating (varied) up to the size specified in MaxSizeGuaranteed?

3. What is the desync value in the playerlist? I've seen some players have value 4, other have 6000. Is it better to have high or low values? I checked briefly in the manual but didn't find it mentioned.

Thanks for your time and replies.

-Rekrul

Share this post


Link to post
Share on other sites

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">how to minimize 'teleporting' as I mentioned earlier<span id='postcolor'>

I am not sure what will effects of changing the config values will be, but I would not expect any miracles of it.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">2. What's the average size of the guranteed msg packets? Is this usually what you set MaxSizeGuranteed to or what? <span id='postcolor'>

Packets as transmitted across network are usually sized as MaxSizeGuranteed tell them. Actual guranteed messages are usually much smaller and several will fit into one packet.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">3. What is the desync value in the playerlist? I've seen some players have value 4, other have 6000. Is it better to have high or low values? I checked briefly in the manual but didn't find it mentioned.

<span id='postcolor'>

It is a kind of metrics of "out-of-sync" status. The smaller, the better.

Share this post


Link to post
Share on other sites

Wow, that was fast. Thanks for your replies Suma.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×