Hi BarFly, I'll do my best to explain my thoughts on it, this is just my guess.
I'm talking about the client's capability of loading the instance, ED servers are probably much more optimized for performance consistency. Outside of their network though there is a lot of network delay variability and time to load that depends heavily on the client machine. I'm on a machine that is just about the minimum requirements for the game so there's noticeable variability in witchspace just going between the same two systems on trade runs. So that leads me to think that the configuration of the Client RAM availability and vidcard-caching mechanisms affect how long you're in witchspace while the system instance graphics & ship/player positioning and compositions get loaded.
I'm not sure what you mean exactly by the start of a second time scanning, it definitely sounds like server side work, but perhaps a syncing issue with server & client.
ED player interactions have p2p code, the 8pm spike would be noticeably different when more players are sync'ing up on the next system instance you're entering. If you're experiencing significant delay spikes way out by yourself they do probably have some server side performance issues to sort out though or maybe your local ISP doesn't handle peak well.
Just to reiterate I think the witch space latency is heavily effected by client-side loading or p2p syncing and would be surprised if they were putting significant server-side strain into on-the-fly system instance generation in real time.
Thanks!
I'm talking about the client's capability of loading the instance, ED servers are probably much more optimized for performance consistency. Outside of their network though there is a lot of network delay variability and time to load that depends heavily on the client machine. I'm on a machine that is just about the minimum requirements for the game so there's noticeable variability in witchspace just going between the same two systems on trade runs. So that leads me to think that the configuration of the Client RAM availability and vidcard-caching mechanisms affect how long you're in witchspace while the system instance graphics & ship/player positioning and compositions get loaded.
10 seconds is damn good performance for 400 billion star systems that have to be consistent for every player who visits them. To me that's 10 seconds of system search/lookup for an enormous galaxy. If it was generating systems on the fly how could I visit the same system you have and we could talk about the same objects? Even if it's only generating the first time it's discovered peak will have numerous players hitting new systems all the time. I'm comparing this to the witchspace performance differences I'm talking about all appear in well traveled space that I alone move back and forth by the same two systems on.
I'm not sure what you mean exactly by the start of a second time scanning, it definitely sounds like server side work, but perhaps a syncing issue with server & client.
ED player interactions have p2p code, the 8pm spike would be noticeably different when more players are sync'ing up on the next system instance you're entering. If you're experiencing significant delay spikes way out by yourself they do probably have some server side performance issues to sort out though or maybe your local ISP doesn't handle peak well.
Just to reiterate I think the witch space latency is heavily effected by client-side loading or p2p syncing and would be surprised if they were putting significant server-side strain into on-the-fly system instance generation in real time.
Thanks!
Last edited: