<div dir="ltr"><div>Thanks for your quick and detailed answers!<br></div><div>I will follow your advices and lower the server cycle, it indeed seems to be a good way to have a better overall reactivity.<br></div><div>As for compression, it may be interesting only for sending maps, but I will put this at the end of the network to-do list :)<br>
<br></div><div>Just one additional question: do you know approximately the bandwidth usage on the server side for the games you have work on?<br></div><div>My target is to be below 50 kB/s upload for 8 players and below 100 kB/s for 16 players, to be able to host such a server on a "classic" Internet line (in France at least, I do not know the max upload rate for other countries...)<br>
</div><br><div>Best regards,<br>Jeremy Richert<br></div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 4, 2013 at 9:16 AM,  <span dir="ltr"><<a href="mailto:enet-discuss-request@cubik.org" target="_blank">enet-discuss-request@cubik.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send ENet-discuss mailing list submissions to<br>
        <a href="mailto:enet-discuss@cubik.org">enet-discuss@cubik.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:enet-discuss-request@cubik.org">enet-discuss-request@cubik.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:enet-discuss-owner@cubik.org">enet-discuss-owner@cubik.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of ENet-discuss digest..."<br>
<br>Today's Topics:<br>
<br>
   1.  Bandwidth/latency optimization (J?r?my Richert)<br>
   2. Re:  Bandwidth/latency optimization (Blair Holloway)<br>
   3. Re:  Bandwidth/latency optimization (Lee Salzman)<br>
<br><br>---------- Forwarded message ----------<br>From: "Jérémy Richert" <<a href="mailto:jeremy.richert1@gmail.com">jeremy.richert1@gmail.com</a>><br>To: <a href="mailto:enet-discuss@cubik.org">enet-discuss@cubik.org</a><br>
Cc: <br>Date: Tue, 3 Dec 2013 22:45:49 +0100<br>Subject: [ENet-discuss] Bandwidth/latency optimization<br><div dir="ltr">Hi all,<br><br>I am currently developing a multiplayer FPS, and I am wondering how to tune ENet to have a network engine as optimized as possible on a bandwidth usage and a latency point of view.<br>
I would like to have your thougts on the following aspects:<br>
<br>----------------<br>1. Packet size<br>----------------<br><br>I was wondering whether it was better to send large packets or to divide them into small packets.<br><br>Pros of the large packets :<br>- Less overhead due to the protocols (8 bytes for UDP, 20 bytes for IPv4, 10 for ENet)<br>

<br>Pros of the small packets :<br>- When a packet is lost, less data is lost<br>- When a reliable packet is lost, resending it requires less bandwidth<br>- Lower latency<br><br>From what I have read, most people agree that it is recommended to send small packets to avoid packet splitting. This means that the application has to ensure that the size of the data sent does not exceed the MTU. Also, as the MTU depends on the router, some people recommended to have packets that will never be splitted, i.e. <= 576 bytes.<br>

What is your experience on this point?<br>For now I have capped the data size to 1500, but I am thinking of reducing it for a better latency. Does anyone know the typical packet loss rate?<br><br>----------------<br>2. Compression<br>

----------------<br><br>Has anyone used compression in a network engine? If yes, which compression algorithm? What was the average gain?<br>I have read that John Carmack used the Huffman compression in the Quake 3 network engine because it was well suited for network data compression, but I still need to find some time to implement it in my program and do some tests.<br>

<br>----------------<br>3. Channels<br>----------------<br><br>What is your network channel policy? How many channels do you use? What do you send on each channel?<br>At the moment I have 2 channels: one for sending unreliable data (a lot), another one for reliable data.<br>

I have chosen this organization to avoid blocking the unreliable data while waiting for an ACK for the reliable data. I am thinking of adding another channel to send high priority reliable data, but I am not sure of the benefit as I already group the reliable data before sending them to limit the blocking. It may be useful if the packet loss rate is too high.<br>

<br>----------------<br>4. Server cycle<br>----------------<br><br>I know this aspect depends on the game type, but I would be interested in knowing how your applications work on this.<br>On my side, based on Valve's introduction to network concepts (+ some readings on the UT and Quake network engines), I have decided to implement a 50-ms cycle on the server side. This means that the servers only updates the simulation and notifies the clients each 50 ms. Meanwhile, it only reads the network messages to empty the network event buffer and to handle the reliable packet sending.<br>

