search

ColumbiaCGUI / MercuryMessaging

A framework and encompassing toolkit to facilitate nonspatial communication in the Unity game engine.
Other
42 stars 8 forks source link

Messaging frequency? #1

Open araujokth opened 5 years ago

araujokth commented 5 years ago

Hi,

Great work on this messaging framework. I was reading both your papers at CHI and UIST and was wondering what is the frequency you transmit in your applications, and what is the maximum frequency you have tested the messaging framework? In the UIST paper you wrote that you can go beyond the 29 Hz of UNET, but I could not see any information on the rates you used in each of the papers.

Thanks!

ce2236 commented 5 years ago

Hi Jose,

Thanks for reaching out and for trying the framework!

It varies. Mercury doesn't directly implement a network transmission infrastructure. Instead, we have built an interface (to which I use UNET in my current distribution, but it can be Photon, .NET Sockets, etc.). In my UNET interface implementation, I use different features of UNET to avoid the NetworkTransform's 29Hz limitation. But as I specifically avoided tying the framework's core message transmission to its networking capabilities, it is possible to swap out UNET if desired. So, any performance metrics (as it pertains to network transmission) really will speak more to the underlying network implementation's capabilities. Except for the additional overhead that comes from Mercury routing (which is in the paper too). So, if you look at the underlying implementation of UNET's NetworkTransform (see here https://bitbucket.org/Unity-Technologies/networking) the rate is limited to 29Hz for that type of network transform

Please let me know if that helps!

On Wed, Dec 5, 2018 at 6:51 AM José Araújo notifications@github.com wrote:

Hi,

Great work on this messaging framework. I was reading both your papers at CHI and UIST and was wondering what is the frequency you transmit in your applications, and what is the maximum frequency you have tested the messaging framework? In the UIST paper you wrote that you can go beyond the 29 Hz of UNET, but I could not see any information on the rates you used in each of the papers.

Thanks!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ColumbiaCGUI/MercuryMessaging/issues/1, or mute the thread https://github.com/notifications/unsubscribe-auth/AMOijTC8Db0iLgHhbtEByUt2nOhK5Vxwks5u17M8gaJpZM4ZCkiy .

araujokth commented 5 years ago

Ah ok. I thought you were relying on another transport interface that was not UNET. Sorry for the misunderstanding. But once you go above 30 Hz, dont you get a lot of message bursts? I raised that issue here in the Unity Forum https://forum.unity.com/threads/unet-communication-problem-message-arrival-interval-not-consistent-and-burst-arrival.586468/. Even with the low level UNET implementation, once I go to 60 Hz, then you get very inconsistent packet receptions as most of the packets arrive in a burst and couldnt achieve frequencies above 30 Hz with UNET.

ce2236 commented 5 years ago

We do get some bursts. I took a look at the thread you posted and my result was mostly the same (as your post from today). With some of our recent networking tests we were getting intermittent bursts, but they didn't last long. We also adjusted the network configuration (for the NetworkManager) in those tests. However, I did notice a difference (up to early 2018, so this may have changed) between performance when testing a custom NetworkManager vs a configuration provided to the default NetworkManager. There seemed to be a hidden set of rules as to when you could actually provide the initialization parameters. In aabramychev's response in that thread, he appears to use a custom NetworkManager. And changing the QOS settings seemed to make a large difference the last time I tested it (Spring 2018).