<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v =
"urn:schemas-microsoft-com:vml" xmlns:o =
"urn:schemas-microsoft-com:office:office" xmlns:w =
"urn:schemas-microsoft-com:office:word"><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1479" name=GENERATOR><!--[if !mso]>
<STYLE>v\:* {
BEHAVIOR: url(#default#VML)
}
o\:* {
BEHAVIOR: url(#default#VML)
}
w\:* {
BEHAVIOR: url(#default#VML)
}
.shape {
BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]-->
<STYLE>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
p
{mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman";}
span.EmailStyle17
{mso-style-type:personal;
font-family:Arial;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</STYLE>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=EN-US vLink=purple link=blue bgColor=white>
<DIV><FONT face=Arial size=2>Hi Jacco,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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 :)</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Some tips I can think of:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>- <STRONG>Send your data unreliably</STRONG>.
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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>- <STRONG>Increase socket send and receive
buffers greatly</STRONG>. 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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>- <STRONG>Pipeline several frames</STRONG>. 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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>- <STRONG>Consider looking at delta compression of
frames</STRONG>. 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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>- <STRONG>Make sure the processes have as high
priority as possible</STRONG>. If I took focus away from my test
application, the bandwidth throughput would drop dramatically.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>- <STRONG>Render a low resolution frame at the
client</STRONG>. 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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Good luck to you! I think this is a really
interesting problem. Just yell if I can help any more.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Tim</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=jacco.bikker@overloaded.com
href="mailto:jacco.bikker@overloaded.com">Jacco Bikker</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=enet-discuss@cubik.org
href="mailto:enet-discuss@cubik.org">'Discussion of the ENet library'</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, February 02, 2005 8:20
PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> RE: [ENet-discuss] Large data
packets over ENet</DIV>
<DIV><FONT face=Arial size=2></FONT><BR></DIV>
<DIV class=Section1>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">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.<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Data transfer rates:
It’s 768KB raw data indeed, and it gets compressed (using LZO) to about
1/6<SUP>th</SUP> 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.<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P>
<DIV><FONT face=Arial
size=2></FONT> </DIV></DIV></BLOCKQUOTE></BODY></HTML>