On the client side, I have introduced a voluntary delay of 70 ms, which goes unnoticed on a user point of view, but helps a lot for overall fluidity as the client will almost always have the following world update (unless a packet is lost).<br>

I will soon try to increase the server cycle time to 60 ms to gain 10-20% of bandwidth. I also plan to separate the display delay of the player (it will stay to 70 ms) and the rest of the world (increased to 100 ms). However, I am afraid of the impact on reactivity.<br>

<br>Does anyone have a similar architecture? What is your experience on timings?<br>If not, has anyone already developed a FPS or a game very dependant on the network speed? If yes, what are your advices?<br><br>----------------<br>

5. Other<br>----------------<br><br>If anyone has some useful advices on how to improve the network engine of a game/application, I would be pleased to hear it (well, to read it at least).<br><br><br>Thanks in advance for all your experience sharing.<br>

<br>Best regards,<br>Jeremy Richert<br></div>
<br><br>---------- Forwarded message ----------<br>From: Blair Holloway <<a href="mailto:thynameisblair@chaosandcode.com">thynameisblair@chaosandcode.com</a>><br>To: Discussion of the ENet library <<a href="mailto:enet-discuss@cubik.org">enet-discuss@cubik.org</a>><br>
Cc: <br>Date: Tue, 3 Dec 2013 15:16:54 -0800<br>Subject: Re: [ENet-discuss] Bandwidth/latency optimization<br><div dir="ltr"><div>Here are my thoughts:</div><div><br></div><div>1) Packet size</div><div><br></div><div>Smaller is nearly universally better, especially if any of your data are reliable, as your packets may quickly be eaten up by resent data over poor connections.</div>

<div><br></div><div>A second advantage of smaller data sizes is that you can generally have a higher number of maximum players, or more stuff happening in your game.</div><div><br></div><div>2) Compression</div><div><br>
</div>
<div>Of all the games I've worked on, we only ever used bit-packing or a range encoder to compress the data; we never used a more general-purpose compression algorithm.</div><div><br></div><div>One exception was a game whose packets often contained a lot of repeated string data. We generated a dictionary at runtime using previously seen strings, and used indices into that dictionary during future transmissions.</div>

<div><br></div><div>In general, the best "compression" we implemented was always "remove the need for X to be sent". :)</div><div><br></div><div>3) Channels</div><div><br></div><div>Can you envision a need up-front for high-priority reliable data? I've never encountered such a case myself, but I *have* found cases where certain unreliable data need to be prioritized ahead of others. Sometimes this can be implemented as simply as "put the high priority stuff in the packet first; continue until pre-set limit reached".</div>

<div><br></div><div>4) Server cycle</div><div><br></div><div>The only thing I can really say here is that the smaller simulation time step your server takes, the lesser your latency will be. Increasing the timestep will save you bandwidth, but it can make your game seem laggier. For an FPS, you probably want to aim for an even higher packet rate -- 30 packets per second wouldn't be unusual.</div>

<div><br></div><div>Cheers,</div><div><br></div><div>- Blair</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 3, 2013 at 1:45 PM, Jérémy Richert <span dir="ltr"><<a href="mailto:jeremy.richert1@gmail.com" target="_blank">jeremy.richert1@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<br><br>I am currently developing a multiplayer FPS, and I am wondering how to tune ENet to have a network engine as optimized as possible on a bandwidth usage and a latency point of view.<br>

I would like to have your thougts on the following aspects:<br>
<br>----------------<br>1. Packet size<br>----------------<br><br>I was wondering whether it was better to send large packets or to divide them into small packets.<br><br>Pros of the large packets :<br>- Less overhead due to the protocols (8 bytes for UDP, 20 bytes for IPv4, 10 for ENet)<br>


<br>Pros of the small packets :<br>- When a packet is lost, less data is lost<br>- When a reliable packet is lost, resending it requires less bandwidth<br>- Lower latency<br><br>From what I have read, most people agree that it is recommended to send small packets to avoid packet splitting. This means that the application has to ensure that the size of the data sent does not exceed the MTU. Also, as the MTU depends on the router, some people recommended to have packets that will never be splitted, i.e. <= 576 bytes.<br>


What is your experience on this point?<br>For now I have capped the data size to 1500, but I am thinking of reducing it for a better latency. Does anyone know the typical packet loss rate?<br><br>----------------<br>2. Compression<br>


