open All Channels
seplocked EVE Information Portal
blankseplocked New Dev Blog: Fixing Lag: Character Nodes
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: 1 2 3 4 [5]

Author Topic

Hawk TT
Caldari
Bulgarian Experienced Crackers
Posted - 2010.08.30 18:59:00 - [121]
 

That's called serious science & research!

But I knew it, I knew it - CCP Dr.EyjoG is a Doctor of Medicine and the whole "Economic lifecycle" b....t is just a cover!!! Twisted Evil Actually, his sole responsibility is to keep the Devs @ The Ballmer's Peak Laughing

Originally by: CCP Masterplan
Originally by: Trebor Daehdoow
Originally by: ELECTR0FREAK
This is what happens when the Devs drink on the job. We get ships that look like the Moa or the Dominix and blogs get reposted.


Actually, you have it exactly wrong -- Ships like the Dominix are what you get when devs are stone-cold sober.

For the Icelandic subspecies of dev, at least, the question is not whether they should be intoxicated, but what level of inebriation is appropriate for a particular task; for example, it is clear that game designers do their best work when falling down drunk, whereas the lag team is most effective when they've just had one or two shots "to take the edge off".

The exact blood-alcohol levels needed for optimum dev productivity is a subject of intensive ongoing research at CCP (and the subject of an upcoming devblog by CCP Tequila), and there are rumors that breathalyzer authentication modules will soon be added to all workstations to prevent the devs from logging in when they are under-medicated.

I think this is what you're looking for...

Lan Tragger
Posted - 2010.08.30 19:02:00 - [122]
 

Originally by: CCP Masterplan

I think this is what you're looking for...


I always wondered why I did my best work on the laptop at the bar and why getting married seemed to diminish my programming skills. :)

Tiger's Spirit
Caldari
Posted - 2010.08.31 03:36:00 - [123]
 

Edited by: Tiger''s Spirit on 31/08/2010 03:36:50
"A new command line switch has been added that will disable the lighting effects on Alienware machines that support it. It is “/nolightfx”."

CCCP mistake, need more command line switch to 1.0,5 patch, "/nolagfix" again :D

Troy LS
Posted - 2010.08.31 20:34:00 - [124]
 

I seem to recall reading a Dev Blog that explained that large fleet fights were unpredictable and that it was difficult to allocate computing resources to such fights. I'm not a programmer but, as an engineer, I have studied statistics and probablity. It seems to me that there are some statistics that would help predict resource utilization on a particular node.

For instance, if a fleet is formed, there is a chance that it will engage a similarly sized fleet. The probability of engagement increases if there are two or more fleets in close proximity. The probability is further increased if the two fleets have negative standings with one another, and virtually assured if they are at war.

My point is that a stochastic model can be developed that would predict resource utilization and allocate resources accordingly. When the model incidates a high probability of resource utilization, the resources can be apropriately allocated PRIOR to the engagement. The resources that might be involved can be predicted by the number of pilots in fleets, the number corpmates and alliance members and associates with standings that are online and in the region, and the resources (ships) that are availabile to those pilots.

I think its funny that CCP has asked players to inform them when they expect large fleet engagements. I can't think of too many situations when enemies have agreed to fight at an agreed upon time and place.

Anyway, this is a great Blog post and I'm happy to see the developers really are taking action.

Dannemora
Posted - 2010.09.02 03:58:00 - [125]
 

Originally by: Troy LS
I seem to recall reading a Dev Blog that explained that large fleet fights were unpredictable and that it was difficult to allocate computing resources to such fights. I'm not a programmer but, as an engineer, I have studied statistics and probablity. It seems to me that there are some statistics that would help predict resource utilization on a particular node.

For instance, if a fleet is formed, there is a chance that it will engage a similarly sized fleet. The probability of engagement increases if there are two or more fleets in close proximity. The probability is further increased if the two fleets have negative standings with one another, and virtually assured if they are at war.

