[ENet-discuss] Multi-threading ENet the easy way...

Syed Setia Pernama syedhs at yahoo.com
Fri Feb 5 00:14:27 PST 2010


I am using Intel VTune profiler and the hits ~20% was in the function enet_protocol_dispatch_incoming_commands.

I think the reason why enet is taking much of the processing time because first

1) it receives the packet from up to 5 clients (which send @60hz, and each of them is about 1kb-2kb, so each second it receives up to 120kb per client). The packet size received is just my estimation but I tried not to exceed the MTU max size.

2) and then it will retransmit some of the packets back to all clients.

I have a dateline this tuesday to have stable server and to have a stable one, the most crucial thing is to have server running the physics @60hz. I think without mult-threading, it is not possible. Anyway, I will post my findings once the code is working.

I think this could be interesting as CPU dice scales up (quad-core, eight-core etc) and I dont think multi-threading enet is that difficult as the enet can keep most of the data to iself (hence, the thread it is running on).




________________________________
From: Blair Holloway <thynameisblair at chaosandcode.com>
To: Discussion of the ENet library <enet-discuss at cubik.org>
Sent: Fri, February 5, 2010 6:39:40 AM
Subject: Re: [ENet-discuss] Multi-threading ENet the easy way...


The last game I worked on handled 16 players, fully connected (so each machine had 15 active connections), and I think in heated dogfights we peaked around 200 outbound packets per second. I'm reasonably sure enet_host_service wasn't taking 20% of our frame time, or my lead would have whacked me over the head with a cricket bat. :)

I'd be curious to see a more detailed profiling here - do you know where Enet is spending its time?

Regards,

- Blair


On Fri, Feb 5, 2010 at 1:04 AM, Syed Setia Pernama <syedhs at yahoo.com> wrote:

>Hi,
>
>>I have profiled my server which use enet and found that many enet functions are using quite substantial of cpu processing (~20%). I know probably many of you don't see enet as the bottleneck while profiling, but mine is a little different, it is a server which can send (and receive) 60 packets/second to 5 clients. I know, i know that there are some past postings suggested that this is not the best way to do it (60hz), but as it is now it is running okay. But the more pressing issue now is to increase the performance so we decide to make full use of quad core via multi-threading technique.
>
>>What I am thinking of the easy way to multi-thread enet is to specifically run this:-
>
>>std::vector<std::pair<ENetPacket*,ENetPeer*>packets;
>>while (enet_host_service (mHost, & event, 0) > 0) {
>>   ...
>>   switch (event.type) {
>>     case ENET_EVENT_TYPE_RECEIVE:
>>       packets.push_back(std::make_pair(event.packet, event.peer));
>>  ....
>>}
>
>>on thread. The thread will be continuously run 'enet_host_service' function until the server shutdown.
>
>>And the enet packet which is stored using 'packets' variable above, will be made available to main thread via another function -
>
>>void getPackets(std::vector<std::pair<ENetPacket*,ENetPeer*>>& packets)
>
>>Of course, this function will perform the necessary lock for multithreading so as to prevent the thread from inserting while main thread is reading it.
>
>>And that's it. The sending part will be in the main thread. The network thread only concern about receiving packets.
>
>>So the big question is, is the design okay?
>
>>TIA.
>
>
>
>>_______________________________________________
>>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/20100205/3687b92a/attachment.htm>


More information about the ENet-discuss mailing list