Forums » General
More server-side optimizations coming.
I have returned from California! For now, anyway..
Ray and Michael have discovered some more problem areas that we'll be optimizing in the sector code, which explicitly impact people with huge inventories. Some of this debugging has been a real pain in the arse, but we built a lot more elaborate testing systems to help us do that, which is going to be great moving forward.
There's also some other cool stuff coming. I'm hoping to address a lot of this in an upcoming newsletter. It may be called something like "Look at all the stuff we fixed!".
Also, we will probably roll out the threaded-SD "universe-wide" on Friday. It's been in partial-rollout for over a week, and has held up well.
That is all for now. This is like a newspost, except I'm not going to spend an hour carefully arranging words in press-release form. I have stuff to do.
Ray and Michael have discovered some more problem areas that we'll be optimizing in the sector code, which explicitly impact people with huge inventories. Some of this debugging has been a real pain in the arse, but we built a lot more elaborate testing systems to help us do that, which is going to be great moving forward.
There's also some other cool stuff coming. I'm hoping to address a lot of this in an upcoming newsletter. It may be called something like "Look at all the stuff we fixed!".
Also, we will probably roll out the threaded-SD "universe-wide" on Friday. It's been in partial-rollout for over a week, and has held up well.
That is all for now. This is like a newspost, except I'm not going to spend an hour carefully arranging words in press-release form. I have stuff to do.
Welcome back and thanks for all the work on fixing bugs. :)
Got any plans for putting some "lag" indicator in the game client to let players know if the game detects network problems? The "sector lag" no-hits bug went on for a long time because it was so hard to tell for sure if it was a server-side issue.
Got any plans for putting some "lag" indicator in the game client to let players know if the game detects network problems? The "sector lag" no-hits bug went on for a long time because it was so hard to tell for sure if it was a server-side issue.
Yeah, we've been talking about that internally. I passed some design ideas back to Ray (icons for latency variation vs packet loss), for him to ticket and assign. Not likely this week, as people are all allocated to the existing optimization tasks (and bringing the new PCC/test server online, etc).
how about you start by fixing the command that poses as "ping". it lies! I have intentionally disconnected from the internet just to see what ping does, and will go so far as to tell me that I am still connected to the game. /ping is not ping, and it is an outright deception to name it that, when it is not that. fix it, or rename it.
wikipedia: Ping (networking utility)
wikipedia: Ping (networking utility)
I don't think it lies, it's just not telling you what you expect. A rolling average over time will not show an immediate change.
Of course it isn't an ICMP ping utility. That wouldn't even work for a lot of people. But it does display network statistics from internal monitoring of the game packet latencies based on individual timestamps. Which is exactly what ping does.
But, I'm sure it could be improved, and the data could be made more immediate.
Of course it isn't an ICMP ping utility. That wouldn't even work for a lot of people. But it does display network statistics from internal monitoring of the game packet latencies based on individual timestamps. Which is exactly what ping does.
But, I'm sure it could be improved, and the data could be made more immediate.
If a utility does not tell me what I expect, and my expectations are reasonable based on a representation made by the utility (for example, the utility is named after a common well known utility, with a standard specification of performance), then the utility is lying.
Change the functionality of the utility to match expectations, or change the expectations of the utility to match it's functionality (rename the command).
Specifically, a rolling average over time should only account for samples taken after the command is issued, not any samples acquired before the command is issued. If I disconnect my internet, and then issue the ping command, it should consistently report that I do not have a connection. It is that simple.
Change the functionality of the utility to match expectations, or change the expectations of the utility to match it's functionality (rename the command).
Specifically, a rolling average over time should only account for samples taken after the command is issued, not any samples acquired before the command is issued. If I disconnect my internet, and then issue the ping command, it should consistently report that I do not have a connection. It is that simple.
@Roda: But is it really that big a deal compared to the stuff Inc and co are working on now?
When you are trying to fix a problem, diagnostics is a big deal. Finding out what exactly needs to be fixed is the first proper step of fixing a problem.
We do not want the devs spending their time trying to fix things that are ultimately outside of their influence. Like the quality of your internet provider, 12 people watching netflix at your house, or you running three antivirus scans while trying to play the game.
ping is a basic diagnostic tool. That is its primary purpose.
We do not want the devs spending their time trying to fix things that are ultimately outside of their influence. Like the quality of your internet provider, 12 people watching netflix at your house, or you running three antivirus scans while trying to play the game.
ping is a basic diagnostic tool. That is its primary purpose.
round-trip min/avg/max/stddev = 9.674/10.968/11.726/0.748 ms
That's from the wikipedia article you linked, Roda. Ping behaves the same way over a long rolling average. Our game is displaying a rolling average of your connection. It is not unlike starting a "ping" when you log in, and then checking on the current statistics by using the "/ping" command. It is so named because it shows the current protocol ping-time data. If you could check in on the statistics of an "on-going" ping, and then yank your connection, it would behave the same way.
I'm all for improving our diagnostics, and making things clearer to the end user. But spare me all this ignorant ranting about utilities "lying@!#@!", or at least maybe find a little less melodramatic way to state it.
You want more realtime data, that would be more useful to you, that's fine. Ask for that.
That's from the wikipedia article you linked, Roda. Ping behaves the same way over a long rolling average. Our game is displaying a rolling average of your connection. It is not unlike starting a "ping" when you log in, and then checking on the current statistics by using the "/ping" command. It is so named because it shows the current protocol ping-time data. If you could check in on the statistics of an "on-going" ping, and then yank your connection, it would behave the same way.
I'm all for improving our diagnostics, and making things clearer to the end user. But spare me all this ignorant ranting about utilities "lying@!#@!", or at least maybe find a little less melodramatic way to state it.
You want more realtime data, that would be more useful to you, that's fine. Ask for that.
less melodramatic:
The /ping command does not provide context for its correct interpretation, and does not represent expected context, and thus, the output is effectively erroneous.
Having a report of a rolling average over a period of time could be considered a desirable feature, if the report specified the context it should be interpreted in, and, where it not to the exclusion of more utilitarian data.
Your quotation of "round-trip min/avg/max/stddev = 9.674/10.968/11.726/0.748 ms" leaves out context, as the text you copy/pasted from does specifies the sample size, and by implication, that the sample set was generated after the execution of the command, and thus by extension, that the time taken producing the sample set could be determined by checking the time before and after issuing the command.
ping is a diagnostic tool. that is its stated and primary purpose.
to wit: A successful ping guarantees that the addressed interface and its associated machine are up...
The /ping command does not provide context for its correct interpretation, and does not represent expected context, and thus, the output is effectively erroneous.
Having a report of a rolling average over a period of time could be considered a desirable feature, if the report specified the context it should be interpreted in, and, where it not to the exclusion of more utilitarian data.
Your quotation of "round-trip min/avg/max/stddev = 9.674/10.968/11.726/0.748 ms" leaves out context, as the text you copy/pasted from does specifies the sample size, and by implication, that the sample set was generated after the execution of the command, and thus by extension, that the time taken producing the sample set could be determined by checking the time before and after issuing the command.
ping is a diagnostic tool. that is its stated and primary purpose.
to wit: A successful ping guarantees that the addressed interface and its associated machine are up...
Roda, You know you can just ping the game server with your OS' ping command and get that result.
Its other things like packets lost/retransmitted/received out-of-order that are harder to track down without the help of the game client's access to the network protocol.
Its other things like packets lost/retransmitted/received out-of-order that are harder to track down without the help of the game client's access to the network protocol.
Roda, you could just say "I would like real-time network connection and latency data", instead of trying to wrangle around and justify all the ways you think what we have is horribly wrong..
I guess I should be clearer: I DO NOT CARE WHAT YOU THINK OF THE EXISTING IMPLEMENTATION. It was not designed as the bestest diagnostic ever, it's a window onto the game-protocol's own timing implementation that's used to optimize motion interpolation and other game functionality (back when we implemented packet-timestamps and slew-synchronized phase-locked-loops on all clients and servers.. making the data user-visible was the furthest from our mind, it's just an operational part of the game).
It would have been much more productive to focus on how we might best improve it, rather than how unhappy you are that it deviates from your expectations.
Please spare me the RFCs from 1989, which has little bearing on the practical real-world usage, filtering, priority and manipulation of ICMP traffic and echo-responses.. even back when I was running an ISP in the 1990s.
If I were a real adherent to your request for a pure "ping" diagnostic tool, then that would mean an ICMP echo-request, which we will never, ever implement into the game, because that would be !#@$ing idiotic. You can always ping the bloody game server yourself, it responds to ICMP.
We could show much more realtime data within our network protocol, even connect it to a display graph like we do for framerate (/toggleframerategraph), and other features. But this "discussion" has absorbed enough of my time that I'm just going to lock this and move on to something more productive.
I guess I should be clearer: I DO NOT CARE WHAT YOU THINK OF THE EXISTING IMPLEMENTATION. It was not designed as the bestest diagnostic ever, it's a window onto the game-protocol's own timing implementation that's used to optimize motion interpolation and other game functionality (back when we implemented packet-timestamps and slew-synchronized phase-locked-loops on all clients and servers.. making the data user-visible was the furthest from our mind, it's just an operational part of the game).
It would have been much more productive to focus on how we might best improve it, rather than how unhappy you are that it deviates from your expectations.
Please spare me the RFCs from 1989, which has little bearing on the practical real-world usage, filtering, priority and manipulation of ICMP traffic and echo-responses.. even back when I was running an ISP in the 1990s.
If I were a real adherent to your request for a pure "ping" diagnostic tool, then that would mean an ICMP echo-request, which we will never, ever implement into the game, because that would be !#@$ing idiotic. You can always ping the bloody game server yourself, it responds to ICMP.
We could show much more realtime data within our network protocol, even connect it to a display graph like we do for framerate (/toggleframerategraph), and other features. But this "discussion" has absorbed enough of my time that I'm just going to lock this and move on to something more productive.