godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
89.72k stars 20.83k forks source link

Network Profiler greatly underreports bandwidth usage #91869

Open romlok opened 4 months ago

romlok commented 4 months ago

Tested versions

Reproducible in: v4.2.2.stable.official [15073afe3]

System information

Godot v4.2.2.stable - Debian GNU/Linux trixie/sid trixie - Wayland - Vulkan (Forward+) - dedicated AMD Radeon RX 7600 (RADV NAVI33) () - AMD Ryzen 5 7600 6-Core Processor (12 Threads)

Issue description

When running a multiplayer project, the "down" and "up" values of the Network Profiler don't match what I see from other network analysis tools (eg. Wireshark), by an order of magnitude!

Eg, an instance of the supplied MRP in Godot: Screenshot_20240511_161134

And the traffic in only one direction (client->server) as monitored by Wireshark: Screenshot_20240511_161025 (note that this is traffic directly to the MRP's server port, so doesn't include debug traffic to the editor itself)

The MRP has each client broadcast a single parameterless unreliable RPC every physics frame (60fps). With just the server and one client this results in the Network Profiler showing a constant ~180B/s to/from each process. This calculates to 3 bytes transferred per RPC.

However, Wireshark shows that just the data portion of a single UDP packet is itself 13 bytes, and the network usage as a whole is 75 bytes on the wire! So I'm not sure how Godot is measuring or calculating these bandwidth values, but they seem at the very least highly misleading :confused:

Screenshot_20240512_103846

Steps to reproduce

  1. Open MRP in editor
  2. Editor: Debug->Run Multiple Instances->Run 2 Instances
  3. Run Project (F5)
  4. Start Wireshark and capture loopback traffic
  5. Filter on udp.dstport == 12345
  6. Wireshark: Statistics->I/O Graphs
  7. Set Y Axis to bytes for the data row at the bottom
  8. :eyes:

Minimal reproduction project (MRP)

network-bandwidth-test.zip

Calinou commented 4 months ago

Note that Godot's network profiler does not measure the overhead added by the network protocol (or even the impact of compression) – it only measures the amount of bytes Godot sends or receives with its high-level multiplayer API.

The value reported by Godot still seems very low (I'd expect it to be at least twice that), but we can't expect it to be identical to the value reported by Wireshark for this reason.

I'm not sure if we can make it a truly accurate measurement of how much data is being sent/received, considering low-level access like Wireshark requires root access and a lot of OS-specific code.

Edit: Disregard the accidental close/reopen below.

romlok commented 4 months ago

Yeah, I don't really know how one could embed more accurate bandwidth measures either. But if the values immediately available to Godot aren't really indicative of real-world usage, the question for me is should they be shown at all? Or should people rather just be directed to the platform-specific tools for accurate bandwidth measurement?

Or else I'm wondering if there are the use cases that the currently presented values are intended for/more helpful, that I'm not thinking of? :thinking:

Faless commented 2 months ago

Or else I'm wondering if there are the use cases that the currently presented values are intended for/more helpful, that I'm not thinking of? 🤔

You can't optimize IP and protocol headers but can optimize your game code (synchronization states and RPCs).

The values shown there, helps you optimize what you can optimize, and you can use them as reference to know if changing your game code actually improve the network usage.

EDIT: In general, this is more useful for the replication system than the RPCs, because the replication system already minimize the number of packets sent (i.e. maximize the packet size while avoiding fragmentation). so the percentage of header overhead is more or less constant, while RPCs are sent immediately (not grouped), so the impact of header overhead may vary much more.