Network caused fps drop

After quite a long time flying around in frontier I returned to core, and vola, network induced little stutter/fps drops are back. Granted ED for me is reliable and better than before (in past game was unplayable when at least 5 pilots were around). But wondering, how many you get constant 10 - 15 fps drop (from 60fps) when flying with other commanders in system. It's certainly gets better at some points, and there's no constant issues either - got 8 commanders at station and it was all relatively smooth.

So question is - how many suffer frame drops when others around (most visibly in supercruise)? Are these issues are reported? Wondering do I have to do some bug debugging.

p.s. I am not talking about stuttering per se, just specific fps slowdown when other commanders are around
 
Yep, and in a stutter thread in the bugs forum I posted some data to show a correlation between data usage, drop off of frame rate, and reduction in GPU utilisation. As far as I am aware no one has picked up on it though. Can't be bothered to collect the data again at the moment.
 
Check your network logs.

if it's full of stuff like:
{22:38:56} Low flow,199, 170075604657034 x 10 [1/2]((Relay))Name Unknown: should send something to re-establish link
{22:39:44} Low flow,-8340, 170075604657034 x 35 [1/2]((Relay))Name Unknown: should send something to re-establish link
{22:39:44} retry fail: seq=3fee, ackhwm=3fed, tslr=71.35
{22:39:44} Machine 170075604657034 x 34 [1/2]((Relay))Name Unknown disconnected: Too many retries
{22:39:44} allow machine to time out immediately after forced disconnect (ed-31797)

Then the stutter is probably peeps on bad connections.

If you are so inclined - you can have a look at your router logs too - and see their connection to you peter out - usually increasing ping times, malformed / discarded UDP packets - or sometimes the connection just instantly dies (cable pullers) and Elite times them out.
 
Last edited:
Check your network logs.

if it's full of stuff like:
{22:38:56} Low flow,199, 170075604657034 x 10 [1/2]((Relay))Name Unknown: should send something to re-establish link
{22:39:44} Low flow,-8340, 170075604657034 x 35 [1/2]((Relay))Name Unknown: should send something to re-establish link
{22:39:44} retry fail: seq=3fee, ackhwm=3fed, tslr=71.35
{22:39:44} Machine 170075604657034 x 34 [1/2]((Relay))Name Unknown disconnected: Too many retries
{22:39:44} allow machine to time out immediately after forced disconnect (ed-31797)

Then the stutter is probably peeps on bad connections.

If you are so inclined - you can have a look at your router logs too - and see their connection to you peter out - usually increasing ping times, malformed / discarded UDP packets - or sometimes the connection just instantly dies (cable pullers) and Elite times them out.

Another terrible 'reason' for stuttering. Why should a network timeout cause a visual artefact???
 
Another terrible 'reason' for stuttering. Why should a network timeout cause a visual artefact???

Because it's multi threaded application, however threads will lock for safety reasons - to protect data it has - so you would get very small lock on graphics thread due of not getting all networking data. This however can be carefully improved.

Programming - anything more complex than minesweeper and you are in the world of pain my friend.
 
Because it's multi threaded application, however threads will lock for safety reasons - to protect data it has - so you would get very small lock on graphics thread due of not getting all networking data. This however can be carefully improved.

Programming - anything more complex than minesweeper and you are in the world of pain my friend.

I don't do much multi-threaded programming but I find it hard to imagine why network and rendering should interact directly, and therefore in my limited imagination they shouldn't need to do locking in such a way that they can directly cause each other to hang for anything more than a few microseconds per second...
 
I don't do much multi-threaded programming but I find it hard to imagine why network and rendering should interact directly, and therefore in my limited imagination they shouldn't need to do locking in such a way that they can directly cause each other to hang for anything more than a few microseconds per second...

Depends how precisely you want other commanders to redraw really. If refresh rate is considerably high, then you will get stutter when having issues with some of connections.

But as I said, these certainly can be improved. They already have, as 1.2 with more than 3 players in supercruise was problematic for me. Now it's just a 10 fps drop which I can tolerate (hoping it will be improved in future).
 
