Implement sliding window scale logic. #110
Comments
|
@lzaiats Hi!
Can you show minimal sample code that works slower than Lidgren-old? |
|
Basically it is UDP congestion the problem.. Lidgren-old appears to drop less packets than LiteNetLib, for example... I will reproduce a little sample code, with LiteNetLib, Lidgren-gen3 and Lidgren-old so you can see the "thing" on your local machine ;) BTW, i've implemented a custom NetSerializer that use MessagePack (the optimized from neuecc) for serialization and it works great! Maybe it can be usefull to other LiteNetLib users ;) |
|
Hi @RevenantX ! Here is the simple benchmark I made... It sends reliable and unreliable messages and count sent and received messages... LiteNetLib reliable performance is not good compared to Lidgren-old! On my "game project" after some time, the clients simply stops receiving reliable instantiate messages and the game stops working... Another important point to mention is the memory consumption... Lidgren-old test is almost not using memory allocations at all, while LiteNetLib test uses > 2Gig... Here is the results: Testing Lidgren-old... Testing LiteNetLib... |
|
@lzaiats thank you! I will investigate this. Something wrong with send speed. |
|
@lzaiats high memory consumption caused by packet pooling. I think i must add some limits to pooled packets. |
|
By staring a second client on the same machine I was able to double the bandwidth transfer on the same connection so this suggests a rate limit inside each client. Would a bounty help you find the time to work on this issue? |
|
@mgamache i know why this problem exits) As i said before - this because i don't implemented "sliding window scale" logic. This requires some time to implement.
Donations always help to find the time to work on library entirely :) But i can't promise fast fix(implementaiton) right now, because i'm working on two projects. But soon (end of december) i will have some time for library features and improvements. |
RevenantX
changed the title
|
Hey, remember me? So was going to ask if you want to share profits on releasing https://github.com/Saishy/TinyBirdNet-Unity at the asset store. |
|
@lzaiats hi! Try latest version from github. I heavily optimized sending code. Your problem (with 750 clients) must be fixed. (but not benchmark) |
Yes)
You can donate any amount that you think is necessary) |
|
@RevenantX Heeeey! Awesome news! I ran the tests changing the values of the NetConstants.DefaultWindowSize and here are the results: ---- WindowSize = 16 ---- WindowSize = 32 ---- WindowSize = 64 ---- WindowSize = 128 ---- WindowSize = 256 ---- WindowSize = 512 ---- WindowSize = 1024 IMPRESSIVE! I'll do some more testing using the real 750 clients and share the results with you! Thank you! |
|
@lzaiats don't increase it manually. It must be increased automatically (later). |
|
@RevenantX ;) Actually I only increased the value by hand to understand the maximum throughput the lib could achieve... On the game (production) I will not touch this number ;) One thing that is still making me a little confused is that on all circunstances, the bytes sent by the client and the bytes received by the server are almost the same... But the number of messages are completely different... Have a look: Testing LiteNetLib... SERVER RECEIVED -> Reliable: 89536, Unreliable: 749593 |
|
@lzaiats after some time all reliable messages will be received. Add more time before showing statistics) They just in queue. |
|
@lzaiats real packets sent is - PacketsSent: 839281 |
Any news?) |
|
@Izaiats Hi, Did you try with a lower DefaultUpdateTime ? Like 5 ms. Can it help ? Maybe the thread shouldnt stop until there is nothing else to process, wait after that. |
|
@DanisJoyal It doesn't help, I already tried. |
|
@nxrighthere Maybe 1 ms sleep too much. Maybe it needs to none stop update until its done. |
|
@DanisJoyal I tried a lot of configurations and I had no luck! @nxrighthere Nice to see your benchmark suite! Also I made one using exact the same libs you did and the results are just the same! Using ENet wrapper gives the best result always! If you want to see good results with another lib, try this OLD lidgren version: https://code.google.com/archive/p/lidgren-network/downloads , the one from Jan 22, 2010... It's almost the same API as Lidgren-v3 but will show you results comparable to ENet ;) @RevenantX I stopped benchmarking for now, maybe we can continue the investigation using @nxrighthere test suite now, since it's more complete and modular than mine! |
|
@lzaiats Hi, I just ran your UDPLibBench.zip. I ve got to adapt it to my latest version, on my fork. So far, Ive got this: Testing LiteNetLib... No Issue, except a little bit packets loss on client side. Im running 2 clients thread at the same time on the same server to see if it last. Cheers |
|
I'm so confused right now... I did a test with the old version of Lidgren as @lzaiats suggested, and you know what? It's passed the test with 1000 clients... CPU usage 60%, memory consumption 360 megabytes. |
|
@nxrighthere Bingo! :) The old lidgren version is far better than the gen3, and its also almost the same performance than ENet... Amazing ;) |
|
Thats funny. So, you re telling me that google are so dumb to create a new version of the lib worst than the first one. I think that it s an issue from the .Net Framework. Maybe you can try the old Lidgren to use .Net Framework > 4.5. I didnt have time since 1 week to continue my investigation. But, I saw that the framework its not using the same sendto function as Enet. I will check that this week end. Cheers. |
|
I'm using .NET Framework 4.7.1 for all libraries. |
|
You re overwriting the framework set by default ? The old lidgren is using .Net Framework 2.0. Anyway, if Lidgren is able to do it. LiteNetLib should be able too. |
|
I'm not using the csproj at all, I compile everything directly with Roslyn. |
|
@nxrighthere @DanisJoyal added DISABLE_IPV6 ifdef. So you can disable ipv6 thread (so this is 1000 less threads in that test). Passed test with 1200 clients. |
|
Yea, works better now. 900 clients are connected and after that the CPU usage raises 92% and the application becomes unresponsive. But very nice anyway. |
|
GC is still the biggest performance killer. I tried to build the library with built-in Roslyn's optimization logic and now 950 connections is reached, but the server thread just crashed. |
|
[Link removed] @DanisJoyal @RevenantX! |
|
@nxrighthere O_o. There is crash and bytes count is diffferent... |
|
Yea, it breaks for some reason. |
|
Now it works much better. |
|
@nxrighthere how? |
|
Take a look at this. |
|
Hi guys! Long time since my last post here =) I just wanted to share with you the current stage of my MMO server architecture and the feedback coming from you guys (@RevenantX @nxrighthere @DanisJoyal ) is a pot of gold to me! Welcome to netEngineX (temporary name) showcase! A distributed MMO server architecture using C# and Unity (other game engines soon)! Basically, netEngineX consists of three parts:
This is a simple demo to show the current state of this technology:
** netEngineX have built-in Network LOD using groups to save bandwidth... *** This is not a real game, but if you can imagine all the possibilities =) All Workers are running locally, but yes, they can be run across the network... We are using CharacterController (heavy) to simulate AIs so we have a more close simulation of (600) player controlled characters... **** netEngineX can be adapted to use any UDP lib (lidgren, litenetlib, enet or any other). Currently using lidgren-old (from Google Code)... Suggestions and questions, feel free to email me! Thanks for watching! |
|
@lzaiats |
|
Hello! Can I ask what's the status of this feature - specifically the sliding window scale logic? Is this still something that's being considered? I see there's a lot of talk about performance and other things in this thread, so I'm not fully certain if that's still the focus. With our use-case, we often run into an issue, where the higher someone's latency is (often times between US <--> Australia and such), the throughput degrades. I believe this is in big part happening due to the sliding window not being large enough to properly saturate that distance, so I think this could help with those kinds of connections. |
|
@Frooxius well ReliableOrdered should be used in RUDP last of all. Mostly packets should be Unreliable/Sequenced - and then you will not get that problem. |
|
@Frooxius also if you will use GetMaxSinglePacketSize and pack your Reliable packets tightly - you will get better performance |
|
@RevenantX We use Unrealiable/Sequenced for what we can - continuously changing poses, voice data and so on. However we have other type of changes, which require reliable transmission, because they are various delta changes to the state of the world - they can be random and they need to happen in the right order as well. This normally works well for our purposes, but the transmission throughput degrades with latency, which is the primary issue we're having. TCP socket is not suitable our purposes for two main reasons. One it's generally not recommended to mix both UDP and TCP (e.g.: https://gamedev.stackexchange.com/questions/165392/will-tcp-really-affects-udp-if-used-in-different-context and https://gamedev.stackexchange.com/questions/120115/does-it-make-sense-to-use-both-tcp-and-udp-at-once) and second, UDP allows for hole punching, but TCP not as much. |
|
@Frooxius you can check https://github.com/RevenantX/LiteEntitySystem/ it uses ReliableOrdered only for BaseState (full game state). And later Unreliable for delta states (that include rpcs). So you can achieve reliability without using ReliableOrdered in much better way. User input also sent to server as Unreliable |
|
+1 for sliding window scale |
|
@RevenantX Unfortunately that approach is not applicable for our project, because we need to synchronize complex state changes of data model. I am not really looking here for suggestions for alternate approaches and workarounds for our project to get around this issue, we do what we can on our end there. My main interest was if there are any plans to work on this issue to improve the networking performance, especially with higher latency between endpoints? |
I have been testing LiteNetLib, Lidgren-gen3 and Lidgren-old (the one from Google Code) and Lidgren-old is beating the competitors by far... On my test I have 750 clients connected to a single server instance, receiving ~15 reliable msgs/s and ~100 unreliable msgs/s and Lidgren-old can handle all this data perfectly! Using the same "game code" but using Lidgren-gen3 or LiteNetLib the test "fails" between 100 and 120 clients... Maybe I am missing something with LiteNetLib API, so I can achieve better performance... Do you have any idea where I am doing wrong with your Lib? If you need I can share the code :)
Thanks and keep the awesome work!
The text was updated successfully, but these errors were encountered: