Network data changes

[kleenburn]

...they reduce their bandwidth charges at the expense of their customers?

[baelang]

Originally posted by kleenburn
...they reduce their bandwidth charges at the expense of their customers?

Everythign they do is at the expense of their customers, right?
i mean who else pays the bills?

you are going to pay (part of) their network bill (and every other bill) one way or the other.

[dirfrops]

Yes, you pay for their bandwidth, their booze and drugs, you even pay their taxes.

That's what business is all about.

The end consumer pays for the world to go round.

[kleenburn]

Yea, the issue seems to be why customers should pay for their bandwidth at the expense of game graphics quality...

[BlueAdept]

I noticed that the longer you seem to play EQ the worse the stuttering becomes. When I log in and am in PoK, it isnt that bad. I go to a few zones, play for a while, go back to PoK and get the stutter. I log totally out of EQ and go back in, it is back to normal until I play for a bit. I am getting the stutter in zones that NEVER had it before they started all this new crap.

It got so bad that I was having to turn down my clip plane down to like 20% so I wasnt getting the graphics lag.

[dirfrops]

Are you on broadband or dialup BlueAdept?

I dont have that problem at all...actually I have more stuttering/lag problems when i first log on, but after being on for 10 minutes I am fine.

[mudtoe]

Blueadept:

I have the exact same problem you do regarding the performance getting worse and worse the more zones you go through. I'm thinking it's a graphics thing rather than a bandwidth one. My guess is that somehow graphics objects from the zones are being kept in memory somehow, and the more zones you go through the worse the problem gets. Since the memory footprint of EQ doens't seem to get larger and larget as time goes by, it points to the video memory. BTW I have a broadband connection and have the datarate.txt set to 12.0.