I love this game.. But my fps has dropped from a solid 60 to a painful 15 fps whilst in supercruise, so I won't be playing until this is fixed... Again!
 
After quite a long time flying around in frontier I returned to core, and vola, network induced little stutter/fps drops are back. Granted ED for me is reliable and better than before (in past game was unplayable when at least 5 pilots were around). But wondering, how many you get constant 10 - 15 fps drop (from 60fps) when flying with other commanders in system. It's certainly gets better at some points, and there's no constant issues either - got 8 commanders at station and it was all relatively smooth.

So question is - how many suffer frame drops when others around (most visibly in supercruise)? Are these issues are reported? Wondering do I have to do some bug debugging.

p.s. I am not talking about stuttering per se, just specific fps slowdown when other commanders are around

The worst I've had is around 30-40 fps with around 8 commanders in SC, but this was in a beta test patch, normally SC is at around 160-200 fps, it's definitely network code, probably used to give packets a bit of time to keep player position consistency.
 
Depends how precisely you want other commanders to redraw really. If refresh rate is considerably high, then you will get stutter when having issues with some of connections.

But as I said, these certainly can be improved. They already have, as 1.2 with more than 3 players in supercruise was problematic for me. Now it's just a 10 fps drop which I can tolerate (hoping it will be improved in future).

I can tolerate rubber banding, players lagging and all other things, what I can't tolerate is forced dropping up to 120 fps, the game hardly renders anything as it is.
 
I can tolerate rubber banding, players lagging and all other things, what I can't tolerate is forced dropping up to 120 fps, the game hardly renders anything as it is.

Rendering isn't really the problem. It's the losses, and timeouts on UDP from peeps on tin-cans-and-string connections, or even good connections peered with someone on ancient voiceband tech. Or everyone on wonderful connections but geolocated out of the matchmakers network health parameters.

Elite doesn't use TCP - which would give some acknowledge/correct/retry ability to the networking. The thing is - it doesn't use TCP for very good reasons

See here for a very good outline. http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
 
My gameplay can be beautifully smooth one day, and stuttering the next time i login, even if it's the same system etc. or even if its just after a quick break.

All framerates, gpu usage cpu usage etc are all nice and low. However every time it stutters, the frametime spikes from nothing to hundreds for mili seconds which is why we stutter. It does seem more to do with networking as it's waiting for packet information that it needs to render the next frames, ie ship locations etc (just a guess).

It's one of the reasons that stutter is a lot less in closed play (taking peoples word on it as i only play in open)
 
Rendering isn't really the problem. It's the losses, and timeouts on UDP from peeps on tin-cans-and-string connections, or even good connections peered with someone on ancient voiceband tech. Or everyone on wonderful connections but geolocated out of the matchmakers network health parameters.

Elite doesn't use TCP - which would give some acknowledge/correct/retry ability to the networking. The thing is - it doesn't use TCP for very good reasons

See here for a very good outline. http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/

Oh nice simple out line.
This ones better for getting dirty http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html ;)

Rendering is the problem for me, since the network issues cause the fps to drop, but that just my personal choice, I would rather have other players rubber banding around and I have a stable 140+ fps.
 

Deleted member 38366

D
--- Deleted ---
 
Last edited by a moderator:
I had that experience in Diablo 3 with FPS drop. It's related to client - server connection.
So, with ED is the same case.
 
I saw this a long time ago too, same time as Timbow looked into it. Not seen it for a while but then, to be honest, I hardly see any real world players in the game anyway. I also struggle to understand why waiting network I/O should force a delay on rendering the entire scene. It's a massive immersion-breaker. I'm fine with people rubber-banding around, but the whole rendered scene suffering as a result is just... urrrrgh.
 
Because it's multi threaded application, however threads will lock for safety reasons - to protect data it has - so you would get very small lock on graphics thread due of not getting all networking data. This however can be carefully improved.

Programming - anything more complex than minesweeper and you are in the world of pain my friend.

I am wondering how this reasoning applies to the spinning ship screen. In that screen, which stutters on my pc, surely there is no locking going on between the network and graphics threads?
 
Back
Top Bottom