My point is that a stochastic model can be developed that would predict resource utilization and allocate resources accordingly. When the model incidates a high probability of resource utilization, the resources can be apropriately allocated PRIOR to the engagement. The resources that might be involved can be predicted by the number of pilots in fleets, the number corpmates and alliance members and associates with standings that are online and in the region, and the resources (ships) that are availabile to those pilots.

I think its funny that CCP has asked players to inform them when they expect large fleet engagements. I can't think of too many situations when enemies have agreed to fight at an agreed upon time and place.



I'm not a not an engineer, but as a systems architect, I saw roughly the same as you in that dev blog :)

However I also noticed one big problem in the current design that negates the effect of being able to predict the resource utilization in real time.

They can't shift people off a location node once it's loaded for them without booting them off it in the process.

That's why they need to perform the load pattern during downtime.

It's like knowing how much beer you should stock an aircraft with before it takes off.

Sure there's nice studies that show the normal consumption based on a boat load of parameters. But if one large group of, let's say, middle aged accountants, wasn't heading to some important seminar but actually going to a 30 year celebration of their graduation, the calculation would most likely be off. And the accountants would run the aircraft dry, at least of beer.

Loading every single flight with enough beer to serve an entire cabin full of beer-happy accountants isn't a workable solution. It would be way to expensive for any company to add all that weight just to shuttle beer around the globe for no good.

Mid air refuelling would work. But it would require that such an option was added at the design stage. Adding it to existing aircraft would be a really hairy job.

But, when I read the devblog I also noticed that they are moving as much as possible off the actual aircraft, erh location node.

This in extension would make it a good deal easier, or at least less complex, to re-engineer the choke points.

Redesigning the beer supply system to handle air-refuelling is easier than redesigning the entire aircraft.

So I'd say, with some experience, that they are on the right track, and improvements will come.

But it'll take a while to get it done, and they will have to tread carefully not to create new problems in other areas.

/D

ELECTR0FREAK
Eye of God
Posted - 2010.09.03 03:25:00 - [126]
 

Edited by: ELECTR0FREAK on 03/09/2010 03:28:18
Edited by: ELECTR0FREAK on 03/09/2010 03:27:59
Originally by: CCP Masterplan
Originally by: Trebor Daehdoow
Originally by: ELECTR0FREAK
This is what happens when the Devs drink on the job. We get ships that look like the Moa or the Dominix and blogs get reposted.


Actually, you have it exactly wrong -- Ships like the Dominix are what you get when devs are stone-cold sober.

For the Icelandic subspecies of dev, at least, the question is not whether they should be intoxicated, but what level of inebriation is appropriate for a particular task; for example, it is clear that game designers do their best work when falling down drunk, whereas the lag team is most effective when they've just had one or two shots "to take the edge off".

The exact blood-alcohol levels needed for optimum dev productivity is a subject of intensive ongoing research at CCP (and the subject of an upcoming devblog by CCP Tequila), and there are rumors that breathalyzer authentication modules will soon be added to all workstations to prevent the devs from logging in when they are under-medicated.

I think this is what you're looking for...


LMAO, awesome! Laughing

Well then, someone's sneaking a little more than their designated beer ration!

Mal Lokrano
Gallente
The Executives
Executive Outcomes
Posted - 2010.09.03 09:07:00 - [127]
 

Edited by: Mal Lokrano on 03/09/2010 09:16:22
Originally by: CCP Atlas
up to 80% of the calls were routed elsewhere freeing Jita up for important things like inventory operations and scams in local.


That made me lol, thanks.

Thy Collector
Posted - 2010.09.07 23:52:00 - [128]
 

So... I get this (I think). But it doesn't exactly explain the gate lag. If the CPU was really being overloaded, wouldn't this just backup the queue so that there would be a delay from when grid loaded, but not so long that the request would time out. Correct me if I'm wrong, but aren't all requests sent to the location node put into a queue. Under normal load, the queue is processed relatively quickly so it often takes less than a second for things to complete. If the CPU was being jammed with more requests than could be processed in a normal fashion, wouldn't this just back up the queue and bit, and not cause a complete failure of processing of requests.