----------------<br><br>Has anyone used compression in a network engine? If yes, which compression algorithm? What was the average gain?<br>I have read that John Carmack used the Huffman compression in the Quake 3 network engine because it was well suited for network data compression, but I still need to find some time to implement it in my program and do some tests.<br>


<br>----------------<br>3. Channels<br>----------------<br><br>What is your network channel policy? How many channels do you use? What do you send on each channel?<br>At the moment I have 2 channels: one for sending unreliable data (a lot), another one for reliable data.<br>


I have chosen this organization to avoid blocking the unreliable data while waiting for an ACK for the reliable data. I am thinking of adding another channel to send high priority reliable data, but I am not sure of the benefit as I already group the reliable data before sending them to limit the blocking. It may be useful if the packet loss rate is too high.<br>


<br>----------------<br>4. Server cycle<br>----------------<br><br>I know this aspect depends on the game type, but I would be interested in knowing how your applications work on this.<br>On my side, based on Valve's introduction to network concepts (+ some readings on the UT and Quake network engines), I have decided to implement a 50-ms cycle on the server side. This means that the servers only updates the simulation and notifies the clients each 50 ms. Meanwhile, it only reads the network messages to empty the network event buffer and to handle the reliable packet sending.<br>


On the client side, I have introduced a voluntary delay of 70 ms, which goes unnoticed on a user point of view, but helps a lot for overall fluidity as the client will almost always have the following world update (unless a packet is lost).<br>


I will soon try to increase the server cycle time to 60 ms to gain 10-20% of bandwidth. I also plan to separate the display delay of the player (it will stay to 70 ms) and the rest of the world (increased to 100 ms). However, I am afraid of the impact on reactivity.<br>


<br>Does anyone have a similar architecture? What is your experience on timings?<br>If not, has anyone already developed a FPS or a game very dependant on the network speed? If yes, what are your advices?<br><br>----------------<br>


5. Other<br>----------------<br><br>If anyone has some useful advices on how to improve the network engine of a game/application, I would be pleased to hear it (well, to read it at least).<br><br><br>Thanks in advance for all your experience sharing.<br>


<br>Best regards,<br>Jeremy Richert<br></div>
<br>_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org" target="_blank">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
<br></blockquote></div><br></div>
<br><br>---------- Forwarded message ----------<br>From: Lee Salzman <<a href="mailto:lsalzman@gmail.com">lsalzman@gmail.com</a>><br>To: Discussion of the ENet library <<a href="mailto:enet-discuss@cubik.org">enet-discuss@cubik.org</a>><br>
Cc: <br>Date: Wed, 4 Dec 2013 10:16:40 +0200<br>Subject: Re: [ENet-discuss] Bandwidth/latency optimization<br><div dir="ltr">My experiences as for Cube/Sauerbraten:<div><br></div><div>1. packet size</div><div><br></div><div>
Do not hand ENet lots of tiny packets. This is bad. Use the ENet packets as batches, i.e. take a bunch of your little user-level with their own specialized little headers (in Sauerbraten these headers are only 1 byte per packet!). However, keep these batch sizes underneath the ENet MTU with some small reserved space for ENet headers, i.e. peer->mtu - 100 should be good for limiting.</div>

<div><br></div><div>The reason this became important for Sauerbraten is we were sending *lots* of these, so ENet packet headers would have become a significant fraction of the total size, since the payloads of these packets are small. That Sauerbraten's internal protocol can get this down to 1 byte sub-header essentially gets rid of that issue. These are then batched into peer->mtu-100 ENet packets as described above to avoid triggering ENet's transparent fragmentation system. </div>

<div><br></div><div>2. compression</div><div><br></div><div>Pack your data intelligently in the first place, and you won't get much if any benefit from compression. At least Sauerbraten's packets get at most only 5-10% more out of ENet's range coder because we encode, say, integers using an extension scheme that uses as few bytes as necessary (not unlike how, say, UTF8 works). So, just be as smart as possible on the encoding up front, and you can mostly avoid compression and save a lot of the CPU time that you would have normally spent on that.</div>

<div><br></div><div>Failing that, others have been happy enough to stick with ENet's built-in range coder.</div><div><br></div><div>3. channels</div><div><br></div><div>Nothing wrong with a 2 channel setup, and is almost what I use for Sauerbraten. I send bulk movement data on a channel that mostly is only unreliable. Occasionally reliable stuff gets sequenced into that, but very rarely (only for special events like teleports or jumppads). The other channel I use for reliable stuff like gun shots, chat, etc. There are other schemes like how Quake 3 works that can be used to send even that 'reliable' data as unreliable, but it wasn't terribly worth it for Sauerbraten's case.</div>

