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
