| Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Solbright
   |
Posted - 2007.01.15 05:36:00 -
[1]
Yep, the network is already decoupled. The problem is more upfront in the client with the 2D renderer in particular and, I suspect, excessive object thrashing in general.
Lag is not the problem here. Major client stutter only kicks you in the face after the network packets have arrived and it needs to be displayed, at which point the above slow code single mindedly hogs the CPU to produce the updated display.
One change in this area with the Revalations patch that I noticed - CCP changed the overview's method of updating the item distances so that they are redrawn only one at a time instead of all at once. Nice improvement imho.
|
Solbright
|
Posted - 2007.01.24 20:57:00 -
[2]
Ya, that's exactly what is being said. Also, this has been one of Eve's enduring features.
As for proof, I guess not, but the 6 second part of your write-up I'd put down to lag so that only leaves stutter for the remaining 4 seconds. And it should be possible to show the network activity for that market/wallet update had completed at the end of the 6 seconds.
|
Solbright
|
Posted - 2007.03.30 09:09:00 -
[3]
I just run the market test again and result has changed for the better. :) Not sure which patch made the improvement but I can regularly bring up, say, the Spaceship Command skills for browsing and they now almost have no stutter at all. Compared to earlier tests, that had a massive seconds long stutter, this is a nice improvement.
I guess CCP are doing some tweaking but it's got a long way to go still to fix things like fleet engagements.
|
Solbright
|
Posted - 2007.03.30 22:33:00 -
[4]
Come on guys, think about was is happening. Take the market example: The servers will still take the same 6 seconds to respond. Just the client no longer has the extra 4 second stutter. Also, it's silly to think the client would be "busy-waiting".
As for achieving decoupling, you certainly don't need multi-threading for that.
|
Solbright
|
Posted - 2007.03.30 22:37:00 -
[5]
Ugh! Also, predictive coding is a done thing in Eve. Why do you think you get repeating warp-ins, damage happening before the missile hits, jumping drones and the likes.
|
Solbright
|
Posted - 2007.03.31 02:34:00 -
[6]
Lag is not the cause of stutter. Decoupling is pretty simple really and prolly easier to do in a single thread than trying to use IPC functions.
|
Solbright
|
Posted - 2007.03.31 03:15:00 -
[7]
Yeah, right! Like IPC is trouble free. Why do you think multi-threading hasn't been the norm since multi-tasking OSes have been all the rage on the desktop for a couple of decades atleast.
|
Solbright
|
Posted - 2007.03.31 10:04:00 -
[8]
Getting back on track. I'd just like to say, from observation ie: the now smooth market test, that stutter is not when the client is waiting for server response. At best, stutter is a result of too much data arriving from the server. The client has so much processing to get through before getting back to the display loop that you see a frozen display.
Actually, it's not really a case of the quantity of data either, it's more about the client's slow execution with this new data. Aka, bloatware rearing it's ugly head, or sloppy coding or whatever other evil sounding name is fitting.
|
Solbright
|
Posted - 2007.03.31 22:24:00 -
[9]
 Originally by: Oblom