I'm a mainframe assembler programmer ( TP monitor development) by trade and this behavior almost looks like what happens when you get a table with too many items in it, coupled with an inefficient search algorithm. It works OK until you get more than a certain number of rows, and then the performance goes down the tubes quick after that. I'm wondering if EQ is keeping so many graphics objects defined to the video card, and not getting rid of them when you zone, so that after a while if you are in a zone where there are lots of objects to display, the search through the now too large table of objects starts to degrade performance (I think the viceo card processor is what's getting saturated). It fits because the problem becomes noticable first in zones with lots of graphics objects to display at once (i.e. zones with lots of players in it, and especially if the lots of players are all close together so they have to be rendered at the same screen).

If you want to see the problem in operation go to nexus at the foot of the pyramid during early evening when there are a number of players there. Log out of the game and come back to "clear the cache". Now spin a 360 turn. You may notice a slight slowdown as your view passes by the platform where the players are standing. Note how long it takes. Now zone into Bazaar, PoK, PoD, and back to Nexus. Repeat the spin test. Notice how much worse the "hitch" is when your view passes the platform.

I've gotten in the habit of logging out of the game and coming back in after I've gotten to the zone we are going to fight in, just to clear the accumulated trash from all the zones I traveled through to get there. Most annoying.


mudtoe

[BlueAdept]

I have broadband. A geforce 4 4400 w/128 megs a p 1.5ghz w/ 1.5 gigs of memory running xp and I have my data rate set to 9.

My meter usually stays around 150 0.0% 0.0% 250 but I still get the stutter and the bazaar is almost unusable now. I have to turn my visability down to 5% to be able to do anything in the zone. Otherwise it takes like a minute for anything I do to actually happen, like mouse movement.

They really messed things up for me. It was perfect before these stupid patches.

[Spook]

Those "hitches" I call graphics caching. If you are of the mind, you can break out a profiler and monitor traffic on the buss or even what is being called when in the system (everything slows down with this sort of monitoring btw)I generally spin once on zone entry to cache the graphics and things run fine for me with only minimal hiccoughs when new characters enter the zone or I see a new spawn with much different graphics than the rest. As of the so-called network optimization patch it seems as if something is happening with that way graphics are loading - even perhaps causing the zone to be reloaded instead of just updated. This is making things turn jerky at times for me. Off in a remote zone where other players don't zone very much - even though there may be a lot of them things run smoother than before. So, I'm of the mind now that some sort of trigger may be happeneing with the new network compression causing graphics to load more so at certain times /shrug

A note about watching the CPU load graph you can get from ctrl-alt-del Task Manager-Performance; it is deceptive. I can write a real short program that runs in a tight loop but with a call to do system events inside it. The perfmon will show 100% CPU usage which is just showing inverse idle time. The system runs just fine like that. So, some programs may be using that sort of threading or looping instead of putting that application to sleep for a while which will show the large but deceptive CPU usage.

[throx]

We're not going to start with the fiction that the decompression/decryption of a 2k/sec byte stream is taking any significant portion of CPU time again are we?

Test it out sometime with gzip. My P3/900 can decompress around 2,000k/sec (decompressing to /dev/nul) and that's limited by HDD speed more than CPU time. That means on a 2k/sec stream you're using at most 1% of CPU, more like 0.1% CPU on the 250 bytes/sec that most people are getting now on non-raid situations. Those numbers are on a P3/900 so scale them down appropriately for faster CPUs.

I do agree that EQ's graphics engine is pretty inefficient and is far, far more CPU dependant than Vid Card dependant. A P4/1500 will definitely struggle with new models and lots of people in a zone. Remember, if facing a wall improves things then it's the rendering engine that's at fault and not the network layer.

[Ratt]

We're not going to start with the fiction that the decompression/decryption of a 2k/sec byte stream is taking any significant portion of CPU time again are we?

Test it out sometime with gzip. My P3/900 can decompress around 2,000k/sec (decompressing to /dev/nul) and that's limited by HDD speed more than CPU time. That means on a 2k/sec stream you're using at most 1% of CPU, more like 0.1% CPU on the 250 bytes/sec that most people are getting now on non-raid situations. Those numbers are on a P3/900 so scale them down appropriately for faster CPUs.

The real issue here is the compression/encryption, not the decompression/encryption.

The additional load on the servers must be awesome, to have to compress/encrypt the data for 2000 users at a time.

Obviously, there's only 2 or 3 zones per computer, some more, some less... but still, on a large, large scale raid, that's gotta suck up major resources on the given box with 500 people in the zone.

[Resiliant]

Unless hardware assisted.

[EnvyEyes]

Off topic....
Love the quote, Ratt. That has to be one of my all-time favorite movie lines. Brian Cox was awesome in that role.... not surprising that he played a 'mirror role' in the newest flic to copy "The Long Kiss Goodnight"'s theme (The Recruit- CIA spy/assassin and deep corruption of the powers that be).

Sorry for straying off topic, but I couldn't resist commenting when I read that.

[throx]

The real issue here is the compression/encryption, not the decompression/encryption.

I agree, though I haven't noticed significant problems on raids with the code. In fact, everyone seems to be raving about how wonderful it is now that /serverfilter works properly and is automatic (*sigh*).

This could certainly be an issue in the bazaar though and causing the time delay noticed for the server to respond.

I wouldn't imagine the encryption takes up any more CPU time than decryption but compression is certainly more time consuming than decompression. I wonder if they've just done another round of server upgrades and I wonder how much CPU time the halved data rate has saved in comparison to the CPU time required for zlib compression?

[Raistlin]

Very interesting discussion...

I've been out of town for a few weeks on and off. On my main machine I've not noticed any real problems to speak of (PoK and Nexus now lag on me a bit when they didn't use to).

HOWEVER since i've been out of town i've been on my PIII 800 laptop with 3xx meg of PC133 memory and a dial in connection.

And all of a sudden this thing is almost completely unplayable. I have all graphics and models off, I have clip plane set to 0, I'm running in 800x600 mode for gods sakes...and i'm still lagging like i'm running on a 386.

I was just going (after last night) to attribute it to heat (the longer I played the slower it got...and the hotter my laptop gets as the fan is a bit flakey and tends to cut out) but it's sounding like this might not be the case. I THOUGHT I noticed that alt-entering did in fact help speed things up for a short while and if in fact there are too many objects stored in the graphics memory, then possibly this could be a partial fix since switching modes like that MIGHT cause some or all of those stored graphics to have to be cleared out of the cache.

Anyone found any way to either stop this or "reset" this?