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 <[email protected]> To: Discussion of the ENet library <[email protected]> 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 <[email protected]> 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 >[email protected] >http://lists.cubik.org/mailman/listinfo/enet-discuss >
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
