Giters

hpcvis / MuVR

The Multi-User Virtual Reality and Body Presence framework is a Unity framework that provides a foundation for multiuser/player VR experiences. Its networking is provided by the Fish-Networking library. It is primarily designed around allowing users to quickly create VR applications.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

2022/08/24 results are incorrect.

FirstGearGames opened this issue · comments

commented

Per your description your setup used a tick rate of 128, but your FPS was capped at 128.

Fish-Networking is a tick based system while Mirror is not, netcode may not be either but I'm not sure on that.
Fish-Networking will speed up sending to try and accommodate the tick rate while others will send as early as they can each frame.

For example, this is what Fish-Networking might look like @ 60 FPS (0.0167s) with a tick rate of 128 (0.0078s).

Frame 1 (0.0167s):
  - Send (0.0078s).
  - Send (0.0078s).
 Frame 2 (0.018s) //notice frame time will vary.
  - Send (0.0078s).
  - Send (0.0078s).
Frame 3 (0.017s):  //notice frame time will vary.
  - Send (0.0078s).
  - Send (0.0078s).
  - Send (0.0078s). //May send a third to accommodate for accumulated lost frame time.

@ 60 frames (1.00s) 128 sends would have occurred.

This is what other netcodes may look like (excluding Fusion, since it is also tick based).

Frame 1 (0.0167s):
  - Has enough time(0.0078s) passed to send? Yes. Send (0.0167s).
Frame 2 (0.018s) //notice frame time will vary.
  - Has enough time(0.0078s) passed to send? Yes. Send (0.018s).

@ 60 frames (1.00s) less than 60 sends would have occurred. This is because other netcodes do not use a rolling tick system.

commented

I switched to using a tickrate of 60 and redid the benchmark. This should minimize the amount of skew. Additionally I have mentioned that the utilization should be slightly higher for Mirror and NCGO (although I don't think the missing frame or two of data would actually add up to enough bandwidth to even mater at 2 digits of precision on a MB/s scale [at least in this benchmark]).

commented

Last I knew Mirror sent between 42-47 bytes per transform update. With only 30 clients you're right that the differences aren't worth mentioning.

I'm still skeptical of the results though, something does not seem right. Can you show the NetworkTransform properties for Mirror and netcodeGO?

commented

Mirror:
image

NCGO:
image

commented
commented

Fixed anything still seem off?

commented
commented

It looks like netcode is tick based but I think the NT is also limiting to one send per frame, which conflicts with a tick based system. So it would seem that the netcode NT default settings is the same as Mirror's with a zero interval. In other words, I believe that's as close as you're going to get to proper results.

commented

Sounds good I am assuming that this has thus been resolved!

commented
commented

I just tested slashing the tick rate down to 20. Which resulted in a substantial decrease in bandwidth utilization. I could be incorrect, but I think this suggests that Fusion is sending multiple ticks per frame.

image

commented
commented

Based on what I know about fusions design, I suspect it has a decent amount of fixed overhead... so I don't think dividing the original value by 3 will simply get us the correct answer...