[ENet-discuss] CPU Usage

[Nicholas J Ingrassellino]

Blunt is good.

My disclaimer in my first message was meant to pose this as an 
experiment. This is a proof of concept kind of thing and nothing more. 
The idea is to develop an alternative to sending hold frames (or only 
the deltas). Much like VoIP does not suffer from some missing data I 
want to do a little work on how much an image would suffer from the 
smallest discrete unit (a pixel) missing unexpectedly. Look at my 
experiment as anything other than academic-- or a what if-- and you miss 
the point.

*This is purely a exercise of the mind with a little code to back it up.*

Compression and related topics will come later when I have the basics 
figured out.

------------------------------------------------------------------------

Nicholas J Ingrassellino
LifebloodNetworks.com <http://www.lifebloodnetworks.com/> || 
nick at lifebloodnetworks.com <mailto:nick at lifebloodnetworks.com>

"The idea that I can be presented with a problem, set out to logically 
solve it with the tools at hand, and wind up with a program that could 
not be legally used because someone else followed the same logical steps 
some years ago and filed for a patent on it is horrifying."
- John Carmack on software patents


On 09/26/2010 08:41 PM, Lee Salzman wrote:
> I apologize in advance for being blunt, but if you are sending 1 pixel 
> per packet, and sending entire 800x600 pixel frames this way (one 
> pixel at a time), I am speechless. Seriously, do not do that, ever, 
> never ever, never ever ever. You should be sending the entire 
> framebuffer in one packet if you need to send each frame reliably, or 
> if you can afford lossiness, in unreliable 1KBish screen tiles even 
> better. You should also be not using up more than 3 bytes per pixel, 
> and where possible compressing that to less - though ENet's built-in 
> PPM compression will actually help there.
>
> Lee
>
> On 09/26/2010 04:30 PM, Nicholas J Ingrassellino wrote:
>> I am running a little experiment in C++ using ENet v1.3.0 with MSVC 
>> 2k8. What I am attempting to create is a pure dumb terminal-style 
>> application where all video is done on a remote server and sent to 
>> the client while the client only sends over key presses. Yes, yes, I 
>> know; I am reinventing the wheel and half the people reading this do 
>> not approve. It is just an experiment I am doing for kicks.
>>
>> My issue lies in ENet's CPU usage. I had noticed that during the 
>> receiving/drawing step my client CPU usage went to 100% and was 
>> reacting way too slow to do what I want to do. After a while I have 
>> narrowed the problem down to ENet. I even went as far as taking ENet 
>> out of the picture to be sure it was not something else using 
>> simulated data as if it were received from the server (IE virtually 
>> not changing my client main loop). Just so I have gone on the record 
>> as saying it the client, once ENet is removed from the picture, can 
>> draw an image, pixel by pixel, 60 times a second without breaking a 
>> sweat.
>>
>> My server is sending 7 bytes (payload, of course) for each pixel. At 
>> 800x600x24 I am aware this is a hell of a lot of data but it is still 
>> eating a lot more CPU than I figured it would on the client. The 
>> server gets all the data off in a timely fashion but the receiving 
>> side can not get it nearly as fast as it was sent so it ends up 
>> backing up really quickly. The client code looks like this:
>>
>>     while ( !main_loop_exit ) {
>>         acquire_screen();
>>         blit(buffer, screen, 0, 0, 0, 0, buffer->w, buffer->h);
>>         release_screen();
>>
>>         if ( keypressed() ) {
>>             unsigned char key_next = readkey() & 0xff;
>>             ENetPacket *packet = enet_packet_create(&key_next,
>>     sizeof(unsigned char), ENET_PACKET_FLAG_RELIABLE);
>>             enet_peer_send(peer, 0, packet);
>>         }
>>
>>         if ( enet_host_service(client, &event, 0) > 0 ) {
>>             if ( event.type == ENET_EVENT_TYPE_RECEIVE ) {
>>                 _putpixel24(buffer, ((PACKET_PAYLOAD
>>     *)event.packet->data)->x, ((PACKET_PAYLOAD
>>     *)event.packet->data)->y, makecol(((PACKET_PAYLOAD
>>     *)event.packet->data)->r, ((PACKET_PAYLOAD
>>     *)event.packet->data)->g, ((PACKET_PAYLOAD
>>     *)event.packet->data)->b));
>>                 enet_packet_destroy(event.packet);
>>             }
>>             else if ( event.type == ENET_EVENT_TYPE_DISCONNECT )
>>                 main_loop_exit = true;
>>         }
>>         else
>>             rest(1);
>>     }
>>
>>
>> Any input on how I can speed up ENet's processing of packets would be 
>> greatly appreciated. I think ENet is a perfect fit for this project 
>> on paper if I can just figure out how to make it sing.
>>
>> ------------------------------------------------------------------------
>>
>> Nicholas J Ingrassellino
>> LifebloodNetworks.com <http://www.lifebloodnetworks.com/> || 
>> nick at lifebloodnetworks.com <mailto:nick at lifebloodnetworks.com>
>>
>> "The idea that I can be presented with a problem, set out to 
>> logically solve it with the tools at hand, and wind up with a program 
>> that could not be legally used because someone else followed the same 
>> logical steps some years ago and filed for a patent on it is horrifying."
>> - John Carmack on software patents
>>
>>
>> _
>>    
>
>
> _______________________________________________
> 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.cubik.org/pipermail/enet-discuss/attachments/20100926/6509b28b/attachment.html>