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


 
Pages: 1 2 3 4 5 6 [7]

Author Topic

Liang Nuren
Posted - 2010.08.25 18:29:00 - [181]
 

Edited by: Liang Nuren on 25/08/2010 18:29:25
Yeah, I absolutely have no intention of doing anything more than offering encouragement, tossing some ideas out, and earlier attempting to translate the dev blog into something that I and perhaps others can understand. Also, Warlock made my week by responding to our little aside here. It made up for the form rejection letter CCP sent me for my resume. Razz

(Reference: CCP Explorer told us all to stop *****ing and help fix the problem. So I applied. :P)

-Liang

Ed: Also, check your evemail on evegate - I'm going to shoot you my email address and maybe we can talk shop about parallel processing. It sounds like we do the same thing but have different perspectives... and I llluuurrrrvvv talking shop!

Whatever Dood
Posted - 2010.08.25 18:54:00 - [182]
 

Okay.

Captain Yifan
Northstar Cabal
R.A.G.E
Posted - 2010.08.25 19:06:00 - [183]
 

CCP Warlock's anti-lag doomsday device hits the lag monster, wrecking 0.00001 damage.

super lag torpedo hits CCP Warlock's anti-lag Titan, wrecking 1e3333 damage

super lag seige launcher is deactivated as CCP Warlock's anti-lag Titan began to explode.

Joking aside, keep it up Razz

Rn Bonnet
Sniggerdly
Pandemic Legion
Posted - 2010.08.25 23:18:00 - [184]
 

Quote:
We are not in any way ignoring the multi-core possibilities btw., so please don't read that into anything here. I will confess to being a little tired of people telling me they're a total solution to all scaling problems though. They get you more CPU, and then outside some of the simple mathematical models, a lot of work designing the application to take the best advantage of it. Unfortunately, a thread is not some imaginary friend that will solve all performance problems - when you really need Mr. Thread he's just never there for you.

What are you talking about, I love Mr. Thread he always shows up for me Razz.

I like others here have no ability to "tell you" what you should design (not unless you can pay more than my current employer :p).

Also you are correct I misinterpreted your statement, indeed the algorithmic cost of communication eventually overloads everything but embarrassingly parallel problems.

However, I have a hard time imagining how they are not a problem to EVE's scaling problem with some smart partitioning of processes.

CCP Warlock

Posted - 2010.08.26 00:08:00 - [185]
 