<div><br></div><div>I also have another channel or two I use for file transfers and things that I don't want stalling the flow of everything else for long durations.</div><div><br></div><div>4. server-cycle</div><div>

<br></div><div>Sauerbraten just because of its insane movement speed uses 33ms (~30 Hz). Whereas for variants with slightly saner move speed, like Red Eclipse/Tesseract/AssaultCube, I have preferred to settle on 40ms (25 Hz). What matters most for this is the quality of your physics interpolation and also that you do a lot of client-side prediction rather than waiting on round-trips, then these small changes in rate don't matter quite as much, but higher fidelity of input to the interpolation always helps.</div>

<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 3, 2013 at 11:45 PM, Jérémy Richert <span dir="ltr"><<a href="mailto:jeremy.richert1@gmail.com" target="_blank">jeremy.richert1@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<br><br>I am currently developing a multiplayer FPS, and I am wondering how to tune ENet to have a network engine as optimized as possible on a bandwidth usage and a latency point of view.<br>

I would like to have your thougts on the following aspects:<br>
<br>----------------<br>1. Packet size<br>----------------<br><br>I was wondering whether it was better to send large packets or to divide them into small packets.<br><br>Pros of the large packets :<br>- Less overhead due to the protocols (8 bytes for UDP, 20 bytes for IPv4, 10 for ENet)<br>


<br>Pros of the small packets :<br>- When a packet is lost, less data is lost<br>- When a reliable packet is lost, resending it requires less bandwidth<br>- Lower latency<br><br>From what I have read, most people agree that it is recommended to send small packets to avoid packet splitting. This means that the application has to ensure that the size of the data sent does not exceed the MTU. Also, as the MTU depends on the router, some people recommended to have packets that will never be splitted, i.e. <= 576 bytes.<br>


What is your experience on this point?<br>For now I have capped the data size to 1500, but I am thinking of reducing it for a better latency. Does anyone know the typical packet loss rate?<br><br>----------------<br>2. Compression<br>


----------------<br><br>Has anyone used compression in a network engine? If yes, which compression algorithm? What was the average gain?<br>I have read that John Carmack used the Huffman compression in the Quake 3 network engine because it was well suited for network data compression, but I still need to find some time to implement it in my program and do some tests.<br>


<br>----------------<br>3. Channels<br>----------------<br><br>What is your network channel policy? How many channels do you use? What do you send on each channel?<br>At the moment I have 2 channels: one for sending unreliable data (a lot), another one for reliable data.<br>


I have chosen this organization to avoid blocking the unreliable data while waiting for an ACK for the reliable data. I am thinking of adding another channel to send high priority reliable data, but I am not sure of the benefit as I already group the reliable data before sending them to limit the blocking. It may be useful if the packet loss rate is too high.<br>


<br>----------------<br>4. Server cycle<br>----------------<br><br>I know this aspect depends on the game type, but I would be interested in knowing how your applications work on this.<br>On my side, based on Valve's introduction to network concepts (+ some readings on the UT and Quake network engines), I have decided to implement a 50-ms cycle on the server side. This means that the servers only updates the simulation and notifies the clients each 50 ms. Meanwhile, it only reads the network messages to empty the network event buffer and to handle the reliable packet sending.<br>


On the client side, I have introduced a voluntary delay of 70 ms, which goes unnoticed on a user point of view, but helps a lot for overall fluidity as the client will almost always have the following world update (unless a packet is lost).<br>


I will soon try to increase the server cycle time to 60 ms to gain 10-20% of bandwidth. I also plan to separate the display delay of the player (it will stay to 70 ms) and the rest of the world (increased to 100 ms). However, I am afraid of the impact on reactivity.<br>


<br>Does anyone have a similar architecture? What is your experience on timings?<br>If not, has anyone already developed a FPS or a game very dependant on the network speed? If yes, what are your advices?<br><br>----------------<br>


5. Other<br>----------------<br><br>If anyone has some useful advices on how to improve the network engine of a game/application, I would be pleased to hear it (well, to read it at least).<br><br><br>Thanks in advance for all your experience sharing.<br>


<br>Best regards,<br>Jeremy Richert<br></div>
<br>_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org" target="_blank">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
<br></blockquote></div><br></div>