open All Channels
seplocked EVE Information Portal
blankseplocked New Dev Blog: The not-so-great-after-all deep safe nerf of 2010
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: first : previous : ... 3 4 5 6 [7] 8 9 10 11 : last (11)

Author Topic

Camios
Minmatar
Sebiestor Tribe
Posted - 2010.04.18 21:16:00 - [181]
 

Originally by: Jattzia
The blog completely ignores that DEEP SAFE SPOTS ARE THE ONLY CURRENT WORKAROUND TO LAG.

Are the DEVs too ignorant understand this? Maybe, but some reply to the lag workaround issue raised about 500 times in the last thread would have been nice.

I imagine that what's really going on is that you're *hoping* Tyrannis will magically cure lag, but aren't sure so have a lips-sealed policy at this point.

...

I think you're underestimating how many people are sick of not getting good fights in 0.0, and what affect that is going to have on their subscriptions if it isn't robustly addressed in Tyrannis.

Kuseka Adama
Gallente
Northstar Cabal
Posted - 2010.04.19 02:08:00 - [182]
 

Kerfira

I would be foolish to assume that the major alliances do not have that type of list. You do not go to war without a battleplan. Even if its a simple priority list of targets.

Game mechanics will never be changed to not benefit blobbing or so everyone seems to believe. I pray that happens at some point.

Vaerah Vahrokka:HAHAHAHAHAHAHA This coming from the same faction that got the greatest source of dev help in the history of MMOS!

Lets not pull any punches here. IT is the Reformed BoB the same BoB that got help from CCP employees in ways most cant begin to imagine. I'm not going to sit here and rehash the past with you but i will say you do bring up a somewhat valid point.

My problem is this. Everyone expects a game with the following technical info happening on a second by second basis to be streamed to their computers at the same time.

Assuming the largest viable fleet battle i've ever heard of 500 on 500. If every ship is mounting 1 weapon. That accounts to 1 million calculations.

How do i arrive at this number? 1000 weapons being fired being transmitted 1000 times. You heard me. Transmitted ONE THOUSAND TIMES! Wether you see it or not that data MUST be transmitted to each computer in the battle. Now lets make it a bit worse. Battleships only, a big mother of a battle. 6-8 weapons per ship in most cases. Dragging that number to 6-8 million transmissions of data every few seconds possibly even shorter.

Now we are unfortunately not talking about 2+2 kinds of numbers. We're talking calculus level equations to figure out damage. Lasers being the easiest. Missiles being about the middle and Projectile/hybrid as the hardest of all. these calculations are difficult enough under simple circumstances. Throw in reppers of various kinds, resistance modifiers, rigs, transversal velocities, traveling speeds and such your talking about an equation that is very difficult to solve on paper.

That is 6-8 million equations transmitted from a single node to all over the world at a rate of 1-10 seconds depending on the firing rate of the weapon your dealing with which is the biggest variable. I haven even gotten into UI/graphics yet. Which brings up its own set of problems in loading. Finding a spot for each ship to jump in effectively on a single mass jump is a strain on the server. Now then back to my original point: Can a solid computer do these calculations. Sure can a server? Most definitely. But the problem comes in no small part from TRANSMISSION of said data. And here is where people are screaming.

These transmissions come in the form of packets to us. These packets vary in size and in some cases have to go a pretty damned long distance of fiber-optic cable. But in these packets you must include, graphics data (all the ships moving around because no one just sits still) Chat Data, (more data that adds strain to the server don't believe me? Check out Chribba's latest thing about jita) POS Data if its a POS strike The aforementioned numbers don't involve drones so throw that in as extra ship data. All that data is coming from one source. It was easier before this latest patch in part because of the optional graphics. Now everyone's running the super graphics which only increases the data being transmitted. And now this is just the stuff being transmitted to the player. Lets not forget what the player is transmitting back and what other things he might be doing with his connection. Eve voice adds another layer or another voice comm setup. In some cases more than one to boot. Not to mention all the other processes a player has going across the net at any given time.

The problem can not be fixed just by raw horsepower. It must be fixed at the tactical level. Blobbing is the single greatest problem this game has and has had for quite some time. The removal of the standard DD's have made it even more profitable to blob. Fixing this situation is not going to be easy. and its going to upset people in its method.

QUicKie NicKy
North Eastern Swat
Pandemic Legion
Posted - 2010.04.19 02:30:00 - [183]
 

On the off chance that the Devs can't see red or something...

The blog completely ignores that DEEP SAFE SPOTS ARE THE ONLY CURRENT WORKAROUND TO LAG.

EVE since Dominion has transformed into a huge checker board so far as numbers above 50-100 are concerned. You can only move to a square(grid) that is open and if someone else manages to fill up the squares that you could move to conventionally, either you jumped to a deep safe or you were pretty much frelled. With the deep safe nerf, you're just plain old frelled.

