- 4,101
- California
- Sk8er913
There has been a lot of speculation about an increased grid offline for GT7, because of the PS4s increased processing power. Also many of us would like to see an increased amount in online lobbys. So I will build a hypothetical network and the stresses that it would place on a network.
Internet connection target, a normal minimum developers seem to use is a low end DSL connection well say that it has these speed constraints:
Download:156KBytes/s
Upload: 78KBytes/s
Ping: 175 Ms
Things that need to be communicated between players in a network.
3 position axis, XYZ. Probably uses 16 values of accuracy for each one. So a hypothetical position could be 53,050.1234567890, 53,050.1234567890, 53,050.1234567890
That is 48 bits of information, but they also have a name attached to them well call them Pos-X: Pos-Y and Pos-Z. That is an extra 18 bytes of information, so we can reasonably communicate where a car is located in approximately 66 bytes of information, however this needs to be updated to make the car move a reasonable speed to update would be 30 times per second since the game is 30 FPS (probably).
Position will use 720 Bytes of data per second
3 rotation axis, same as position
To save space since rotations don't have to be as accurate and have generally smaller numbers than position so we can use 8 values of accuracy for rotation instead of 16. This saves us 3 Bytes per packet! Making our rotation packet size a small 21 Bytes.
Rotation will use 630 Bytes of data per second
We're not done yet, we still need information on throttle input, steering, brake input, gear selection, lap times, sector times, current speed, tire condition, fuel amount, and what player it is.
Thr: 8bit val = 5 bytes per FPS = 150 Bytes
Brk: 8 bit val = 5 bytes per FPS = 150 Bytes
Str: 8 bit val = 5 bytes per FPS = 150 Bytes
Fuel: 8 bit val = 6 bytes per second (Per FPS sounds excessive.)
TireC: 8 bit val = 7 bytes per second
Gear: 8 bit val = 6 bytes per FPS = 180 Bytes
Spd: 8 bit val = 5 bytes per FPS = 150 Bytes
Sect: SectX + time = 8 Bytes per section (I think?)
LapT: Time = 6 Bytes per section
We need to know what car they are in right?
An efficient system could possibly only use 5 bytes per fps per category.
Car knowledge will use 1800 Bytes of data per second
That is for a 2 person lobby. Lets add it up to see how much it stresses the internet.
720 + 630 + 450 + 13 + 180 +150 + 14 + 1800 /1000 = 3.957KB/s
Our bottleneck in the connection is the upload speed of 78KB/s now that we know per peer we can figure out what the pressure on our host is. We can simply divide 78 by 3.957 to find how many players we can network together.
78/3.957 = 19.7 connections.
And we can't have 0.7 people playing so its 19. Which an increase from 16 to 19 doesn't sound like much fun. PD probably did the exact same test that I just did, and that's why our numbers were so close together. I think I may have been a little conservative, so 16 sounds perfect. If you want GT7 to have a 32 car grid. You better update your old DSL connections quickly, if you have a connection like our example here.
Day #2 Optimization and correction of errors made in the original post
Adding in RPMs, apparently I accidentally forgot RPM, so I will add it now.
RPM: 8 bit val = 5 bytes of information, every FPS, that is 150 Bytes per second.
Optimization!
Do we really need to update position and rotation EVERY FPS? We have all of the components to drive the car already, so it's more of a correction thing. We could likely lower it from every 30 fps to every 10 FPS, and not notice any change in quality.
Position will use 240 Bytes of data per second instead of 720.
Rotation will use 210 Bytes of data per second instead of 630.
@daan questioned my use of car information per FPS. And why it was needed. It is actually player information, so that cars can be in different positions at the same time. And after thinking about it, it does not need to be updated every FPS per category, it only needs to be updated every update per category which saves us a lot of work.
Position updates 10 times = 50 Bytes
Rotation updates 10 times = 50 Bytes
thr, brk, and str update 30 times each = 450 Bytes
fuel, tires update 1 time each = 10 Bytes
Gear, Spd, and RPM update 30 times each = 450 Bytes
Sect and LapT = 10 Bytes in a rough second.
100 + 900 + 20 = 1020. MUCH BETTER THAN 1800!!!!!!!!
Over connectivity per player will be:
240 + 210 + 450 + 13 + 180 + 300 + 14 + 1020 /1000 = 2.427 KB/s
78/2.427 = 32.13 connections, BUT we want to have a little extra for features like text chat. And for players joining in the middle of a game. 24 Players is completely reasonable. 32 is also reasonable if the host has an upload speed higher than 78 KB/s
Internet connection target, a normal minimum developers seem to use is a low end DSL connection well say that it has these speed constraints:
Download:156KBytes/s
Upload: 78KBytes/s
Ping: 175 Ms
Things that need to be communicated between players in a network.
3 position axis, XYZ. Probably uses 16 values of accuracy for each one. So a hypothetical position could be 53,050.1234567890, 53,050.1234567890, 53,050.1234567890
That is 48 bits of information, but they also have a name attached to them well call them Pos-X: Pos-Y and Pos-Z. That is an extra 18 bytes of information, so we can reasonably communicate where a car is located in approximately 66 bytes of information, however this needs to be updated to make the car move a reasonable speed to update would be 30 times per second since the game is 30 FPS (probably).
Position will use 720 Bytes of data per second
3 rotation axis, same as position
To save space since rotations don't have to be as accurate and have generally smaller numbers than position so we can use 8 values of accuracy for rotation instead of 16. This saves us 3 Bytes per packet! Making our rotation packet size a small 21 Bytes.
Rotation will use 630 Bytes of data per second
We're not done yet, we still need information on throttle input, steering, brake input, gear selection, lap times, sector times, current speed, tire condition, fuel amount, and what player it is.
Thr: 8bit val = 5 bytes per FPS = 150 Bytes
Brk: 8 bit val = 5 bytes per FPS = 150 Bytes
Str: 8 bit val = 5 bytes per FPS = 150 Bytes
Fuel: 8 bit val = 6 bytes per second (Per FPS sounds excessive.)
TireC: 8 bit val = 7 bytes per second
Gear: 8 bit val = 6 bytes per FPS = 180 Bytes
Spd: 8 bit val = 5 bytes per FPS = 150 Bytes
Sect: SectX + time = 8 Bytes per section (I think?)
LapT: Time = 6 Bytes per section
We need to know what car they are in right?
An efficient system could possibly only use 5 bytes per fps per category.
Car knowledge will use 1800 Bytes of data per second
That is for a 2 person lobby. Lets add it up to see how much it stresses the internet.
720 + 630 + 450 + 13 + 180 +150 + 14 + 1800 /1000 = 3.957KB/s
Our bottleneck in the connection is the upload speed of 78KB/s now that we know per peer we can figure out what the pressure on our host is. We can simply divide 78 by 3.957 to find how many players we can network together.
78/3.957 = 19.7 connections.
And we can't have 0.7 people playing so its 19. Which an increase from 16 to 19 doesn't sound like much fun. PD probably did the exact same test that I just did, and that's why our numbers were so close together. I think I may have been a little conservative, so 16 sounds perfect. If you want GT7 to have a 32 car grid. You better update your old DSL connections quickly, if you have a connection like our example here.
Day #2 Optimization and correction of errors made in the original post
Adding in RPMs, apparently I accidentally forgot RPM, so I will add it now.
RPM: 8 bit val = 5 bytes of information, every FPS, that is 150 Bytes per second.
Optimization!
Do we really need to update position and rotation EVERY FPS? We have all of the components to drive the car already, so it's more of a correction thing. We could likely lower it from every 30 fps to every 10 FPS, and not notice any change in quality.
Position will use 240 Bytes of data per second instead of 720.
Rotation will use 210 Bytes of data per second instead of 630.
@daan questioned my use of car information per FPS. And why it was needed. It is actually player information, so that cars can be in different positions at the same time. And after thinking about it, it does not need to be updated every FPS per category, it only needs to be updated every update per category which saves us a lot of work.
Position updates 10 times = 50 Bytes
Rotation updates 10 times = 50 Bytes
thr, brk, and str update 30 times each = 450 Bytes
fuel, tires update 1 time each = 10 Bytes
Gear, Spd, and RPM update 30 times each = 450 Bytes
Sect and LapT = 10 Bytes in a rough second.
100 + 900 + 20 = 1020. MUCH BETTER THAN 1800!!!!!!!!
Over connectivity per player will be:
240 + 210 + 450 + 13 + 180 + 300 + 14 + 1020 /1000 = 2.427 KB/s
78/2.427 = 32.13 connections, BUT we want to have a little extra for features like text chat. And for players joining in the middle of a game. 24 Players is completely reasonable. 32 is also reasonable if the host has an upload speed higher than 78 KB/s
Last edited:
Le Mans is 56.
