Just in case, do remember that ENet is a UDP library so it might: A) consume more CPU than regular TCP libraries B) consume more bandwidth due to lost packets
Also, vector may be a bit slow since it's a linear array and all, try using either map or list and see if it speeds things up. On Fri, Feb 5, 2010 at 8:14 AM, Syed Setia Pernama <[email protected]> wrote: > 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 > >
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