I figure that you guys are using a priority queue so that certain requests get placed higher up in the queue than other requests. This seems to make sense until those higher priority requests begin to fill up the queue at an unusually fast rate, and so low priority requests never get taken care of. Could this possible a reason as to why the grid never (or takes forever to load) for everyone jumping in? Are requests such as loading a grid from another system (or other things that would effect us actually loading grid after jumping) being put so far back in the queue relative to other requests that they are just never taken care of and time out?

If so wouldn't it make sense to us some kind of run-time like algorithm so that requests that have been in the queue for too long are forced to the front? E.G. requests must be completed in a certain amount of time, regardless of their original priority.

I ask this because I don't understand why loading grid is never taken care of as that seems to be the biggest issue. Its one thing for the grid to take an extra 10-30 seconds to load and its another thing entirely for the grid to take so long to load that the request times out and then we are left helpless.

Further more, sense those already on grid have much less of in issue are grid requests from those entering a new system less important than those already in system?

I understand that there are also other things that need to be taken care of, such as making sure that their are no unnecessary repeats of requests, especially high priority requests, but if it indeed is the case that some requests are just being pushed back so much that they are never taken care of, it seems that making sure they are processed at all should be a higher priority.

Nytemaster
Blackwater USA Inc.
Against ALL Authorities
Posted - 2010.09.08 07:06:00 - [129]
 

Quote:
Through their work and the work of others, there's now, at this moment, a perfect storm within the company and we have a great number of fixes in the pipes that will knock your socks off.


I knew we had a Dev in corp and this post proves it.

Mashie Saldana
Minmatar
Veto Corp
Posted - 2010.09.09 12:56:00 - [130]
 

Originally by: Nytemaster
Quote:
Through their work and the work of others, there's now, at this moment, a perfect storm within the company and we have a great number of fixes in the pipes that will knock your socks off.


I knew we had a Dev in corp and this post proves it.

Omg, you must be George Clooney then, can I have your autograph please? Laughing

Rakessh
Bat Country
Goonswarm Federation
Posted - 2010.09.30 20:47:00 - [131]
 

Quote:
Another example of a load balancing unit is a solar system. Typically we will have multiple, even hundreds of solar systems living on a single node. We call these types of nodes Location Nodes. Typically these solar systems have such low load that they can be mapped onto a node with a lot of other systems in the same way as the market is. However, now comes the gotcha: If a single solar system exceeds the capacity of the CPU core we have lost the ability to further balance it.


Not entirely correct, and cpu utilization figures alone does not tell the whole story, maybe not even the truth.
Running several hundred solar system on a single node because they are low-load ones, doesn't mean you won't run into trouble.
There are only so many time slices in a second for any task to complete! Typically one "balancing" unit running on the same node as another "balancing unit" will compete for cpu time, and thus you will have to pay close attention to your process que depth.

Tweaking of the kernel to solve this problem is a must, you have to create more time slices. It will increase kernel overhead, but also increase the responsiveness until you hit the utilization barrier. Do you guys actually do that to your windows servers, or are you trying to run less than 50 "balancing units" per node? I think the normal win NT (2000) kernel has 20ms slices, so in one second you have 50 slice units. So your guys will have to decide the time resolution each process should have (how many time per second the process is allowed cpu time so it can respond to new input).

So whenever you are running more potentially cpu intensive processes than configured time slices, you may end up with processes end up in time starvation. Response times will skyrocket, and even a solar system with only 10 guys in it can feel jita-laggy.

Just thought I'd point it out, seeing the article was doing it easy-mode, I hope it doesn't mean you weren't aware though ;)



Pages: 1 2 3 4 [5]

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