3 ms·

> Actual traffic for a metaverse is mostly bulk content download. Highly interactive traffic over UDP is maybe 1MB/second, including voice. Typical bandwidth f

> Actual traffic for a metaverse is mostly bulk content download. Highly interactive traffic over UDP is maybe 1MB/second, including voice. Typical bandwidth for multiplayer games like FPS (Counterstrike, Apex Legends) are around 512kbps-1mbit per-second down per-client, and this is old information, newer games almost certainly use more. It's easy to see a more high fidelity gaming experience taking 10mbit - 100mbit traffic from server to client, just increase the size and fidelity of the world. next, increase player counts and you can easily fill 10gbit/sec for a future FPS/MMO hybrid. God save us from the egress BW costs though :)

geraldhh 3y ago
i venture a guess that there are still no online games that use more than one mbps for interactive traffic and seeing fully remote gaming using tens of mbps, i don't see any justification for complexities like asset streaming.
eqvinox 3y ago
You'll hit game engine CPU usage limits way before getting anywhere near Gbit/s in outbound game traffic on a game server, and the cost of network I/O is going to be negligible. XDP is useful for applications that are network I/O bound. Gaming is not one of those.
Animats 3y ago
There are only so many pixels on the screen, as Epic points out. The need for bandwidth is finite. It will be interesting to see if Epic makes a streamed version of the Matrix Awakens demo. You can download that and build it. It's about 1TB after decompression. If they can make that work with their asset streaming system, that will settle the question of what you really need from the network.
- gafferongames 3y ago
  You can't client side predict pixels.
- fluoridation 3y ago
  But pixels can be arbitrarily "deep". That is to say, the amount of context that is needed to figure out the color of a pixel can grow arbitrarily large.
  - Kamq 3y ago
    Yes, but if it requires more data than the screen's worth of pixels, you can just send the pixels. Pretty sure this is the "cap" that was described.
    - gafferongames 3y ago
      And yet if you just send the pixels, you cannot client side predict (hide latency in multiplayer games) because the pixels fix you to a specific point of view. Game streaming is not really the solution here.
      - eqvinox 3y ago
        Even with a zero size game client, there is only so much to stream in textures and geometry. And when you're done with that, the game world itself is trivial. The only thing in games that is bandwidth heavy is on-demand game asset delivery, which is highly cacheable and shardable. It will need no XDP-like networking tricks in either servers or clients.
        gafferongames 3y ago
        > the game world itself is trivial. This is just absolutely not true.
        chainingsolid 3y ago
        Adding a possible example here to back Glen's comment. Larger render distance Minecraft servers, Bandwidth cost is un-predictable (Player movement based ex: Elytra, portals, joining) and scales squared! with the render distance.

geraldhh 3y ago

i venture a guess that there are still no online games that use more than one mbps for interactive traffic and seeing fully remote gaming using tens of mbps, i don't see any justification for complexities like asset streaming.

eqvinox 3y ago

You'll hit game engine CPU usage limits way before getting anywhere near Gbit/s in outbound game traffic on a game server, and the cost of network I/O is going to be negligible. XDP is useful for applications that are network I/O bound. Gaming is not one of those.

Animats 3y ago

There are only so many pixels on the screen, as Epic points out. The need for bandwidth is finite. It will be interesting to see if Epic makes a streamed version of the Matrix Awakens demo. You can download that and build it. It's about 1TB after decompression. If they can make that work with their asset streaming system, that will settle the question of what you really need from the network.

gafferongames 3y ago
You can't client side predict pixels.
fluoridation 3y ago
But pixels can be arbitrarily "deep". That is to say, the amount of context that is needed to figure out the color of a pixel can grow arbitrarily large.
- Kamq 3y ago
  Yes, but if it requires more data than the screen's worth of pixels, you can just send the pixels. Pretty sure this is the "cap" that was described.
  - gafferongames 3y ago
    And yet if you just send the pixels, you cannot client side predict (hide latency in multiplayer games) because the pixels fix you to a specific point of view. Game streaming is not really the solution here.
    - eqvinox 3y ago
      Even with a zero size game client, there is only so much to stream in textures and geometry. And when you're done with that, the game world itself is trivial. The only thing in games that is bandwidth heavy is on-demand game asset delivery, which is highly cacheable and shardable. It will need no XDP-like networking tricks in either servers or clients.
      - gafferongames 3y ago
        > the game world itself is trivial. This is just absolutely not true.
        chainingsolid 3y ago
        Adding a possible example here to back Glen's comment. Larger render distance Minecraft servers, Bandwidth cost is un-predictable (Player movement based ex: Elytra, portals, joining) and scales squared! with the render distance.