[ENet-discuss] Large data packets over ENet

[Tim Auld]

Hi Jacco,

Ok, 100KB per frame is more reasonable, and I think 20fps or maybe more is achievable.  I just tried sending a huge amount of data unreliably using my own protocol, and I was able to achieve about 2.2MB/s bandwidth without much effort.  I bet my system administrator was scratching his head at the sudden slowness of the network :)

Some tips I can think of:

- Send your data unreliably.  With the massive bandwidth the overhead of reliability will not be worth while.  Also, packet dropping is not much of an issue with local area networks.  You could replicate adjacent lines to cover up for any lost data.

- Increase socket send and receive buffers greatly.  The defaults will not be enough (8KB is typical I think).  I used 100KB for both send and receive buffers and that seemed to stop all data loss due to buffer overflow on the socket.

- Pipeline several frames.  I think it will be better if you give each server an entire frame, or at least half a frame each, to render.  Issue as many frames as you can to the servers available.  This way the overhead of setting up, compressing, and sending a frame is amortised.  While the other machines are rendering and compressing their frames, one machine is sending the client its finished frame.  Careful coordination may be necessary to prevent servers from trying to send at the same time.  I think this will also lead to fewer collisions on the ethernet.

- Consider looking at delta compression of frames.  If there is not much change between frames, it could be possible to just send the client the changes since the last one.  The client could keep the last frame from a particular server in memory, and apply the change to the frame.

- Make sure the processes have as high priority as possible.  If I took focus away from my test application, the bandwidth throughput would drop dramatically.

- Render a low resolution frame at the client.  Just a spitball idea, but in case a server does not deliver the full resolution frame in time, the client could display a lower resolution frame instead.  This would keep the animation smooth.


I don't know if ENet is suitable for this application.  Someone with more experience with ENet may be able to comment.  In any case, it shouldn't be too much work to write some network code and create your own custom protocol.  This would give you maximum control and performance.

Good luck to you!  I think this is a really interesting problem.  Just yell if I can help any more.

Tim

  ----- Original Message ----- 
  From: Jacco Bikker 
  To: 'Discussion of the ENet library' 
  Sent: Wednesday, February 02, 2005 8:20 PM
  Subject: RE: [ENet-discuss] Large data packets over ENet


  Couldn't you look at the client-server model like this: The server is the 'managing' system that distributes data to all clients. In that case, it's not strange to call the rendering system 'server'. In fact, this system will also handle user interaction and so on, so it's definitely the system that knows most about the process. Perhaps 'master-slave' is better, like in OpenMPI.

   

  Data transfer rates: It's 768KB raw data indeed, and it gets compressed (using LZO) to about 1/6th of that (lossless, there are quite some black areas in the sample scene I'm using). That's still more than 100KB per frame, so at 20fps, it's 2MB. The network should be able to handle that, but ENet isn't: Performance drops to 400ms per frame where I achieved 200ms or less in the original application (no client-server rendering), or 240 in my first (buggy) UDP/Winsock implementation with LZO compression. For comparison: Last night I tried RakNet, which manages to get 270ms frames (also using LZO compression), which isn't optimal, but pretty close.

   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.puremagic.com/pipermail/enet-discuss/attachments/20050203/cdbaedb3/attachment.html