Caladain Barton
Navy of Xoc
The Remnant Legion
Posted - 2010.04.19 02:42:00 - [184]
 

Originally by: Kuseka Adama



Yet, surprisingly, this is not a large number.

You see, they are not using TCP/IP to transmit the data. Updates and information flow from the client, to the server (who, with a modern server, very easily crunch these numbers coming in, do all the calculations in real time, and format the outgoing messages), who then broadcasts out the updates (without doing checking on the packets..thus rubberbanding and various lag illnesses, but full TCP/IP handshake and data verification would kill the connections.

More than likely they are using a form of (or just plain) UDP. No bit checking on transmission, no handshakes, or CRC.

Also ignored is the fact that 500v500 battles *were working*. No joke, honest. Patch comes out, 200v200 doesn't work. *blinkblink* Since things were working, and now they aren't, we can safely point the finger at something that was changed causes the issue.

*IF* CCP is sending these updates out in this style: Person A shoots gun2 at Person B. (next message) Person A shoots gun3 at PersonB. Then *maybe* they might run into a transmission bottleneck. More than likely they are sending update "packets" that contain more than one update per packet..at say, oh, i don't know, a couple ten thousand per minute, or 400hz or so. Even with 1000v1000 this shouldn't be a problem in the slightest. In this case, i sincerely doubt it's the server hardware, and the blame is more than likely square on the software's shoulders, and, if i was a betting man, on the buffer subsystem in the incoming message handling subsystem. I'm betting it's getting starved for resources or mutex's..and dropping things on the floor.

Kuseka Adama
Gallente
Northstar Cabal
Posted - 2010.04.19 02:55:00 - [185]
 

Originally by: Caladain Barton
Originally by: Kuseka Adama



Yet, surprisingly, this is not a large number.

You see, they are not using TCP/IP to transmit the data. Updates and information flow from the client, to the server (who, with a modern server, very easily crunch these numbers coming in, do all the calculations in real time, and format the outgoing messages), who then broadcasts out the updates (without doing checking on the packets..thus rubberbanding and various lag illnesses, but full TCP/IP handshake and data verification would kill the connections.

More than likely they are using a form of (or just plain) UDP. No bit checking on transmission, no handshakes, or CRC.

Also ignored is the fact that 500v500 battles *were working*. No joke, honest. Patch comes out, 200v200 doesn't work. *blinkblink* Since things were working, and now they aren't, we can safely point the finger at something that was changed causes the issue.

*IF* CCP is sending these updates out in this style: Person A shoots gun2 at Person B. (next message) Person A shoots gun3 at PersonB. Then *maybe* they might run into a transmission bottleneck. More than likely they are sending update "packets" that contain more than one update per packet..at say, oh, i don't know, a couple ten thousand per minute, or 400hz or so. Even with 1000v1000 this shouldn't be a problem in the slightest. In this case, i sincerely doubt it's the server hardware, and the blame is more than likely square on the software's shoulders, and, if i was a betting man, on the buffer subsystem in the incoming message handling subsystem. I'm betting it's getting starved for resources or mutex's..and dropping things on the floor.



You could well be right, but i want people to understand the full scope of the issue. I personally think its a graphics problem more than anything else. And i don't mean that its happening client side. The effects are obviously NOT client. I think the strain of the enhanced graphics forced on the server since the last expansion is a HUGE cause in what is happening. There is imo no one source of lag in this issue. I still maintain that blobbing is a huge problem in this game and the fact you cant dogfight in large fleet fights is a disaster as far as i am concerned.

Hack Harrison
Caldari
Posted - 2010.04.19 03:20:00 - [186]
 

Originally by: Kuseka Adama
Originally by: Caladain Barton
Originally by: Kuseka Adama



Yet, surprisingly, this is not a large number.

You see, they are not using TCP/IP to transmit the data. Updates and information flow from the client, to the server (who, with a modern server, very easily crunch these numbers coming in, do all the calculations in real time, and format the outgoing messages), who then broadcasts out the updates (without doing checking on the packets..thus rubberbanding and various lag illnesses, but full TCP/IP handshake and data verification would kill the connections.

More than likely they are using a form of (or just plain) UDP. No bit checking on transmission, no handshakes, or CRC.

Also ignored is the fact that 500v500 battles *were working*. No joke, honest. Patch comes out, 200v200 doesn't work. *blinkblink* Since things were working, and now they aren't, we can safely point the finger at something that was changed causes the issue.

*IF* CCP is sending these updates out in this style: Person A shoots gun2 at Person B. (next message) Person A shoots gun3 at PersonB. Then *maybe* they might run into a transmission bottleneck. More than likely they are sending update "packets" that contain more than one update per packet..at say, oh, i don't know, a couple ten thousand per minute, or 400hz or so. Even with 1000v1000 this shouldn't be a problem in the slightest. In this case, i sincerely doubt it's the server hardware, and the blame is more than likely square on the software's shoulders, and, if i was a betting man, on the buffer subsystem in the incoming message handling subsystem. I'm betting it's getting starved for resources or mutex's..and dropping things on the floor.



You could well be right, but i want people to understand the full scope of the issue. I personally think its a graphics problem more than anything else. And i don't mean that its happening client side. The effects are obviously NOT client. I think the strain of the enhanced graphics forced on the server since the last expansion is a HUGE cause in what is happening. There is imo no one source of lag in this issue. I still maintain that blobbing is a huge problem in this game and the fact you cant dogfight in large fleet fights is a disaster as far as i am concerned.


I must be dumb - WHAT has graphics got to do with server lag? Server tells client to shoot missile or laser blast. The graphic settings on the client determine WHAT you see (good/crap graphics). As long as the client is communicating with the server, lag won't come from "enhanced graphics forced on the server since the last expansion" as that is not something the server handles. Lag WILL come from the server failing to process messages in time... Also the data will be grouped into packets so less messages are sent over the wire.

BTW - your million messages would be on a P2P model X x X messages sent. This is server based. So for X ships there are 2X messages surely - X to the server. Messages are then processed. Server sends replies to X clients.
What is your computer science/programming background to justify your arguement?

Kanatta Jing
Posted - 2010.04.19 03:24:00 - [187]
 

Dude, It's Fleet Finder. Try doing 500 vs 500 without being in fleet.

Kuseka Adama
Gallente
Northstar Cabal
Posted - 2010.04.19 03:43:00 - [188]
 

Originally by: Hack Harrison

I must be dumb - WHAT has graphics got to do with server lag? Server tells client to shoot missile or laser blast. The graphic settings on the client determine WHAT you see (good/crap graphics). As long as the client is communicating with the server, lag won't come from "enhanced graphics forced on the server since the last expansion" as that is not something the server handles. Lag WILL come from the server failing to process messages in time... Also the data will be grouped into packets so less messages are sent over the wire.

BTW - your million messages would be on a P2P model X x X messages sent. This is server based. So for X ships there are 2X messages surely - X to the server. Messages are then processed. Server sends replies to X clients.
What is your computer science/programming background to justify your arguement?


Question 1: Server has to transmit enhanced graphics to the player. There is other reasonable explanation on some of what's being experienced. Because I've had similar issues in other games Anarchy Online being the most prevalent in my mind on this particular issue. Your computer has to process the extra graphics and because of an MMO's permanent spherical view that means it transmits everything. A grid loading those kind of graphics. Most gamers at this point are at least running 250's or their equivalents/better but even with an 8800 GT you'd still have no performance issues with this game. Otherwise there is something else completely at play here bordering on the Boot.ini error and given the time its taken to figure out i cant believe its anything that nuts. Heck i could be wrong but what the player sees has to be transmitted too doesn't it?

As for the background? I don't have much honestly. But to go with what you insinuate is that every thing is 'rolled' IE predetermined or 'grouped' and not allowing for independent damage. And combat logs specifically show that just isn't the case. Because its independent messaging i have to believe that everything is independent. If i'm wrong someone show me where CCP announced that kind of change because that ain't minor in the grand scheme of things. Regardless i just take what i see analyze it and make a few guesses.

Caladain Barton
Navy of Xoc
The Remnant Legion
Posted - 2010.04.19 05:12:00 - [189]
 

Edited by: Caladain Barton on 19/04/2010 05:26:18
Originally by: Kuseka Adama

Question 1: Server has to transmit enhanced graphics to the player. There is other reasonable explanation on some of what's being experienced. Because I've had similar issues in other games Anarchy Online being the most prevalent in my mind on this particular issue. Your computer has to process the extra graphics and because of an MMO's permanent spherical view that means it transmits everything. A grid loading those kind of graphics. Most gamers at this point are at least running 250's or their equivalents/better but even with an 8800 GT you'd still have no performance issues with this game.


Okay, two seperate things here. Classic Client Server model. The Server does not render anything graphics related. It sends in a packet a series of commands (messages) to the client letting it know what's happening (plain text). The client takes these commands (plain text descriptions in essence) and then interprets what to display on the screen. A classic form of this would be a laser beam, or the client getting conflicting messages on "where" your ship is due to lag..the rubber banding effect (where the client shows you arriving, then you reverse course and repeat the last thing you "saw" twice or three times before finally staying on grid.)

This is why when the new graphic's engine came out (and everything got pretty) we *had* to download a new client. Don't take my word for it..google or MIT's lectures should say the same thing about good design. On the Client Side (your computer), you can experience lag rendering these instructions. Thus, in major battles, if you've got all the bells and whistles turned on, you get three frames of pictures a second. This is why in all major engagments, we tell everyone to turn off every graphical "pretty" option we can, and to turn off brackets. Everything that has to be rendered by the client, thus allowing it to "ignore" some of it's duties and preform better.

Me? I've got a monster machine and play 30 frames a second rendering in massive battles with brackets. It's very pretty when there is no lag. (i still turn off a bunch of things normally as i don't like to test my luck, but the couple times i have...WOW)

Originally by: Kuseka Adama
Otherwise there is something else completely at play here bordering on the Boot.ini error and given the time its taken to figure out i cant believe its anything that nuts. Heck i could be wrong but what the player sees has to be transmitted too doesn't it?


Nope, you're completely wrong. The only thing sent from your client to the server is when you give new commands to your ship and some UI elements when they've been clicked (offline a tower, drag a module, etc). Pretty explosions, etc, the server doesn't care about. The client only transmits messages when you target someone (start targeting), shoot someone, etc. The client doesn't even know how much capacitor you have. That's why the "fleet fits" are so cap-unstable..in major lag the server prioritizes what info gets transmitted, and 9/10, the cap info gets dropped. Thus, you get to fight without draining your cap. You also have trouble exiting siege for a similar reason..most embarrassing to be stuck on grid for 9 cycles not consuming fuel (but shooting at sieged damage levels.

Originally by: Kuseka Adama
As for the background? I don't have much honestly. But to go with what you insinuate is that every thing is 'rolled' IE predetermined or 'grouped' and not allowing for independent damage. And combat logs specifically show that just isn't the case. Because its independent messaging i have to believe that everything is independent. If i'm wrong someone show me where CCP announced that kind of change because that ain't minor in the grand scheme of things. Regardless i just take what i see analyze it and make a few guesses.

Just because the messages are grouped together doesn't mean they don't have individual statements.

<Continued>

Caladain Barton
Navy of Xoc
The Remnant Legion
Posted - 2010.04.19 05:17:00 - [190]
 

Edited by: Caladain Barton on 19/04/2010 05:32:37

Originally by: Kuseka Adama

As for the background? I don't have much honestly. But to go with what you insinuate is that every thing is 'rolled' IE predetermined or 'grouped' and not allowing for independent damage. And combat logs specifically show that just isn't the case. Because its independent messaging i have to believe that everything is independent. If i'm wrong someone show me where CCP announced that kind of change because that ain't minor in the grand scheme of things. Regardless i just take what i see analyze it and make a few guesses.


<Continued>
Lets look at it with a crappy example (i really suck at examples). You're sending a letter to your friend.

You could send each sentence as a seperate sealed, mailed letter. The same information would get there, yeah, but it would flood the connection (Postal Service) for no reason. Now imagine everyone doing it. The Postal service would have millions of messages and die horribly.

Okay, bad example slighty as computers can do that. But if Eve was sending each action as an individual "letter", then it *would* be a bad architecture design.

Instead, you put all the sentences into a letter (containing multiple statements) and shove it out the door.

In a good design, the server would stack up a pre-determined number of messages (say, 50 or 75) and mail them out to everyone at once. The sever doesn't check to see if they have arrived, it just shoves them out the door because it's busy.

In a bad design, it would send out 50 or 75 messages.

Now, these messages get sent out regardless if anything is happening. Thus, in 1v1 battles..yeah, it might be a single action per message. But in mass engagements, each message is stuffed full before being shoved out the door. make some sense?

Something changed server side. My guess..some developer tapped into something relating to messages..added a new one, pinging the queue of messages..something that had a side effect. Maybe he changed the rate at which a message is sent (message being a single client instruction from the server in this case) and borked something. I can't believe it's taken more than 4 months to find it..which means it's something they can't pin down. Which means, a) the guy who wrote it left and was smarter than the other devs/wrote something horribly bad. or b) They have no idea and are blaming vendors/hardware/something else. Stuff was working, software changed, stuff broke. 99.999999% of the time, your software change or "patch" broke it. You have to be twice as clever to debug something as when you wrote it.

*IF* ccp has their source under source control (Please, by all that is holy and good in the world, you DO right ccp?) narrowing down *what* got changed should be as easy as running a diff against the old version. Feed it into a debugger (or run echo/cout/ada.text_io/whatever if you can't for some reason) and see *where* it dies. Then see if thats actually where it dies, or if it just seems to die there. Then see what makes it die (poke, prod, feed it bad data, etc), fix it, and *prove* it's been fixed.

Caladain Barton
Navy of Xoc
The Remnant Legion
Posted - 2010.04.19 05:42:00 - [191]
 

Originally by: Kuseka Adama

You could well be right, but i want people to understand the full scope of the issue. I personally think its a graphics problem more than anything else. And i don't mean that its happening client side. The effects are obviously NOT client. I think the strain of the enhanced graphics forced on the server since the last expansion is a HUGE cause in what is happening. There is imo no one source of lag in this issue. I still maintain that blobbing is a huge problem in this game and the fact you cant dogfight in large fleet fights is a disaster as far as i am concerned.


Lag is a catch-all term. Like Cancer.

There are many types of Lag. We all know and love Graphical lag (rubber banding, detonations on your ship when you're not being fired at, Gal large towers spazzin out). This is client side. Everything related to graphical glitches or rendering rate (which depends on how powerful your machine is) is client side. *IF* your client is maxing out your computer..it *might* be hard to send out a client->server message..say..you try and shoot someone. This only effects you though.

Then there is server lag. The server is late sending out a message, or sends out duplicates (or you recieve duplicates via the wonderful thing called UDP and the interwebs) causing rubber banding on your client. Nasty things happen in server lag land...this is real lag. Messages don't get sent out (due to bad coding) but the server things they have been, messages arrive garbled (UDP does that sometimes), etc. The sever may be *able* to crunch all these things and do the right thing, but that relies upon the correct logic to have been programmed into it.

Some dev changed something and broke part of that logic. Now fleets don't get "registered" inside the server software when they attempt to "join" a grid..like they used to be able to. The server hiccups, and probably thinks it sent the "okay, you all loaded grid, here's what you see" message. It doesn't hear anything back from the client for X amount of time (client is sitting there) and then drops the client (while still keeping the ship and stuff on grid..nifty bug eh?). It then merrily processes the damage done to the ships, and kills them rightly so.

Zenst
Hall Of Flame
Chain of Chaos
Posted - 2010.04.19 06:01:00 - [192]
 

Originally by: QUicKie NicKy
On the off chance that the Devs can't see red or something...

The blog completely ignores that DEEP SAFE SPOTS ARE THE ONLY CURRENT WORKAROUND TO LAG.

EVE since Dominion has transformed into a huge checker board so far as numbers above 50-100 are concerned. You can only move to a square(grid) that is open and if someone else manages to fill up the squares that you could move to conventionally, either you jumped to a deep safe or you were pretty much frelled. With the deep safe nerf, you're just plain old frelled.


As you say The blog completely ignores that DEEP SAFE SPOTS ARE THE ONLY CURRENT WORKAROUND TO LAG.



Oh deep safespots you serve us so well,
At times of lag when servers go towards hell.

I call it a mechanic you call it a bug,
The forums a panic from dominions drink jug.

So look at the problem and not at the cure,
You idea is iratic and offtrack I'll assure.





The deep-safe patch prayer:

Your idea, which farts in space,
flawed be thy name;
thy deepsafe gone;
thy will be done;
in lag as it is in space.
Give us this day our daily sanity,
as we forgive them that patch against us.
And lead us not into lag;
But deliver us from lag.
For thine is the system,
the stability, and the soverenty,
for ever and never.

Aye CCP

chadwill
Gallente
Goldtooth of stellar enterprices
Posted - 2010.04.19 06:58:00 - [193]
 

Originally by: Zenst




Oh deep safespots you serve us so well,
At times of lag when servers go towards hell.

I call it a mechanic you call it a bug,
The forums a panic from dominions drink jug.

So look at the problem and not at the cure,
You idea is iratic and offtrack I'll assure.





The deep-safe patch prayer:

Your idea, which farts in space,
flawed be thy name;
thy deepsafe gone;
thy will be done;
in lag as it is in space.
Give us this day our daily sanity,
as we forgive them that patch against us.
And lead us not into lag;
But deliver us from lag.
For thine is the system,
the stability, and the soverenty,
for ever and never.

Aye CCP


+1 internets for you my good sir

clap clap

Julius Rigel
Sub-warp Racing Venture
Posted - 2010.04.19 07:17:00 - [194]
 

Edited by: Julius Rigel on 19/04/2010 07:25:05
Ahem...

2 300 items? Not 230 000? Not 23 000?

I don't get what the big issue is?

I think it's time for one of those signatures pointing out fairly stupid decisions brought on by who knows what horrible combination of players whining and dining at CCP HQ and on the forum.

Please visit your user settings to re-enable images.

AeonOfTime
Minmatar
Syrkos Technologies
Joint Venture Conglomerate
Posted - 2010.04.19 07:29:00 - [195]
 

Awwwww, and what about the cans in the EVE Gate system then? Will there be one big heap of cans at the 20AU limit then after the move? Laughing

Vaerah Vahrokha
Minmatar
Vahrokh Consulting
Posted - 2010.04.19 07:34:00 - [196]
 

Quote:

So, what happens if I create an off-plane deep safe that falls within the new limit, but is still a very long way from the nearest celestial? In some larger systems, that would still potentially be very hard to find.



Phase 1 will be about finding out and killing the ships that were auto-moved to 20 AU at patch day.

Phase 2 will be about finding out and killing the ships that were moved to off-plane deep safe spots (but within the new limits) before patch day.

I predict a fair number of people will believe to be smart and unique snow flakes at parking their stuff off-plane, others will just use of that knowledge.


Quote:

On a final note seeing as I am a pirate, I will be online as soon as the servers return to service following deployment of Tyrannis to do 2 things.

1. Claim some planets to make the inhabitants slave for me



Why "pirate" seems connected with "slave for me"?
All you need to be like that, is to roll Amarr and pretend to be righteous :D


Quote:

Raise the standard ME for invention BPC's to 0. BPO's would still have the advantage as they could be researched, but the big advantage they have in production price would be reduced.



No, no, no. T2 materials are the only economy that seems still to work (because of obscurity, not because of good game mechanics), putting invention to ME 0 would give a bad kick to the kidneys to it.
It's less damaging to keep T2 BPOs than that.


Quote:

Allow BPC's to be researched in some way (ME/PE). It shouldn't be very expensive, but should take time and require a research slot



It is... somehow. T2 is fine, the only thing that annoys me being the "random" chances.

Quote:

Vaerah Vahrokka:HAHAHAHAHAHAHA This coming from the same faction that got the greatest source of dev help in the history of MMOS!



IT <> BoB. It kept known faces and some of the old "core" but other things changed and hopefully for their best.


Quote:

Assuming the largest viable fleet battle i've ever heard of 500 on 500. If every ship is mounting 1 weapon. That accounts to 1 million calculations.



Actually what's very heavy weight are the setting up and the database queries. IE logging in is very intensive in both (and why we can get queues even with low numbers logged in). The other heavy cost operation is switching system, even more so if there's a large number of people in that system's warp in grid.
This is why of the issues at grids not loading: the stress off them interacts with some Dominion born bug (I can think it's the same bug happened with FW structures, "ported" into 0.0 + TCU).
What you say is the cause of part of the module lag. The calculation is a very small part of it, the rest being congestion in the TCP / IP pipes and database updates (IE every time a ship or drone pops and even when a new wrecks appears, a nice amount of database updates has to be done).

Quote:

Can a solid computer do these calculations. Sure can a server? Most definitely. But the problem comes in no small part from TRANSMISSION of said data. And here is where people are screaming



It can, 50% of the issue is caused client-side by the craptastic "quasi-interpreted" UI that can't keep up with the continuous refreshes to update the overview and even less update the brackets. In fact it's so bad that just to gate camp and kill frigs and cov-ops (that is, in a 4-5 ships scenario! Not 500) it becomes faster to hide the overview and manually target on screen. It's how some of my corpies could scram interceptors. Half was their "almost zero" lag connection, half was to get rid of the slow UI parts.


Vaerah Vahrokha
Minmatar
Vahrokh Consulting
Posted - 2010.04.19 07:40:00 - [197]
 

Quote:

Now everyone's running the super graphics which only increases the data being transmitted



No, it's client affected, the servers send the same stuff.


Quote:

Eve voice adds another layer or another voice comm setup.



1) Voice sucks and is usually dumped by every worthwhile corp and alliance. TS and ventrilo get used instead.
2) Voice is hosted on a third party (non CCP) server farm, EvE just notifies that server farm about you having logged in. After a while of not using it you even get logged off and then the "weight" is zero for everyone.


Quote:

Fixing this situation is not going to be easy. and its going to upset people in its method.



Fixing it is easy, it's the consequent teeth-gnashing and crying and rage-quitting that is the only obstacle to it.


Quote:

*IF* ccp has their source under source control (Please, by all that is holy and good in the world, you DO right ccp?) narrowing down *what* got changed should be as easy as running a diff against the old version.



They apparently started with a very, very "messy but works" spaghetti code and later they switched to agile programming.
Now, agile programming (I think they chose SCRUM) has very, very defined and strict practices.
This would almost impose a complete re-engineering of the "before agile times" source, but this is impossible because the game cannot be paused for a year.
So if they are confronted with the same challenges my own team was confronted in the past, they are using the "ancient code" as a black box, the new code just wires in and "feeds" the new features to that.
As long as no low level changes are done, the approach works, but when something as basic as grid / sov management gets touched, the consequences and collateral effects cannot be predicted and then sh!t happens. Usually in the form of "ugly hack to do, which WILL impact on something unrelated, basic and important else".


Stratio
Minmatar
Mirkur Draug'Tyr
Damu'Khonde
Posted - 2010.04.19 08:29:00 - [198]
 


Hack Harrison
Caldari
Posted - 2010.04.19 08:51:00 - [199]
 

Originally by: Kuseka Adama
Originally by: Hack Harrison

I must be dumb - WHAT has graphics got to do with server lag? Server tells client to shoot missile or laser blast. The graphic settings on the client determine WHAT you see (good/crap graphics). As long as the client is communicating with the server, lag won't come from "enhanced graphics forced on the server since the last expansion" as that is not something the server handles. Lag WILL come from the server failing to process messages in time... Also the data will be grouped into packets so less messages are sent over the wire.

BTW - your million messages would be on a P2P model X x X messages sent. This is server based. So for X ships there are 2X messages surely - X to the server. Messages are then processed. Server sends replies to X clients.
What is your computer science/programming background to justify your arguement?


Question 1: Server has to transmit enhanced graphics to the player. There is other reasonable explanation on some of what's being experienced. Because I've had similar issues in other games Anarchy Online being the most prevalent in my mind on this particular issue. Your computer has to process the extra graphics and because of an MMO's permanent spherical view that means it transmits everything. A grid loading those kind of graphics. Most gamers at this point are at least running 250's or their equivalents/better but even with an 8800 GT you'd still have no performance issues with this game. Otherwise there is something else completely at play here bordering on the Boot.ini error and given the time its taken to figure out i cant believe its anything that nuts. Heck i could be wrong but what the player sees has to be transmitted too doesn't it?

As for the background? I don't have much honestly. But to go with what you insinuate is that every thing is 'rolled' IE predetermined or 'grouped' and not allowing for independent damage. And combat logs specifically show that just isn't the case. Because its independent messaging i have to believe that everything is independent. If i'm wrong someone show me where CCP announced that kind of change because that ain't minor in the grand scheme of things. Regardless i just take what i see analyze it and make a few guesses.


Thanks for confirming my suspicions - you have no computer programming understanding, so you are talking crap. No game sends graphics over the internet (which is what you are saying). They send instructions on what to display. If your machine is slow, it may take time to process the instructions and your game will lag. THIS IS NOT THE SAME THING AS WHAT PEOPLE ARE TALKING ABOUT WHEN THEY HAVE BIG FLEET BATTLES (everyone lagging). You get the same instructions sent to/from the server regardless of if you have full graphics or bare bones turned on...

<tl;dr> You are talking out your backside, hypothesising about one of the most complicated computer programs in existence without any knowledge of computer programming or system design...

Ranka Mei
Caldari
Posted - 2010.04.19 10:00:00 - [200]
 

Edited by: Ranka Mei on 19/04/2010 10:23:40
Originally by: Hack Harrison

BTW - your million messages would be on a P2P model X x X messages sent. This is server based. So for X ships there are 2X messages surely - X to the server. Messages are then processed. Server sends replies to X clients.


If 500 ships are fighting, the server still has to send out a total of 250,000 (500 x 500) packets per update cycle. After all, each of those 500 ships needs to know about the changes of all those other 499 ships (+1 for their own position); so each client receives 500 packets.

250,000 doesn't seem like a lot, but it is. I have a small private gaming server, with an upstream capacity of 10Mb/s. Which in practice means I can roughly host 20 or so folks at one time, before out game start to lag too much as the server pipe gets crammed.

Having said that, I'm sure it's not a bandwidth issue, really. CCP's servers should be able to handle (500 x 500) UDP packets easily. Since CCP requires folks to fill out a form now before doing large battles, it would appear they add extra hardware to do, yeah, what exactly? Get better database response? Could be that's true. CCP itself says they're thinking the lag is caused by a bogged overview system. So, for now we simply don't really know.

Singion Hawk
Posted - 2010.04.19 10:26:00 - [201]
 

Originally by: Jattzia
The blog completely ignores that DEEP SAFE SPOTS ARE THE ONLY CURRENT WORKAROUND TO LAG.

Are the DEVs too ignorant understand this? Maybe, but some reply to the lag workaround issue raised about 500 times in the last thread would have been nice.


Camios
Minmatar
Sebiestor Tribe
Posted - 2010.04.19 10:29:00 - [202]
 

Since

The blog completely ignores that DEEP SAFE SPOTS ARE THE ONLY CURRENT WORKAROUND TO LAG.


We could try to find a cheap solution. A possible one is

make it possible to light a cyno inside a pos forcefield if the system sov is contested.

Den Dugg
Posted - 2010.04.19 14:40:00 - [203]
 

Deep safe spots are not a prob in my opinion. if u have over 200 employees workin on EVE Online fix the problems after this expansion and stop adding garbadge.. tyranais (however its spelled) looks kool but we keep tellin u things that are wrong and each expansion u barly touch them.. ppl who reply on fourms spend to much time in ur game to be ignored..and fix this ------------ CCP. my mineing slave pilots an orca. the ship can hold 56k m3 or in cargo hold, and there is corp hanger, ship maintainace bay and ore hold . flown next to my armagedon the ships are almost the same size... wtf lol? the armagedon can fit in the orca wth!?! still love this game but their are other games that will take this genre from u in the works if u dont un frak ur game.

ArmyOfMe
Hysera.
Posted - 2010.04.19 15:11:00 - [204]
 

Originally by: Camios
Originally by: Jattzia
The blog completely ignores that DEEP SAFE SPOTS ARE THE ONLY CURRENT WORKAROUND TO LAG.

Are the DEVs too ignorant understand this? Maybe, but some reply to the lag workaround issue raised about 500 times in the last thread would have been nice.

I imagine that what's really going on is that you're *hoping* Tyrannis will magically cure lag, but aren't sure so have a lips-sealed policy at this point.

...

I think you're underestimating how many people are sick of not getting good fights in 0.0, and what affect that is going to have on their subscriptions if it isn't robustly addressed in Tyrannis.


James Razor
Amarr
Fallen Angel's
White Noise.
Posted - 2010.04.19 15:48:00 - [205]
 

Tbh. atm i often ask myself if i realy want to log in into Lag Online if there is new big fight supposed to happen.

And i am allready pretty ****ed by A LOT of things CCP did in the past. I still think that the guys from art department that changed the faction BS deserve to get skined alive.

Oh and btw to all that hope that lag will get better: Planetary interaction will cause even more server load which will result in even more lag as they have to somewhere get those resources from.

Marchocias
Posted - 2010.04.19 18:08:00 - [206]
 

Originally by: Ranka Mei
Originally by: Marchocias

Speaking of which... the "Haves-vs-Have-nots" reason is ABSOLUTE HORSECRAP. Eve is ALL about Haves-vs-Havenots. Tech 2 BPOs are a clear example where CCP has stated that they do not mind unfairness.

What exactly did you have in mind that CCP do with those T2 BPO's? Destroy them, and deprive legitimate owners of property worth possibly hundreds of billions? (think T2 Hulk BPO, for example). Sure, indy corps possessing those have an advantage; it's just not the sort of thing you can take away easily. Watch how people (myself included) scream foul over CCP wilfully destroying propery at deepsafes. Now imagine what will happen if they start to destroy T2 BPO's; then multiply your estimation by two.


I don't propose anything... I rather like the game being unfair... I'm merely pointing out that it is inconsistent to claim that fairness is a reason for the deep safe nerf, given the continued existance of T2 BPOs.

Personally I think both T2 BPOs and Deep Safes should be kept in, but just make deep space un-anchorable, to avoid issues with sovereignty.

Marchocias
Posted - 2010.04.19 18:23:00 - [207]
 

Originally by: Hack Harrison
...
No game sends graphics over the internet (which is what you are saying). They send instructions on what to display.


Checkout OnLive. Astonishingly they're doing exactly this.

Vaerah Vahrokha
Minmatar
Vahrokh Consulting
Posted - 2010.04.19 19:26:00 - [208]
 

Quote:

If 500 ships are fighting, the server still has to send out a total of 250,000 (500 x 500) packets per update cycle



No, CFR 2009 posts about WH on IGN forums for the theory behind that.

The theorethical number can be squashed to "small" numbers like 2 x N or a function like that.

An old example:

http://www.usenix.org/event/nsdi06/tech/full_papers/bharambe/bharambe_html/main.html


where the "area-of-interest" would be an EvE grid and in secondary order, the influence sphere around each ship.
Also notice the way EvE server implements damage application and motion prediction AND (unlike other games) seems to perform game data loss in case the same TCP / IP request is sent "too soon" (ie modules recycling).

Liol Wongsta
The Arrow Project
Morsus Mihi
Posted - 2010.04.19 19:41:00 - [209]
 

It seems to me that there is a fairly simple method to remove the "real" reason for this, make it so sov structures can only be anchored within a set distance from a planet - similar to pos towers and moons.

Simple fix and removes the issue of anchoring things 500+ au away and making sov battles nearly pointless.

Let the deep safes exist.

Fix the fleet lag, making it no longer necessary to USE deep safes, just to have a hope of seeing your enemy in a fight.

Seth Ruin
Minmatar
Ominous Corp
Circle-Of-Two
Posted - 2010.04.19 21:21:00 - [210]
 

Originally by: Liol Wongsta
It seems to me that there is a fairly simple method to remove the "real" reason for this, make it so sov structures can only be anchored within a set distance from a planet - similar to pos towers and moons.

Simple fix and removes the issue of anchoring things 500+ au away and making sov battles nearly pointless.

Let the deep safes exist.

Fix the fleet lag, making it no longer necessary to USE deep safes, just to have a hope of seeing your enemy in a fight.


I really doubt the TCUs had anything to do with this. I still don't see what the "issue" is with placing a TCU in a deep safe. Anyone can see it on overview, anyone can warp to it. If it were a clear strategic advantage to have a TCU 500AU away, you'd see a hell of a lot more of them in deep safes. In all likelihood, the real reason for anchoring a TCU 500AU away is just "because you can."


Pages: first : previous : ... 3 4 5 6 [7] 8 9 10 11 : last (11)

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only