Too much data or not - it doesn't matter. Updates of the screen with available information should never stop. Like own ship, static surroundings and things like blinking stars  . Arriving data can be buffered and processed as time allows. There will be delay with displaying some objects, but no freezes. Then you optimize the code and see what can be done to make things faster.
Good stuff. Couldn't have said it better. :)
Quote:
But I still think that in most cases it caused by server side delays with client just sitting frozen doing nothing while waiting for server to respond.
http://oldforums.eveonline.com/?a=topic&threadID=497236
- Check the posting by Nonym Ous in particular, you get a good descripton of someone dealing with lag but no stutter. I bet, however, if he'd had the full force of the battle, ie: very little lag, he'd not only have had a dose of stutter to deal with he also would have been podded because of the stutter.
Quote:
But again, it doesn't reallly matter. We are not going to fix it. We only can make a little bit of noise on the forums about it. Question really is will CCP ever attempt to fix it?
Well, isn't that a good enough reason? To make some noise so CCP takes action?
|
Solbright
|
Posted - 2007.04.01 05:05:00 -
[10]
There's the rub, noone has been complaining about stutter. So how can CCP react if all is well? Everyone complains about the cluster lagging problem, and are completely silent on the client stutter problem except to tell the few little bleeps to shutup and buy a faster PC.
|
Solbright
|
Posted - 2007.04.08 06:15:00 -
[11]
After some more arguing about what is lag what is stutter in yet another thread. Be warned, there is multiple links back to this thread in there. 
As mentioned in there I've realised that the same stutter fix that was done for the market rendering can be applied pretty much verbatim to combat also. It's not a complete fix but it's a good start and it's an obvious incremental improvement that I'd expect CCP are already at work on.
|
Solbright
|
Posted - 2007.04.10 21:21:00 -
[12]
Originally by: Xianthar
2 weeks post patch: everyone *****es about why the ship that their client thought was 15km away should have been scrammed when the server thought the ship was actually 80km away.
This thread is about the client stuttering. You appear to be talking about lag effects.
|
Solbright
|
Posted - 2007.04.11 10:03:00 -
[13]
Edited by: Solbright on 11/04/2007 10:01:48
Originally by: Princesse Qiao
... but that the client once it has its own distances fixed seems to reject server updates to the contrary
Prolly not any new updates coming from the server. The server only sends updates for changes to the world simulation. If the model of the object motion is not changing then there is no further updates needed.
The client runs it's own world simulation that should closely match what is on the server. Sometimes this will get out of synchronisation for one or more objects and only getting straighten out when there is an update for that object.
A common reason for loss-of-sync is packet loss over the internet.
|
Solbright
|
Posted - 2007.04.11 10:28:00 -
[14]
Edited by: Solbright on 11/04/2007 10:33:58
I'm doing a lot of guessing of course, and the reality will be more complex that my summary.
One example of a bulk update that can straighten out much loss-of-sync is where the Overview is closed and reopened. When this is done the client requests a full refresh of the Overview info which the server will respond to.
Edit: Suck, nope, not true. Assumed too much there. Dunno why it has such a big stutter then if there is no new info for it.
|
Solbright
|
Posted - 2007.04.12 08:33:00 -
[15]
Guess that also makes the Overview refresh trick a debugging hack that has been left in for everyone to enjoy. Could do with some more of those for helping keep the game on it's feet.
|
Solbright
|
Posted - 2007.04.15 22:19:00 -
[16]
Originally by: Sal Alo
Originally by: Oblom
... cause the whole thing become dead. This is design error, admit it.
/signed 101%
Except, imho, that won't be the design. It will be decoupled, ie: lag can't cause a stutter. The client code is simply too slow is all. It doesn't even need any server input and it still struggles big time. The client isn't handling the job of simulating and rendering, period.
It's still in beta, needing a major optimisation before releasing on the paying customer.
|
Solbright
|
Posted - 2007.04.21 08:50:00 -
[17]
For the record: Stutter and lag are two quite different beasts
because of Decoupling via the local simulator
which means Blocking against the server won't happen
|
Solbright
|
Posted - 2007.04.26 00:12:00 -
[18]
As for what is the cause of stutter and poor framerate in general. I now have two reasons that fit observation rather well:
- Boring old bloat. This has been my favorite but a recent hint suggests it might not be the main cause. That's not to say bloat isn't a problem! I'm not going to let it slide that easy. :)
- Flawed caching of geometry and texture data. This has been listed before but I've generally ignored it as too obvious and solved already. The recent hint made me think CCP intend to decouple the fetching so the data won't be needed to complete a rendering pass. The data will be used as it becomes available from the HDD. This method has the nice bonus of not needing to restrict the total number of models to a certain memory footprint.
I am still concerned that decoupling the texture fetching like this, while it's bound to have a big impact on stutter, it won't help general framerate at all. I guess that's where the other optimisations and redesigns come in.
Have to wait another year to find out ...
|
Solbright
|
Posted - 2007.04.26 22:30:00 -
[19]
The above flawed caching hint comes from this little present in the form of "better asynchronous resource loading". And, here's the follow up thread.
We finally have the long overdue acknowledgement of the client based issues covering both low fps and stutter. :)
|
Solbright
Advanced Security And Asset Protection
|
Posted - 2007.07.14 11:06:00 -
[20]
Edited by: Solbright on 14/07/2007 11:10:37
Originally by: Frug
I think it's fairly obvious that nothing's decoupled and that the market lag is due to the whole client waiting for an update.
There is no one cause. Lag exists. And stutter exists.
The client is decoupled completely. Which is why you get rendering while waiting for the response to a market listing. And you can click on other stuff during that time.
But when the market data arrives is when the client freezes for a short period while it handles the influx. This is the part that I call "stutter".
Stutter is fixable in a permanent sense. This is why I'm a stickler for having separate names for lag and stutter.
|
Solbright
Advanced Security And Asset Protection
|
Posted - 2007.09.11 00:21:00 -
[21]
Edited by: Solbright on 11/09/2007 00:23:07
Oveur's new blog on Rev 3 and Trinity 2 doesn't indicate any attempt to solve stutter. Feeling a little depressed ... well, there is not much actually said beyond new features so I guess I shouldn't view that as nothing changed.
------
Vote for Low graphics client |
| |
|