Same here with the 20+fps. What I have found weird is when I am on the mercenary missions and am engaging the pirates often times my fps drops down to sub 10 fps while it doesn't when flying around port Olisar with many players coming and going.
Clive Johnson CIG dispel some myths that get repeated quite a lot...
- Thread starter Mich Angel
- Start date
AstroGimp01
Space Marshal
So I have been doing some TESTing and have some interesting results to report, at least to me.
I spent hours last night on my rig, first I had an error that was claiming 8GB as hardware reserved memory that scared the shit out of me (fixed by reseating one 8GB stick into another slot), then I went all the way through the Win10 Gaming Tweak guide as well as the USER.cfg guide, and I have found that setting RSI Launcher and Star Citizen to HIGH for CPU priority had a noticeable difference, maybe 3 FPS or so, I changed pagefile to system controlled on my SSD, and I also changed resolution from 1920x1080 Very High to 2560x1440 Very High, and am now better than I was before, 12-17 FPS with occasional drops to 9 - but peaks to 20-ish - plus it is so much prettier now though.
CPU load is about the same, and GPU load is now up to 50-60% with all the VRAM used (3.9GB of 4GB). SSD usage seems better with system managed vs fixed size, but transfer rates look to be 70+ MB/sec sometimes near as I can tell dropping into Task Manager/Performance so not sure I am getting the speed out of it which would explain why I have not seen the dramatic increases others have reported. More to do here I think - and yes, Samsung RAPID Mode is on, I think.
I have also finally spent time watching the ping report from CIG in the FPS display, and see a correlation between Ping <100 ms and >100ms. It is exponential on my system, the further below 100ms it gets, the better my FPS gets which makes sense, but is something I had not noticed as clearly before.
I ping tested my system with and without a set DNS, it tests at a mean of 14 ms with no set DNS, and with Google as DNS it tested 15 mean - I routinely see 80-300 ms pings in SC the higher the ping the slower the FPS, with 100 ms correlating to 10 FPS for me, on average.
Learning more and more about gaming and computers I muyst say.
'Gimp
I spent hours last night on my rig, first I had an error that was claiming 8GB as hardware reserved memory that scared the shit out of me (fixed by reseating one 8GB stick into another slot), then I went all the way through the Win10 Gaming Tweak guide as well as the USER.cfg guide, and I have found that setting RSI Launcher and Star Citizen to HIGH for CPU priority had a noticeable difference, maybe 3 FPS or so, I changed pagefile to system controlled on my SSD, and I also changed resolution from 1920x1080 Very High to 2560x1440 Very High, and am now better than I was before, 12-17 FPS with occasional drops to 9 - but peaks to 20-ish - plus it is so much prettier now though.
CPU load is about the same, and GPU load is now up to 50-60% with all the VRAM used (3.9GB of 4GB). SSD usage seems better with system managed vs fixed size, but transfer rates look to be 70+ MB/sec sometimes near as I can tell dropping into Task Manager/Performance so not sure I am getting the speed out of it which would explain why I have not seen the dramatic increases others have reported. More to do here I think - and yes, Samsung RAPID Mode is on, I think.
I have also finally spent time watching the ping report from CIG in the FPS display, and see a correlation between Ping <100 ms and >100ms. It is exponential on my system, the further below 100ms it gets, the better my FPS gets which makes sense, but is something I had not noticed as clearly before.
I ping tested my system with and without a set DNS, it tests at a mean of 14 ms with no set DNS, and with Google as DNS it tested 15 mean - I routinely see 80-300 ms pings in SC the higher the ping the slower the FPS, with 100 ms correlating to 10 FPS for me, on average.
Learning more and more about gaming and computers I muyst say.
'Gimp
So what they are basically saying is that the netcode is fine, the server performance/netcode has nothing to do with the client framerate being so utterly shit as it is not slowing down anything.... yeaaaaah, I bet that's just simply not true in that form. I'm guessing it grossly oversimplifies the issue.
Look, I believed that the game was unplayable most of the time, cos the networking stuff was broken. You want me to change years of hardcore belief in my PC's adequateness? Pull the ground from under my feet by telling me that the fault doesn't lie in the netcode and servers? Kill this ancient tradition of blaming low performance on the netcode, which was based on nothing but baseless speculation by my drunken fellow Testies and some random ppl on youtube? Huh? Really?! You want me to throw away all the knowledge imparted onto me by my fellow beer lovers?!!
Then you gotta do better then a few lines of "nope, not the networking stuffs fault", sonny boy Clive!!!
Oh. You are an actual dev, so you won't do better than that. Okay. I guess I'll be going then.
So I jumped in to see how performance was doing as I haven't played since last week. I caught a moment on Olisar when 2 players suddenly started moving on screen, and another one was opening the door to the room just a tenth of a second after the screenshot was taken. These "small" things happening bumped my CPU and GPU usage up from 79% and 29% to 82% and 34% respectively. So why would a simple character animation take up so much more CPU and GPU time? It's kinda unrealistic, unless something in the code is dependent on an information that's not available from local memory. As everything is right there on screen already and in memory, being constantly calculated (bones-skin-clothes animations) , that means that the missing data comes from outside. From the servers. And that means it IS fucking netcode dependent....Hah! Or not. Maybe it was something entirely different. Like a ship blew up at the same moment. Or windows update had a hiccup. Who knows?
Important thing to point out, is that After they started moving, the CPU and GPU usage went back down to the same percentages as before and didn't spike again, no matter if they moved or stopped or even run off or on screen again! The guy in the white suit had come up and salute to me, and all percentages stayed the same throughout! So... this is basically useless information that tells nothing :D
Another interesting tidbit: I installed 3.0 on my wife's PC so we could play together and it worked. Whats very strange, is that initially, when spawning on Olisar and running around there for like 2-3 minutes (before the ram gets filled with crap), her PC gets better framerates by 3-5fps, on the same server at the exact same time!
It's an old 3xxx i5 with only 8gigs of ram and an old 750ti 2gig! I got 16 gigs, a faster and a bit newer i5 and a goddamn 1060 6gb! Yet that machine gets the better framerates??
The important difference? Her's is plugged in to the router, while my PC is on 5GHz ac WiFi !
So yeah, throughput and "clean" network traffic is quiet important to actual framerate!
TLDR.: PU framerate IS bottlenecked by networking. Use an ethernet cable if u can instead of wifi for +0-2000 fps gain, and pray for optimisations to come sooner than 3.0 did.
PS.: actually, it's no real surprise that a 750ti and an old i5 can run SC just fine. I had this game running on that gpu with my decade old first gen. Core2Duo and 3 gigs of ram back when Arena Commander was launched, and don't forget that it is still the same engine beneath all that, despite all the shiny awesome upgrades they did to it lol
Look, I believed that the game was unplayable most of the time, cos the networking stuff was broken. You want me to change years of hardcore belief in my PC's adequateness? Pull the ground from under my feet by telling me that the fault doesn't lie in the netcode and servers? Kill this ancient tradition of blaming low performance on the netcode, which was based on nothing but baseless speculation by my drunken fellow Testies and some random ppl on youtube? Huh? Really?! You want me to throw away all the knowledge imparted onto me by my fellow beer lovers?!!
Then you gotta do better then a few lines of "nope, not the networking stuffs fault", sonny boy Clive!!!
Oh. You are an actual dev, so you won't do better than that. Okay. I guess I'll be going then.
If you paid attention to ATVs and dev interviews that explained how the physics, animation and lot's of other systems are built into the game, it's pretty clear we are actually limited by how fast their servers can give us the feedback on stuff. A lot of it needs to be either calculated or verified and transmitted by the server. This is the case with multiplayer games anyways...
My guide to basic multiplayer for dummies states: you push button - your pc calculates stuff (or skips this step entirely) - info goes to server - server crunches it - commands/data comes back that tells your pc what the hell just happened - thing happens on your screen. Some of this goes on entirely on your side, some entirely server side, but in the case of Satr Citizen, almost EVERYTHING needs to go through the server in some limited way at least, or the other players won't see the same things happening that you see.
This is called being in sync with the server. If for some reason this can't happen often enough and fast enough, you either get out of sync and see weird shit happen (rubberbanding, invincible enemies, teleporting objects, stuff stuck inside walls, the usual..), or it has to slow the update rate of some component (physics is the usual suspect here) of the update process to get everything right.
One thing I noticed about the facts posted by the actual developer, the GRAPHICS pipeline doesn't wait. He never said that ALL the other pipes that the graphics are slaved to, don't have to wait for server input!
Drawing 1 frame is just a Part of a cycle! Although some pipelines are running in parallel, some have to run in a linear order, so the graphics pipeline is not independent of the other pipelines of course! This means that while the other pipes wait for input from the network, the graphics pipeline (drawing the picture) part of the cycle has to wait in line for at least some of those pipes to get it's share of the limited CPU and GPU time! The very low GPU usage on modern cards is a really good indication that it is waiting on something. In this case it is probably another pipeline. As best I can recall from ATVs, it follows the physics pipe.
If it would be independent, we would get much higher GPU usage all the time with much higher framerates (like in single player), while everything around the player would still play out as a stop motion animation because of the other pipelines lagging behind, waiting on the network.
Devguy said that thing no slowy downy cos of netcode, huh?
In my mind, this implies that if network input lags behind, the player will rather get out of sync, but performance won't suffer. And this is the part where experience shows that it's probably not as simple as that. While we do get partially desynced all the time, any time I have better pings and a "cleaner" connection, I get better frame rates.
Now the explanation above by CIG was that if there are less players on fresh servers, our machines don't have to calculate with so much stuff. And just what are these things our Client machine has to calculate soooo much, prey tell? Let's try to find out!
Physics? Not unless it interacts with the local player, it doesn't. It shouldn't at least, that would be purely stupid and unsyncable. Have you ever tried a real time physics sim in a game or other software? You would get different results on every single machine! Heck, depending on the sim system, you get different results every time you run the sim! How could that be of any use, in a world where everyone is supposed to see the same thing? Yet SC seems to do it this way for some objects, for now at least, so yeah, this might be an issue IF it doesn't get the neccesary info from the Network fast enough. Especially if the object on your screen is simulated both locally and on the other players pc locally, and the server needs to correct it's position every frame, from the data recieved from both clients? Yeah, that can slow things down quiet a bit. So a culling system is in order here, to not simulate anything that doesn't specifically need it, especially not "twice"!
**Look, why would your machine have to calculate what an other player's Aurora is doing 900kKm away in the docking bay of Levsky? It shouldn't even load it into memory ffs, let alone calculate physics and shit for that ship and it's components.... Yet it seems like it does, from the insanely high RAM usage, the odd spikes in CPU and GPU usage, to total freezing of the client when someone with a couple of cargo crates blows up half a star system away. I know they are working on culling these things, I think it was even tested in the closed PTU phase of 3.0 although only for like an hour or so, and I hope it gets implemented sooner than later, but it seems like a huge step they haven't solved, yet it was present since the beginning of PU.**
IFCS? Why would our clients calculate the IFCS of everyone else's ships in multiplayer? How could you keep that synced up, instead of just syncing positions and velocity vectors for objects, like you know, every multiplayer game ever that actually works? And this requires sooo much calculation? Looking at single player arena commander when IFCS is calculated locally for all ships, yet my fps hits above a 100 sometimes, but at least hits 70. This show's that even if it happens real time for the 10-20 something ppl around, it's not a heavy calculation at all. I'm pretty sure they got IFCS local calculations down to as fast as possible. So what's limiting here? I dunno, netcode? IFCS is waiting on updates from the server? So yeah, Clive said it's not the Netcode! so let's keep looking!
Animation? Hmm, yeah, this could be a good contender for slowdowns. Although, I get the exact same framerate, once everything's loaded mind you, with 3 players running around me and no one on screen or near me. Strange. So this is not a limiting factor unless the animation pipe is waiting for input from something...THE NETCODE! ffs, that can't be it, back to square one again...
Entity Updates! Yay, this means all the objects around the verse, need their position, velocities, moods, bladder status and all the rest updated constantly! This is the bit that's causing the real issues I think. This is where thousands of objects get their updates even when they don't need any, and the system is waiting on them.
How is entity #36492hdh896324 doing? asks your Client from the Server. And it won't finish it's update cycle until it hears from the server, so it waits, while asking the same question from millions of other entities, so it can update your universe with up-to-date data on everything.
Entity #36492hdh896324 meanwhile, is the upper left bolt head sticking out proudly from a pillar in of the corners of Port Olisar strut C. Which means it Never Does Anything apart from moving along in space with the pillar it's attached to, which moves along with a floor it's attached to, which moves along with the space station it's attached to! So it should never, ever need an update of it's own. Yes, I exaggerate here, but it wasn't too long ago when this level of "entity updates" were an actual issue.
Yet, as I understand from previous ATVs, this sort of issue still exists and a working solution is... being worked on. So again, it is a network issue! But nah, it can't be...
Looking at my CPU and GPU usage, it seems like everything is waiting for something to happen. Some data to tell the underlying systems what to calculate, and it bottlenecks the whole thing. I get the same baseline of 18-23 fps with 5 players as I got with 45...
So anyways, devguy states that netcode is faaaast, no worries about that. Well, I either call bullshit on that, or there really is nothing more to be done with that. In that case, everything else, the pipelines, need to be less network dependant! In part, this might be the optimisations he is referring to, and we shall see it soonTM.
My guide to basic multiplayer for dummies states: you push button - your pc calculates stuff (or skips this step entirely) - info goes to server - server crunches it - commands/data comes back that tells your pc what the hell just happened - thing happens on your screen. Some of this goes on entirely on your side, some entirely server side, but in the case of Satr Citizen, almost EVERYTHING needs to go through the server in some limited way at least, or the other players won't see the same things happening that you see.
This is called being in sync with the server. If for some reason this can't happen often enough and fast enough, you either get out of sync and see weird shit happen (rubberbanding, invincible enemies, teleporting objects, stuff stuck inside walls, the usual..), or it has to slow the update rate of some component (physics is the usual suspect here) of the update process to get everything right.
One thing I noticed about the facts posted by the actual developer, the GRAPHICS pipeline doesn't wait. He never said that ALL the other pipes that the graphics are slaved to, don't have to wait for server input!
Drawing 1 frame is just a Part of a cycle! Although some pipelines are running in parallel, some have to run in a linear order, so the graphics pipeline is not independent of the other pipelines of course! This means that while the other pipes wait for input from the network, the graphics pipeline (drawing the picture) part of the cycle has to wait in line for at least some of those pipes to get it's share of the limited CPU and GPU time! The very low GPU usage on modern cards is a really good indication that it is waiting on something. In this case it is probably another pipeline. As best I can recall from ATVs, it follows the physics pipe.
If it would be independent, we would get much higher GPU usage all the time with much higher framerates (like in single player), while everything around the player would still play out as a stop motion animation because of the other pipelines lagging behind, waiting on the network.
Devguy said that thing no slowy downy cos of netcode, huh?
In my mind, this implies that if network input lags behind, the player will rather get out of sync, but performance won't suffer. And this is the part where experience shows that it's probably not as simple as that. While we do get partially desynced all the time, any time I have better pings and a "cleaner" connection, I get better frame rates.
Now the explanation above by CIG was that if there are less players on fresh servers, our machines don't have to calculate with so much stuff. And just what are these things our Client machine has to calculate soooo much, prey tell? Let's try to find out!
Physics? Not unless it interacts with the local player, it doesn't. It shouldn't at least, that would be purely stupid and unsyncable. Have you ever tried a real time physics sim in a game or other software? You would get different results on every single machine! Heck, depending on the sim system, you get different results every time you run the sim! How could that be of any use, in a world where everyone is supposed to see the same thing? Yet SC seems to do it this way for some objects, for now at least, so yeah, this might be an issue IF it doesn't get the neccesary info from the Network fast enough. Especially if the object on your screen is simulated both locally and on the other players pc locally, and the server needs to correct it's position every frame, from the data recieved from both clients? Yeah, that can slow things down quiet a bit. So a culling system is in order here, to not simulate anything that doesn't specifically need it, especially not "twice"!
**Look, why would your machine have to calculate what an other player's Aurora is doing 900kKm away in the docking bay of Levsky? It shouldn't even load it into memory ffs, let alone calculate physics and shit for that ship and it's components.... Yet it seems like it does, from the insanely high RAM usage, the odd spikes in CPU and GPU usage, to total freezing of the client when someone with a couple of cargo crates blows up half a star system away. I know they are working on culling these things, I think it was even tested in the closed PTU phase of 3.0 although only for like an hour or so, and I hope it gets implemented sooner than later, but it seems like a huge step they haven't solved, yet it was present since the beginning of PU.**
IFCS? Why would our clients calculate the IFCS of everyone else's ships in multiplayer? How could you keep that synced up, instead of just syncing positions and velocity vectors for objects, like you know, every multiplayer game ever that actually works? And this requires sooo much calculation? Looking at single player arena commander when IFCS is calculated locally for all ships, yet my fps hits above a 100 sometimes, but at least hits 70. This show's that even if it happens real time for the 10-20 something ppl around, it's not a heavy calculation at all. I'm pretty sure they got IFCS local calculations down to as fast as possible. So what's limiting here? I dunno, netcode? IFCS is waiting on updates from the server? So yeah, Clive said it's not the Netcode! so let's keep looking!
Animation? Hmm, yeah, this could be a good contender for slowdowns. Although, I get the exact same framerate, once everything's loaded mind you, with 3 players running around me and no one on screen or near me. Strange. So this is not a limiting factor unless the animation pipe is waiting for input from something...THE NETCODE! ffs, that can't be it, back to square one again...
Entity Updates! Yay, this means all the objects around the verse, need their position, velocities, moods, bladder status and all the rest updated constantly! This is the bit that's causing the real issues I think. This is where thousands of objects get their updates even when they don't need any, and the system is waiting on them.
How is entity #36492hdh896324 doing? asks your Client from the Server. And it won't finish it's update cycle until it hears from the server, so it waits, while asking the same question from millions of other entities, so it can update your universe with up-to-date data on everything.
Entity #36492hdh896324 meanwhile, is the upper left bolt head sticking out proudly from a pillar in of the corners of Port Olisar strut C. Which means it Never Does Anything apart from moving along in space with the pillar it's attached to, which moves along with a floor it's attached to, which moves along with the space station it's attached to! So it should never, ever need an update of it's own. Yes, I exaggerate here, but it wasn't too long ago when this level of "entity updates" were an actual issue.
Yet, as I understand from previous ATVs, this sort of issue still exists and a working solution is... being worked on. So again, it is a network issue! But nah, it can't be...
Looking at my CPU and GPU usage, it seems like everything is waiting for something to happen. Some data to tell the underlying systems what to calculate, and it bottlenecks the whole thing. I get the same baseline of 18-23 fps with 5 players as I got with 45...
So anyways, devguy states that netcode is faaaast, no worries about that. Well, I either call bullshit on that, or there really is nothing more to be done with that. In that case, everything else, the pipelines, need to be less network dependant! In part, this might be the optimisations he is referring to, and we shall see it soonTM.
So I jumped in to see how performance was doing as I haven't played since last week. I caught a moment on Olisar when 2 players suddenly started moving on screen, and another one was opening the door to the room just a tenth of a second after the screenshot was taken. These "small" things happening bumped my CPU and GPU usage up from 79% and 29% to 82% and 34% respectively. So why would a simple character animation take up so much more CPU and GPU time? It's kinda unrealistic, unless something in the code is dependent on an information that's not available from local memory. As everything is right there on screen already and in memory, being constantly calculated (bones-skin-clothes animations) , that means that the missing data comes from outside. From the servers. And that means it IS fucking netcode dependent....Hah! Or not. Maybe it was something entirely different. Like a ship blew up at the same moment. Or windows update had a hiccup. Who knows?
Important thing to point out, is that After they started moving, the CPU and GPU usage went back down to the same percentages as before and didn't spike again, no matter if they moved or stopped or even run off or on screen again! The guy in the white suit had come up and salute to me, and all percentages stayed the same throughout! So... this is basically useless information that tells nothing :D
Another interesting tidbit: I installed 3.0 on my wife's PC so we could play together and it worked. Whats very strange, is that initially, when spawning on Olisar and running around there for like 2-3 minutes (before the ram gets filled with crap), her PC gets better framerates by 3-5fps, on the same server at the exact same time!
It's an old 3xxx i5 with only 8gigs of ram and an old 750ti 2gig! I got 16 gigs, a faster and a bit newer i5 and a goddamn 1060 6gb! Yet that machine gets the better framerates??
The important difference? Her's is plugged in to the router, while my PC is on 5GHz ac WiFi !
So yeah, throughput and "clean" network traffic is quiet important to actual framerate!
TLDR.: PU framerate IS bottlenecked by networking. Use an ethernet cable if u can instead of wifi for +0-2000 fps gain, and pray for optimisations to come sooner than 3.0 did.
PS.: actually, it's no real surprise that a 750ti and an old i5 can run SC just fine. I had this game running on that gpu with my decade old first gen. Core2Duo and 3 gigs of ram back when Arena Commander was launched, and don't forget that it is still the same engine beneath all that, despite all the shiny awesome upgrades they did to it lol
Just so you know, you're not wrong. It is oversimplified, but not incorrect. CIG is being partly ah... not quite misleading. It's not even a white lie, it's just strictly true, but not the whole truth. The server code, and the netcode have to do with object state calculations, and object state transfer, and has nothing strictly to do with client frame rate, that is true. That is not the same as saying the network performance does not have an impact on frame rate. It does, and as you demonstrated, it can be a big impact.
Some people think that WiFI at 2.5 or 5 GHz should operate faster than Ethernet cable, and in some conditions it can be. But the channel that each wifi connection uses is only 20 MHz wide. To make WiFi matters worse, the 2400-2500 band consists of overlapping and very crowded channels AND microwave ovens use a 12 cm wave, that's 2450 MHz - right smack in the middle.
If you want to maximize WiFi, use the 5 GHz band, it consists of non overlapping channels, and isn't competing with the microwave oven in the kitchen. But even it is stacks of 20MHz wide channels.
Thing is, Cat 5 cable is rated at 100 MHz, over 100 meters. That's 5 times the bandwidth. Cat 6 is 250-500, and cat 7 is 600 MHz. So yeah, wire is actually faster than WiFi.
Okay maybe I should try again but saying tweak this and tweak that to get just poor performance 20fps is not exactly inviting the masses to play (sorry alpha Test).
This conversation on reddit at least has been going on a while and whilst I have no doubt some of the poor performance is at my end I have no intention at all of purchasing a new computer (lets be honest it will be out of date before any release). The ships are not sold with minimum very high end pc requirements warnings.
This conversation on reddit at least has been going on a while and whilst I have no doubt some of the poor performance is at my end I have no intention at all of purchasing a new computer (lets be honest it will be out of date before any release). The ships are not sold with minimum very high end pc requirements warnings.
AstroGimp01
Space Marshal
I think I finally get it, now understand I am an aerospace engineer not a computer science guy and am a very casual gamer who can change things in a desktop but have not 'built' a computer - but this is what makes sense to me.
As I think I understand it - the ping delays are because of how CIG has implemented some of the communication server-to-client - specifically related to objects/physics and some other systems modelling (the 'fidelity' mantra)- the busier the server gets, the slower the ping.
In my case, my system is not working hard - yes the game plus Windows and stuff I can't turn off occupy most of the RAM, but CPU load across all six cores is 50-70%, and GPU load is 30-50% at 1080 and 50-70% at 1440.
My frame rate has an inverse relationship to ping with 100ms = 10-11 FPS, 150ms = 8 FPS, 150-200ms = 6 FPS, 300ms = 4 FPS, etc. 80ms = 15 FPS, 70ms = 17 FPS, and when ping is 40ms or better the FPS is over 30, 20ms = 60 FPS.
By way of comparison, on my old R7 360 2GB GPU on 2.6.3 I saw high 20 FPS all the time, it was totally playable including PVE and PVP dogfighting, I do not engage in ship-to-ship or FPS style combat in 3.0 because of the poor FPS/latency.
So, while technically true that the netcode is not throttling FPS, the passage of time client-side appears to be related to FPS and FPS is directly related to server responsiveness (e.g., ping). The servers are still the limiting factor but it is not the same from one client to another.
Now what I don't understand is why some streamers like Sitarow get a consistent 30-ish ms ping, and I get a consistent 80-150ms ping - could be mechanical issues with my installation, e.g., cables, etc, could be my ISP (but for a straight ping speed test I see 13-15ms consistently), but the limitation that is driving my low FPS appears to be server responsiveness and that is not on my end (and it does not appear to be consistent across the user base).
I'm going to continue working to improve things on my end but I now feel like the frame rate issues I have are being driven by the server and are no longer a hardware limitation on my end (e.g., RAM, CPU, GPU).
Not sure that makes sense to anyone else but it is the only thing that makes sense to me based on my observations.
'Gimp
As I think I understand it - the ping delays are because of how CIG has implemented some of the communication server-to-client - specifically related to objects/physics and some other systems modelling (the 'fidelity' mantra)- the busier the server gets, the slower the ping.
In my case, my system is not working hard - yes the game plus Windows and stuff I can't turn off occupy most of the RAM, but CPU load across all six cores is 50-70%, and GPU load is 30-50% at 1080 and 50-70% at 1440.
My frame rate has an inverse relationship to ping with 100ms = 10-11 FPS, 150ms = 8 FPS, 150-200ms = 6 FPS, 300ms = 4 FPS, etc. 80ms = 15 FPS, 70ms = 17 FPS, and when ping is 40ms or better the FPS is over 30, 20ms = 60 FPS.
By way of comparison, on my old R7 360 2GB GPU on 2.6.3 I saw high 20 FPS all the time, it was totally playable including PVE and PVP dogfighting, I do not engage in ship-to-ship or FPS style combat in 3.0 because of the poor FPS/latency.
So, while technically true that the netcode is not throttling FPS, the passage of time client-side appears to be related to FPS and FPS is directly related to server responsiveness (e.g., ping). The servers are still the limiting factor but it is not the same from one client to another.
Now what I don't understand is why some streamers like Sitarow get a consistent 30-ish ms ping, and I get a consistent 80-150ms ping - could be mechanical issues with my installation, e.g., cables, etc, could be my ISP (but for a straight ping speed test I see 13-15ms consistently), but the limitation that is driving my low FPS appears to be server responsiveness and that is not on my end (and it does not appear to be consistent across the user base).
I'm going to continue working to improve things on my end but I now feel like the frame rate issues I have are being driven by the server and are no longer a hardware limitation on my end (e.g., RAM, CPU, GPU).
Not sure that makes sense to anyone else but it is the only thing that makes sense to me based on my observations.
'Gimp
Last edited:
That might be all she wrote, all it can do on your hardware for now. Clive also touched on something else, but didn't offer much explanation in his last paragraph. Ultimately he said, "Let's also not forget that performance is not the only goal here - we're also trying to achieve fidelity levels not seen before. Fidelity is often the enemy of performance, so we find ourselves having to optimize even further than we otherwise would have had to."
In short, what he said is, in order to make the game as beautiful as it is, they put far more mesh objects in the game than they would otherwise have had to. Problem is from a performance perspective, each object needs to be managed by the game, and that takes time to process. It's not the end of the world because the game isn't optimized yet, and that is certainly something they need to look at. Object optimization is going to be a very big chore.
But someone, I forgot who, in Discord the other night mentioned something that might be sentient. He said, What if CIG isn't designing Star Citizen for TODAY's hardware. What if they're designing it for the hardware 5 years from now. Something struck me about this. CIG has had conversations with Intel that led to Intel's support in the last Citizencon. This is all just speculation - but that partnership suddenly made sense. If we're right, it's not about the drive and widgets, it's about technology.
I owe you a vote of thanks by the way. You had advice for me regarding take off's and the quantum mastic tape, I forgot where I wrote that so consider it liked. It works.
You're also getting the networking part down too, engineers often get this stuff before even computer professionals. Regarding ping times themselves, in a real time simulation world, we develop software with often less than 2 ms ping times. You're sitting beside the development server, or it's not more than 50 feet away over 1000BaseT so that's what we get. It's incredibly hard to be able to tell what is going to happen once you release the software "into the wild". That's RTS. This is a game, and that's even more "wild" than it gets in my business.
(I design enterprise software for scientists, not games. It's often real time simulation stuff, and a lot of network code. a ton of network code. I've been doing it for over 30 years. The thing that keeps me sane is I don't write code that often anymore, I just design it. I leave the heavy lifting to the younger folks who I mostly mentor. The operation is very similar in many respects to writing game code, it's just that the only game engines I've ever used was for simulating something - a process - and interacting with other simulations, not interacting with a person. We actually use Unity mostly for this.)
Radegast74
Space Marshal
@Vavrik --> Rules violation! If you know what you are talking about, you are *NOT* allowed to post on forums, lol!
BTW, nice chatting with you last night! Get some sleep! (because in a a couple of days, I'm going to post some questions about the game & server performance, maybe you can help me figure stuff out!)
OH! I forgot the disclaimer. I was operating under the principle that it's easier to ask forgiveness than it is to ask for permission. :stuck_out_tongue_closed_eyes:
I'll be happy to help any way I can, but there are limits to what can be done if the game isn't optimized.
Last edited:
Radegast74
Space Marshal
@Vavrik No worries! I was going to post video, but maybe that isn't necessary.
My problem is, almost all the time in my game sessions, after jumping to Grim Hex & buying cargo, when I want to jump back to Oli, about 90 seconds after leaving Grim, I get pulled back to a previous location...if I hover over the landing pads at Grim, I get bounced back down to the landing pad...if I start leaving Grim but don't jump, I get pulled back to the landing pads at Grim (except I'm going at my current speed)...if I jump and I'm near Oli, I get pulled back to some weird location around Oli.
Clearly there is some sort of discontinuity...my position isn't synching with the server's idea of where I should be. What could cause this? I'm concerned I'm on some swampy backwater of the internet, and my small-town connection to the information superhighway isn't big enough...I'm concerned this may be more of a infrastructure problem, rather than any client-server issue.
As you can imagine, this really kills the immersion, flying along one second dodging asteroids, then the next moment banging nose first against the side of Grim Hex!
About CIG designing SC for future computers... Yes, they are probably aiming for that, it is the sensible thing to do.
The problem with this, is that currently the game can't even utilise present day hardware to it's fullest. SC hardly ever uses my CPU at a 100% and killing background tasks to free up a few more percents of CPU time doesn't make any difference. This might be something really technical future tech stuff, or just an ancient engine code that is limiting.
Do you think they already know about a radical change of direction in how CPUs will work, and that's why it can't use our machines to their fullest? Or is it just cos it's an alpha stage, and that's not about optimisation.
When it comes to meshes, with properly optimized code, it should come down to the GPU to display those high fidelity meshes. Now with 30 something percent of GPU usage, and the much higher framerates in offline PU / single player AC, it's pretty clear that it's not simply the number of meshes that's killing performance. I watched the rendering pipeline presentation and they got some pretty cool, really optimized way to display stuff and it shouldn't be an issue for any mid to high-end GPU of today. High framerates in single player modes proves this pretty well.
What I'm trying to say is, I agree with you on that high fidelity - number of meshes - is killing performance, because they need to be managed first, but not because they need to be drawn on screen.
On-screen polygon counts were culled and optimized a lot since the early days! All the redesigned ships use way less meshes/polygons now than they did when 2.0 came out. I don't really like it that every panel line and small detail is now normal/parallax mapped instead of using a full on mesh. I really miss the chunky meshes of the original models, they felt way more immersive to me. Maybe it was uglier, much much more performance intensive, but somehow more next-gen immersion, to my mind at least. But it makes the game run much faster this way so it's perfectly sensible that they did it.
THAT is the quantum mastic tape! In Levski, there's a quantum spring too, it will reach up, grab you and make SURE you saw the texture of the front wall of the hanger bay. It's reached out and grabbed me after 2 quantum jumps after leaving Levski. One thing to try, is to turn your engines on, then off, then back on. That was the advice @AstroGimp01 gave me, and so far it's worked every place except Levski, where it's worked 2 out of 4 visits.
AstroGimp01
Space Marshal
Delamar also has weird gravity wells, I have been cruising along fully 2 Km above the surface at 190 M/S, just cruising to Levski from an OM and suddenly you are sucked down and nothing you do will keep you from hitting the surface at speed - of course, only happens when you have a Connie full of cargo and are already worried about getting safely down before the server crashes. Pucker Factor - Sphincter Diamond.
'Gimp
'Gimp
This is always the case and is nothing new. Many game developers for the PC use Moore's law to predict what the average PC will be with in the projected game release window and build their engine to be playable with that as the recommended specs. This way when the game is released it doesn't look dated as much as we say we are gamer's we tend like the pretty graphics more.
Tis a shame, network code writing is challenging and so I still find it pleasant. Then again I also make sure that the minions are using VM's that have been specifically crafted to have crappy connections so that when they attempt to send a full serialized object it takes years and they are reminded to optimize. Still doesn't help with 3rd party developers who make a tcp server who can't handle more then one client or handle disconnects and reconnects. Go figure.
Isn't this the primary Principle of life? Perhaps we can get @Montoya to rule on this.
Radegast74
Space Marshal
Oh, that's what was meant by that "mastic" whatever...I'll try that, thanks for interpreting for me, lol!
Actually this is because it really doesn't take much CPU power for a multi-threaded cpu to sort through the big ass RAM chunk that is paging your 40Gb file, It just takes time. The consequence is, your GPU is spending most of the time between frame rendering, wondering when the CPU will finally find the objects it's requesting. That alone can reduce the frame rate, because it's inefficient use of the GPU and CPU's time. All they need to do to fix that is complete the very onerous task of object optimization. (There's a LOT of objects to optimize) It won't go away completely, but it'll become more efficient.
Here's a concrete example, well maybe not concrete as in cement, but it's something I noticed in game. The hab doors, aren't door objects, they're composites. You'd have to check with CIG, or dig through the Data file to find out if this is right, but this is what i think:
- 1 object for the door itself,
- 2 frames for the Open/Closed plackards (one each side of the door),
- 2 plackards (one each side of the door)
- 2 Item 2.0 highlight objects which are inverted copies of the frame I think. You just invert the normals, then color the inverted faces when the user hovers the cursor over a sensitive spot.
- That's 7.
- But the sensitive spot seems to be able to offset. That might mean 2 more invisible prims that instruct their respective highlight object to light up. That's 9
How'd I figure this out? At first I didn't give it any thought at all, then I noticed things don't quite line up all the time, and sometimes they simply don't all rez. More than once, the plackard bit, the piece that says Open, is only half inside the frame, or some part is missing. You get the highlight, but nothing is there to say, "Press" when you hover over it. Sometimes if you search around you can find it elsewhere on the surface of the door. That's weird if it's only 1 object, but not if it's a composite, and my system is trying to figure out where all these overlapping objects should be rezzed.