From: Nuno Silva <[email protected]>
To: Discussion of the ENet library <[email protected]> Sent: Fri, February 5, 2010 5:25:16 PM Subject: Re: [ENet-discuss] Multi-threading ENet the easy way... 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. std::vector should be okay as the main thread will access the data linearly (I am not going to find data base on ENetPeer) and the std::pair is there to make sure that I know where the packet is coming from. 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
