[ENet-discuss] Large data packets over ENet

[Jacco Bikker]

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.

 

  _____  

From: enet-discuss-bounces at cubik.org [mailto:enet-discuss-bounces at cubik.org]
On Behalf Of Tim Auld
Sent: Wednesday, February 02, 2005 7:43 AM
To: Discussion of the ENet library
Subject: Re: [ENet-discuss] Large data packets over ENet

 

Firstly, if you follow convention, the process that displays the rendered
images is called the client, and the other processes are the servers.  This
is because the client asks a server to do some work for it, no matter the
relative number of processes.  Really, your client (the renderer with work
it needs done) should connect to multiple servers... not the other way
around.

 

Question: do you really mean 650 kilobits per frame, or do you mean
kilobytes?  512*384*4 = 768KB.  While it's not impossible to compress that
to 650Kb (about 83KB), using something like JPEG, it would probably take
quite a lot of time to do that compression.  There's a big difference.
After doing some calculation, I think you could only achieve about 20fps on
a 100Mbps ethernet with 650KB frames.

 

Tim

 

----- Original Message ----- 

From: Jacco <mailto:jacco.bikker at overloaded.com>  Bikker 

To: enet-discuss at cubik.org 

Sent: Wednesday, February 02, 2005 2:44 AM

Subject: [ENet-discuss] Large data packets over ENet

 

Hello,

 

I am writing a ray tracer that renders at interactive frame rates on a
single machine (2Ghz, 5fps). To advance to realtime performance, I am trying
to use several computers to render the image. I tried using winsock/UDP, but
I lack the knowledge to properly implement this, and the result was
disappointing for anything above 2 clients.

 

So I tried Enet. Implementation was a breeze, but performance is somewhat
disappointing. Perhaps I am doing something wrong, so let me explain what I
do:

-          The server accepts incoming clients.

-          Once at least one client is available, the server sends a 'go'
packet to each client. This packet contains information about which lines
the client should render.

-          The client receives this information, starts rendering, and
returns the result to the server.

 

The maximum amount of returned pixel data is 512x384 pixels (32bit). This is
about 650Kb per frame. Using Enet, performance is significantly better (but
still disappointing) if I compress the data. Does Enet have problems with
large data streams? Is there a way to optimize this?

 

- Jacco.


  _____  


_______________________________________________
ENet-discuss mailing list
ENet-discuss at cubik.org
http://lists.cubik.org/mailman/listinfo/enet-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.puremagic.com/pipermail/enet-discuss/attachments/20050202/ca7ce5be/attachment.htm