Edited by: CCP Warlock on 26/08/2010 00:31:49
Originally by: Whatever Dood
Originally by: CCP Warlock
The Gupta/Scaglione (Gupta presented the original result, but Scaglione's proof is much more elegant), is very important in what it tells us about scaling limitations in these systems.


I'm sorry, but you can't talk like this if you're trying to communicate. (I get this same thing from Bartholomeus, btw.) I don't know what "the Gupta/Scaglione" refers to, and a quick google doesn't clear it up for me. And yet, I suspect it's a principle that's familiar to me. The last time Barto did this, it took four pages of posts to clear up that his obscure reference was to a principle I not only already knew but had extensive experience working with/around. caveat: I don't actually feel you have an obligation to divulge as much info as you guys are doing. But still, if we're chatting.


My bad, sorry - I thought I had it in the presentation, but in any case I should have linked it properly. I also love chatting about this stuff, but i should probably avoid trying to do it quickly at work Smile

On the Interdependence of Routing and Data Compression in Multi-Hop Sensor Networks Scaglione

is the Scaglione paper, and it references the earlier work by Gupta and Kumar The Capacity of Wireless Networks.

The first two pages of the Scaglione paper are a much more elegant version of the same result in Gupta and Kumar. Stripping out the domain specific stuff, what both these papers are talking about is the instantaneous Information capacity of distributed systems. Not just wireless networks, or sensor networks but all distributed systems.

The key results, imho, is that first there is a limit which does not scale with N for mesh networks, and secondly that the limit depends on the topological relationships of communication between the nodes - and it's trivial to show that a much lower limit exists for centralised systems (hierarchical) than de-centralised. (It was at this point that a little light bulb went on in my head and I went, oh now i understand why communism failed.)

Originally by: CCP Warlock
but we also have much larger applications now too.

Of course that works in the opposite direction generally, ie, lower statistical chance of contention, lower percentage concurrency overhead. (Just boatloads more work to decompose.)


Generally.

Or perhaps it might be said it increases the total number of tractable cases, but still leaves the intractable ones that are the domain of the various truly large scale distributed systems, which is essentially networks, and networked applications - like MMO's. After all, the Gupta and Kumar result only really affects a very specific set of real time applications that are continuously producing and processing information. All the other applications can just run however long it takes to process all that they have to.


Rn Bonnet
Sniggerdly
Pandemic Legion
Posted - 2010.08.26 00:13:00 - [186]
 

Edited by: Rn Bonnet on 26/08/2010 00:21:05
Edited by: Rn Bonnet on 26/08/2010 00:18:08
Just to be clear by the way I am not hounding you. I am just one of those people who get fascinated by problems and can't stop thinking all day about architectures for a multi-threaded eve or something similar. Which is probably why I was spending 20 hours+ a week on tournament setups not so long ago. I particularly find the task of reducing something like eve's grid/node which is transparently n to n into a smaller number of communications fascinating.

(Also http://www.eveonline.com/On%20the%20Interdependence%20of%20Routing%20and%20Data%20Compression%20in%20Multi-Hop%20Sensor%20Networks 404's for me).
You where probably looking for: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.5839 )


CCP Warlock

Posted - 2010.08.26 00:40:00 - [187]
 

Edited by: CCP Warlock on 26/08/2010 00:48:03
Edited by: CCP Warlock on 26/08/2010 00:47:26
Originally by: Rn Bonnet
Edited by: Rn Bonnet on 26/08/2010 00:21:05
Edited by: Rn Bonnet on 26/08/2010 00:18:08
Just to be clear by the way I am not hounding you. I am just one of those people who get fascinated by problems and can't stop thinking all day about architectures for a multi-threaded eve or something similar. Which is probably why I was spending 20 hours+ a week on tournament setups not so long ago. I particularly find the task of reducing something like eve's grid/node which is transparently n to n into a smaller number of communications fascinating.

(Also http://www.eveonline.com/On%20the%20Interdependence%20of%20Routing%20and%20Data%20Compression%20in%20Multi-Hop%20Sensor%20Networks 404's for me).
You where probably looking for: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.5839 )




Fixed - thanks.

Yes, that's pretty much my problem too. They are fascinating. And btw. seeing as how Mr. Thread is hanging out at your place all the time, i'm going to have to insist we clear this contention the honourable way, and have it out with deadlocks at dawn.

Your choice of semaphores Smile

Rn Bonnet
Sniggerdly
Pandemic Legion
Posted - 2010.08.26 01:13:00 - [188]
 

Mutex's it is than. At dawn.

Very Happy

Camios
Minmatar
Sebiestor Tribe
Posted - 2010.08.26 07:48:00 - [189]
 

Edited by: Camios on 26/08/2010 07:48:38
Originally by: CCP Warlock
(It was at this point that a little light bulb went on in my head and I went, oh now i understand why communism failed.)



I have lots of things to say about it, but moderation does not allow us to speak about politics on the forums (and it's fair because politics is a serios businnes since people even die for it).
I'll just say that your conclusions and underlying reasoning is pretty superficial.
I appreciate your professionality (when it's there), though.

Yeay Fritg
Caldari
Confrerie de Kaedri
Cluster Of Rebirth
Posted - 2010.08.26 13:02:00 - [190]
 

Sorry,

But CCP I just want a BackLog Bug Dev Blog !

Do you read the forums or will you moderate all our quality request if not in line with your marketing plan ?

Yeay

Whatever Dood
Posted - 2010.08.26 14:47:00 - [191]
 

Warlock, I keep coming back to our problem space. It just does not seem to me that the sort of limits Gupta and Scaglione are discussing apply to us yet, and probably never. Now, there was some discussion elsewhere of putting each ship, for instance, on a separate thread (and then assigning the threads to nodes or cores, doesn't matter for this) - in that case, our "N" gets large enough that these sorts of limits would be applicable. (Also, aside - I think Charlie Stross, Sci-fi author of "Accelerando" etc you guys were talkng about a few days ago, might benefit from reading this sort of thing before postulating the sort of near-future technical utopia worlds he gets off on.) But for our purposes "N" is number of cores, and is just too small. It's likely to stay small-ish in the near future, and even if (for instance) we get something like 256-core servers in the near future, the "N" isn't even total local cores, it's total cores simulating a single location LBU. I'm not sure I see the necessity to use anything but a small subset of them for our problem - ie, decomposing to the level of a ship or small number of ships per core just isn't required, so we'd only use a few of the 256 for each location LBU.

Are we just talking general theory, or where EVE might end up in 10 years? That's fine. Unless we're talking about inter-location communication? If so, then sure, lots of those, but then the "topological relationships" are restrictive (locations don't need to know much about others that are far away), and shared information limited and well-defined. (Locations are very self-contained, most of the data needed to run the sim is only needed in that one LBU.) argh, realizing I'm not sure what we're talking about again. <sigh> I'm used to it.

Something else you said, Jackie -

"All the other applications can just run however long it takes to process all that they have to."

I think that we might be ignoring an elephant in the living room. The EVE location LBU's do have to finish their processing in a limited amount of time. But my GOD, the constraint is to finish in a SECOND!! I've had a lot of experience profiling and optimizing a lot of different sim loops, and I've a pretty good "feel" for the complexity of the EVE location LBU sim vis a vis others. It just seems to me that one second is far more time than I'd expect to take even for 4000 ships (and their associated components, ie, drones fighter-bombers etc.)** It's also the reason I agree with all the CCP devs' assertion that conventional optimization first is the way to go, as well as concentrating on dynamic LBU migration, ie -

* One second is too much time (optimization), and...
* We probably aren't getting the full second in most lag situations, ie, other LBU's are likely infringing on our processing time. (LBU migration)

Aside from possible LBU fighting, It seems to me that something pathological is going on here. When we encounter this in my world it often boils down to massive numbers of fine-grain general-purpose memory allocations, or badly implemented (often synchronous) I/O, or straight-up n-squared processing bugs. What I'd be frightened of is that one or more of these (or similar, ie messaging?) problems might be endemic, ie, baked into EVE by unlucky architectural choices in such a way that attacking them is problematic. Also, Python makes me nervous. :)

** - the deal with the eve sim is that it doesn't have to do a lot of processing other sims deal with. No terrain collision, no/simple model bone animation and skinning, no navmesh traversal or physics raycasting. Shoot, most of the real time-consuming elements of a conventional game sim loop just aren't there. CCP Veritas mentioned that the physics step isn't a large part of the load, and that jives.

Flitterby
Posted - 2010.08.27 01:53:00 - [192]
 

Warlock: Your dissertation sounds interesting, is it online? Mine was in a similar vein, but I focused on how autonomous agents could learn to ground symbols and create their own protocol for sharing information and cooperating, particularly across generations.

Zanzan Naznaz
Posted - 2010.08.27 18:03:00 - [193]
 

Warlock,

I read the devlog. Interesting problem, particularly surrounding the possibility of multiple factors combining to produce the lag. You should read "Minding The Machines", which has a number of case studies of disasters involving cascading failures (Bhopal, Chernobyl, East Cost Power Outage, and others). The upshot is that although all of these complex systems had multiple backup plans to deal with subsystem failure, they ended up failing in ways that the original designers didn't think of (and, perhaps, couldn't imagine in advance). In some cases, the complexity of what they had built was too much for a human to imagine all the possible failure modes. Ultimately, cascading failures caused a catastrophic event.

There may be something like that in play with the EVE lag problem. Of course, that also makes it really hard to solve, as you mentioned.

I obviously don't have the specific knowledge of your environment necessary to do any real troubleshooting, but if I were to breakdown the possible problem space, I'd look at these areas:

1. Database - Either load related (which should be fairly easily found, and you probably would have already, so I doubt that's it), or query related (I've seen malformed SQL queries cause lag, even though the query eventually finished and returned a correct result).

2. Network - You mentioned your pet theory of the TCP congestion algorithm and rate adjustments being an issue. Although you later determined that not to be an issue, there are other network related issues (such as packet fragmentation along the path) which could be at play. I could foresee issues where occasionally having to handle fragmented packets doesn't cause any problems, but causes lag when a lot of them happen.

3. Disk I/O - Sort of the same deal as network: things that aren't an issue at a small scale become huge problems when scaled up. I imagine you've got the monitoring tools in place already to figure out if disk I/O was the problem though. Have you seen the video of the guy who demonstrated that the vibration from a loud sound can cause a huge spike in disk latency by yelling into a disk array? It was crazy, and not something that anybody would normally consider when trying to troubleshoot something. I love weird stuff like that.

As an infrastructure guy, I take a layered (as in OSI model) approach to troubleshooting. Start at the physical layer and work your way up. Even if a problem was introduced at the application layer, the root cause can often be traced to sensitivity to something going on at the data link, network, or transport layers.

I don't expect this to be particularly helpful, but thought I'd throw it out there.

Zanzan

Rn Bonnet
Sniggerdly
Pandemic Legion
Posted - 2010.08.28 06:26:00 - [194]
 

Quote:
the deal with the eve sim is that it doesn't have to do a lot of processing other sims deal with. No terrain collision, no/simple model bone animation and skinning, no navmesh traversal or physics raycasting. Shoot, most of the real time-consuming elements of a conventional game sim loop just aren't there. CCP Veritas mentioned that the physics step isn't a large part of the load, and that jives.

I too have wondered where all the performance is going. Now python is undeniably slow, but it shouldn't be THAT slow form what I do know, especially if you are JIT compiling it.

Whatever Dood
Posted - 2010.08.28 17:03:00 - [195]
 

Originally by: Rn Bonnet
Quote:
the deal with the eve sim is that it doesn't have to do a lot of processing other sims deal with. No terrain collision, no/simple model bone animation and skinning, no navmesh traversal or physics raycasting. Shoot, most of the real time-consuming elements of a conventional game sim loop just aren't there. CCP Veritas mentioned that the physics step isn't a large part of the load, and that jives.

I too have wondered where all the performance is going. Now python is undeniably slow, but it shouldn't be THAT slow form what I do know, especially if you are JIT compiling it.


It's pure bulk. Which is sort of bad for optimization, the load profile is probably flat as a Kansas cornfield. Fewer obvious places to spot-optimize.

Liang Nuren
Posted - 2010.08.29 04:58:00 - [196]
 

Edited by: Liang Nuren on 29/08/2010 05:00:23
Originally by: Whatever Dood
Warlock, I keep coming back to our problem space. It just does not seem to me that the sort of limits Gupta and Scaglione are discussing apply to us yet, and probably never. Now, there was some discussion elsewhere of putting each ship, for instance, on a separate thread (and then assigning the threads to nodes or cores, doesn't matter for this) - in that case, our "N" gets large enough that these sorts of limits would be applicable.


The amount of things being processed in parallel has nothing at all to do with the total amount of processing to do. Consider that for a fight of size N, any publicly visible action (like moving your ship, firing your guns, or blowing someone up) must notify the N-1 other participants. Thus, the growth is definitely going to be N(N-1) where N is the number of people present (thanks for the correction Warlock).

To really drive the point home, assume that we only have to worry about two public actions (movement and fire notifications) and one private event (damage notifications). We'll also assume nobody blows up and ignore the multitude of other kinds of things to be processed.

So suppose we have a quad core machine where each core can process a million of these notifications per second. The game would scale as follows:
1M/sec, Big Fleets:
- 1 cores: 708 players
- 2 cores: 1000 players
- 3 cores: 1225 players
- 4 cores: 1415 players
- 8 cores: 2000 players
- 16 cores: 2829 players

Suppose we used a high level programming language that only processed half as fast:
500K/sec, Big Fleets:
- 1 cores: 500 players
- 2 cores: 708 players
- 3 cores: 867 players
- 4 cores: 1000 players
- 8 cores: 1415 players
- 16 cores: 2000 players

An impressive difference in the beginning, but looks to be ultimately meaningless as the number of people fighting goes up. Also, Python is generally not that slow.

Suppose the original programming language, but a game mechanic change that forced people to disperse into 4 smaller fleets:
1M/sec, 4x Small Fleets:
- 1 cores: 1415 players
- 2 cores: 2000 players
- 3 cores: 2450 players
- 4 cores: 2829 players
- 8 cores: 4000 players
- 16 cores: 5657 players

And of course, this is what Warlock was getting at - a good permanent solution will involve game mechanic changes.

-Liang

Ed: Also, I didn't include drones [ O(n*m), n = players, m = players + drones ] or people that keep their guns ungrouped [ O(m * n(n-1)), n = num players, m = guns/ship ]. Hell, there's a lot of things I didn't include - mostly because I don't know enough about the situation to include them. Razz

Liang Nuren
Posted - 2010.08.29 12:26:00 - [197]
 

Oh yeah, and that wasn't to dismiss your whole post, just to settle the question of what N was and explore its effects a bit. I deliberately avoided the questions of optimization and tick time.

What I can say on that topic is pretty limited - I know that all games expect all events to resolve within tick time, and that FPSs run very fast ticks. I'm of the opinion that MMOs run slow ticks like MUDs did. It seems like one of the advantages of a slower tick would be that you're more forgiving to lag and slower ping.

-Liang

Whatever Dood
Posted - 2010.08.30 18:04:00 - [198]
 

Liang, your post here shows what happens as you scale up an application that has an N-squared growth rate (ie, O(N*N). Two quick notes -

1) You're assuming available processing power increases linearly with additional cores. That's not correct. In other words, two cores won't give you twice as much processing bandwidth as one. It'll be some fraction of that, due to cross-core communication inefficiency. But, more importantly...

2) No simulation should scale as a squared function of the number of elements (ie, ships etc.) For that matter, no portion of the simulation should scale at O(N*N). If it does, it's a bug. (We like to call it an "n-squared bug".) Very Happy You might not be saying that it does, but if you are, you're mistaken. Or, more accurately, if it does scale as O(N*N), it's a bug. There likely are some parts of EVE's simulation that currently scale that way, but they need fixing.

Liang Nuren
Posted - 2010.08.30 19:17:00 - [199]
 

Originally by: Whatever Dood

1) You're assuming available processing power increases linearly with additional cores. That's not correct. In other words, two cores won't give you twice as much processing bandwidth as one. It'll be some fraction of that, due to cross-core communication inefficiency. But, more importantly...



Of course this is true for a huge variety of reasons. I didn't want to complicate things by trying to account for it though.

Quote:

2) No simulation should scale as a squared function of the number of elements (ie, ships etc.) For that matter, no portion of the simulation should scale at O(N*N). If it does, it's a bug. (We like to call it an "n-squared bug".) Very Happy You might not be saying that it does, but if you are, you're mistaken. Or, more accurately, if it does scale as O(N*N), it's a bug. There likely are some parts of EVE's simulation that currently scale that way, but they need fixing.



I'm not sure how you can say that - those are customer facing notifications that have to be sent. It's why I chose them.

-Liang

Whatever Dood
Posted - 2010.08.30 19:31:00 - [200]
 

Originally by: Liang Nuren
Quote:

2) No simulation should scale as a squared function of the number of elements (ie, ships etc.) For that matter, no portion of the simulation should scale at O(N*N). If it does, it's a bug. (We like to call it an "n-squared bug".) Very Happy You might not be saying that it does, but if you are, you're mistaken. Or, more accurately, if it does scale as O(N*N), it's a bug. There likely are some parts of EVE's simulation that currently scale that way, but they need fixing.



I'm not sure how you can say that - those are customer facing notifications that have to be sent. It's why I chose them.

-Liang


We've probably got some sort of misunderstanding. Why would a ship firing its guns (for instance) need to communicate that fact to the other N ships? Are you referring to internet communication load or something similar? I'm talking about sim processing load.

Magunus
The Forsakened Few
Green Alliance
Posted - 2010.08.30 22:50:00 - [201]
 

Has CCP happened to see this? Allowing multiple cores act as one

It's still experimental unless something has changed, and I have no idea how well it works, but it sounds like it would help with your 1 system/1 CPU problem without massive rewrites. Of course, integrating it with Python might be a challenge...

Liang Nuren
Posted - 2010.08.31 05:51:00 - [202]
 

Originally by: Whatever Dood

We've probably got some sort of misunderstanding. Why would a ship firing its guns (for instance) need to communicate that fact to the other N ships? Are you referring to internet communication load or something similar? I'm talking about sim processing load.



I'm talking about the actions as a whole. Processing an individual action may be cheap ("I fire my guns", "I move 100 meters"), but it will spawn N-1 "messages" to be sent. Even if you can conceptually think of these messages as being purely network bound, they will take CPU cycles to put in queue.

And in the end, the entire presentation was about communication and network bottlenecks in various topologies of distributed systems.

-Liang

Tiger's Spirit
Caldari
Posted - 2010.08.31 06:31:00 - [203]
 

1.0.5 fixes :D

So important.

A new command line switch has been added that will disable the lighting effects on Alienware machines that support it. It is “/nolightfx”.

Maybe need one more commandline switch the "/nolagfix" :DDDDD
Soon™

Ban Doga
Posted - 2010.08.31 07:05:00 - [204]
 

Originally by: Liang Nuren
Originally by: Whatever Dood

We've probably got some sort of misunderstanding. Why would a ship firing its guns (for instance) need to communicate that fact to the other N ships? Are you referring to internet communication load or something similar? I'm talking about sim processing load.



I'm talking about the actions as a whole. Processing an individual action may be cheap ("I fire my guns", "I move 100 meters"), but it will spawn N-1 "messages" to be sent. Even if you can conceptually think of these messages as being purely network bound, they will take CPU cycles to put in queue.

And in the end, the entire presentation was about communication and network bottlenecks in various topologies of distributed systems.

-Liang


If I wanted to tell everyone living in my house some incredibly important news (e.g. it started raining) I could go and talk to all the n people living in my house.
That would require n messages for the n people: more people would mean more messages and more effort for me.

Another way would be to write a post-it and put it on the "weather section" of the in-house bulletin board (alternative: yell at the top of my lungs)
This has two advantages:
1. no matter how many people will read that post-it I only have to write it once (less messages sent)
2. only the people who care about that information will look for it (less messages received - not true for the yelling alternative Rolling Eyes)

This pattern is called publish/subscribe and demonstrates that sending/receiving messages does not always have to become harder for the one sending the messages. (It can still be a very difficult problem in large systems)

You would not expect someone giving a speech having to work harder just because another listener arrived either, eh?

Whatever Dood
Posted - 2010.08.31 09:11:00 - [205]
 

Edited by: Whatever Dood on 31/08/2010 09:17:13
That's a pretty good general description, Ban Doga. We can also give a specific example of a ship firing its weapons.

First off, weapon firing will have some affect on the firing ship's state. (ammo expended, blinky modules, etc.) Then, it will possibly affect one other ship directly, ie, the target. All constant load so far.

The firing action will also cause some graphic objects to be registered in the visual scene. This is analogous to posting it on your bulletin board, Ban. This scales linearly with number of ships.

Then, finally, somewhere down the road the visual scene has to be read by all the clients. This is one big blob of data. Again, it's like the bulletin board - except in this case, everyone has to display the scene, ie, read the bulletin board. Now this right here is why I was asking Liang if he was talking about network traffic, because the network load could go up as N*N, ie, scene complexity scales up linearly with number of ships multiplied by number of clients which is again, number of ships. But my understanding is this transmission load is both outside the sim loop and handled by the client proxies - ie, each of the proxies samples the scene out of shared network memory and transmits to their associated clients. It's not part of the sim load, and each client's transmission load scales linearly. Also, my understanding is that's not currently a problem, CCP is handling the transmission load just fine. (I could be talking out of my ass again on how they transmit the scene, speculating.)

I think all this jives with what Warlock has posted, Liang. I don't think she was saying anywhere that the EVE sim load scales as O(N*N), she was referring to mesh networks for that.

Whatever Dood
Posted - 2010.08.31 09:15:00 - [206]
 

Hey, I was just thinking - bombers might risk incurring an N-squared load. In that case (finding all affected targets) we'd probably avoid the N-squared load for testing on whether they're within the blast radius by doing some sort of hierarchical spatial partitioning on fleets. But then it could affect quite a few ships. <shrug>

Eventy One
Magellan Exploration and Survey
Mordus Angels
Posted - 2010.08.31 13:20:00 - [207]
 

Edited by: Eventy One on 31/08/2010 13:23:59
Just a thought, with no centralized control, presumably your autonomous robots need to engage in some type message passing routine to develop/establish cooperative relationships. Which means that in terms of scalability, your problems arise in 'negotiation' rather than steady-state situations.

If so, John Forbes Nash might come in handy here, with his Nash equilibrium. He basically over throws the previously held idea that a populations benefits the most when autonomous agents within the population act solely in self-interest. In game theory, the idea is that each player only strives for maximum benefit, but this is provably less optimal than when when there is a strategy that holds in equilibrium the interest of each player doing what is maximally best for them against what is best for society. This is known as Nash equilibrium.

What it means for your example of developing distributed cooperation is a model of how to constrain or model the negotiation scenario in a way that makes it more scalable, while deriving optimal benefit for the entire population.

If right now, negotiation is modeled as simply back and forth to establish maximum benefit for both parties engages in negotiation, that isn't scalable, because not only are there are fewer constraints governing how these negations take place but the outcome isn't guarantee to develop a relationship that contributes to overall cooperation in a maximal way. It is an N to N connected graph.

However if you model the negotiation such that the 'joining' agent adopts a position seeking maximal benefit, while the 'already joined' agent (who represents the interests of the community in this process) adopts the position of constraining the negotiation to seek maximal group benefit, not only do you make for more scalable negotiations but according to Nash equilibrium, your result provably provides maximum group benefit.

Why would the 'already joined' agent argue for maximum group benefit? Because that agent already had the opportunity to seek maximum self interest when it joined, and now it simply wants to preserve the benefit it already negotiated.

Another benefit of this strategy is that if you have a situation where where you have concurrent development of groups, you can model group to group negotiation the same way where the joining agent is the smaller group, and the already joined agent is the larger group, so the smaller group would seek to maximize self interest (its benefit) and the larger group would constrain negotiations to concede only what would maximally benefit to the group itself.

You could have agents joining groups, and subgroups forming metagroups until you have an entire population in a nash equilibrium, which you can prove provides maximum benefit to the entire population. For scalability, negotiation taxes your resources only as long as two agents/groups are engaged in it. Once an agreement is reached negotiation ceases, and you get all of this with one model of negotiation that works for both autonomous agents and subgroups.

How is this different than the development of corporations from individuals and the development of alliances from corporations? Again, the key here is to model Nash equilibrium.

Just a suggestion.

Skaarl
Posted - 2010.09.01 19:49:00 - [208]
 

after dealing with the god awful lag which gets worse and worse i would suggest CCP quit spinning how they will eventually dedicate resources to figuring out what happened and spamming out more and more broken, crap quality upgrades and focus on fixing core issues with mechanics of the game like being able to actually being able to oh i dont know, control a ship or log in withing 20 jumps of a 10v10 fight. or you wont have any custoemrs left when you get around to actually trying to look at it. for gods sake its been a year since you put out dominion, and now your talking about yet another god awful,. poorly tested expansion? seriously?

fix your ****.


Pages: 1 2 3 4 5 6 [7]

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