open All Channels
seplocked EVE Information Portal
blankseplocked New Dev Blog: Fostering meaningful human interaction, through testing
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: 1 2 3 4 5 [6]

Author Topic

Bartholomeus Crane
Gallente
The Crane Family
Posted - 2010.08.19 14:38:00 - [151]
 

I know you have been working on such mechanisms, but in addition to the usual criticism of "Bit late in the day, innit?", this is also something that is central to distributed computing as I define it. If partitioning the problem-space is central, you also have to have mechanisms to put those partitions to where they can be run efficiently. As such, there are many, many mechanisms to do that explored in distributed computing (with an under-emphasis in the connectionist view in my opinion).

I'll try to give an example. Take a node running a couple of SOL systems. With a load-balancing mechanism like this, if a single SOL system gets hammered, you can either move it to another node, or, if more appropriate, move the other SOL systems to other nodes. There are many methods to decide what to move where, but given my AI background, I'm a strong advocate of learning classifier systems here, as the collection of these systems eventually provide a learnt model of the load of the system, which (eventually) provides for more derived insight (no more log staring) while, if implemented correctly, approximating optimal behaviour (in real-time: DDDAS here). And there are quite a number of interesting boundaries on what a Collective Intelligence can and can not do.

But, in the end, this will only buy you time. Hopefully enough time to look at the functional entities themselves. The easiest step is to partition away integrated functionalities that aren't closely coupled. You mentioned that local chat is connected to SOL systems. It might be possible to separate those two, quite distinct, functionalities and move one away from the other if needed. Chat, for all the smacking it facilitates, is not time-critical (no one will lose sleep over a slight delay in the order of magnitude available on a well-connected cluster). But this is just reducing the granularity of the problem, and not necessarily a distributed computing thing.

In the end, and I have still no idea how pressing this really is, especially given the possibilities above, you'll have look at partitioning the (reduced) functionality entities themselves, and distributing them over multiple cores/nodes.

For example, you may end up partitioning SOL systems, meaning the 'in space' bit themselves. Again, distributed computing can provide a whole slew of paradigms, methods, and ideas there. You could partition over location for example, move one grid in a SOL system to one node, and the others to another, using basically the same mechanisms as above. Personally that I think that will only get you so far as big fleet fights are the problem, and they have a tendency to all happen on one grid. Also, ships warping from one grid to another means moving them from one core/node to another, and that necessitates a limited session-change (contact switch if you will), which will introduce problems of their own. Not to mention all the different ways of ships on one grid interacting with ships on another grid, and the inter-node communication problems that may entail.

But the location-based example is evocative, and easy to explain. I doubt it will work, because it might introduce more problems than it may solve, but it is not the only solution in the distributed computing toolbox. Because, you may not be aware, there is this field of distributed agent-based computing that basically focusses on exactly these types of problems. If you want, you can call it distributed virtual-world computing, I hear it is quite in vogue across the pond now (brings in the defence contracts I hear), and we've been theorising, solving, and implementing these types of problems for a while now in various ways.

But the point of all this, and the one I was trying to make earlier, that it is fine to look at distributed computing from a connectionist viewpoint, but that tends to under-emphasise what the computationalists can bring to the table. And I think that practically, there is still a lot to gain there ...

Rakessh
Bat Country
Goonswarm Federation
Posted - 2010.08.19 22:59:00 - [152]
 

You sound a bit like Richard Bartle Shocked

Bartholomeus Crane
Gallente
The Crane Family
Posted - 2010.08.20 00:43:00 - [153]
 

Originally by: Rakessh
You sound a bit like Richard Bartle Shocked


# look
> Although it is pitch dark, you see a person that is clearly not Richard Bartle. Still, you are likely to be eaten by a grue.

# look
> Well, now you did it, you have been eaten by a grue. Happy now? Rolling Eyes

CCP Warlock

Posted - 2010.08.20 13:42:00 - [154]
 

Originally by: Bartholomeus Crane
Well, that is the connectionist view of distributed computing. Not that I dismiss that view of distributed computing, but in my view it over-emphasises the importance of communication in distributed computing, and, following Information Theory in that respect, it tends to neglect the importance of partitioning the problem-space and the computational aspect of that. In my view, while communication still plays an important role in distributed computing because its various methods provide constraints on how, what, and where to partition, the fact that processes communicate, on its own, is not a, or the sole, qualifier for calling something a distributed program. In my opinion, therefore, the Wikipedia definition of distributed computing is too broad, not restrictive enough.



A distinct challenge of working in distributed computing is being able to hold two (or more) sometimes contradictory ideas at the same time. I agree it is just as big a mistake to say "mere computation" as it is to say "mere communication". Without
computation there is obviously no system, because nothing is being done. But while there can still be computation on a single machine without communication, there cannot be communication without computation, so Wikipedia can be trusted here. The critical design question is which is the bottleneck for this particular instance of the problem, and usually the follow on question is and where did i just move it? (There's a decided element of whack-a-mole to a lot of this.)

The short answer is, it depends. It depends on the number of computational elements in the system, it depends on their individual computational speed, network latency, bandwidth, and the induced computational latency that messages trigger. It depends on the interaction of all these, and they can all change between applications, hardware, and also historically. Fibre-optic networking removed the network as the bottleneck for a large class of applications, so the emphasis on communication in these systems has been lost over the last decade, at least for the smaller, simpler ones. That didn't mean it went away for the large systems like Eve and the other MMO's.

With that many things that can be varied, it's also not at all surprising that there are so many debates within the subject, especially as the expression of thought through language is inherently sequential, and that is the one thing that distributed computing most definitely is not.

Most importantly, the decision on how and when to partition, and how to distribute computation cannot be made, in the limit, without knowledge of the communication constraints within that computation. There is a general issue within the field though, which was one of the points I was trying to make in the presentation, that there is an area on the constraint curve, where communication limits don't matter, because the application cannot reach them. As long as the application is in the sweet spot on the left hand side of the graph, you are in a nice little zone, where everything works, and can stay blissfully unaware of the limitations that communication impose. As a design point I would also say, if at all possible, try to stay there. Interesting as I find the larger systems, they are orders of magnitude more complex to design and build, and engineering complexity should not be sought out, simply for the sake of it.

Originally by: Bartholomeus Crane

But it is true that at different levels of abstraction you can call a system either monolithic or distributed according to the various definitions of what a distributed system is supposed to be. Looking at the whole architecture,
then yes, you can argue that most systems are monolithic, but then what have we gained in insight into those system
s when we do that?


A similar insight to the one Einstein offered when he said "No problem can be solved from the same level of consciousness that created it".

... continued

CCP Warlock

Posted - 2010.08.20 14:27:00 - [155]
 

Originally by: Bartholomeus Crane

<snip...>
Instead, I think it is more worthwhile to take the architecture as a given, see the communication problems, I suspect you're dealing with now, as a given useful application of the divide and conquer paradigm, and instead consider what distributed computing can provide for individual functional entities. And on that level of abstraction, I think it safe to assume that none of the functional entities is distributed.


I'm afraid that would be an incorrect assumption.

Originally by: Bartholomeus Crane

That may sound picky, or trying to be right regardless, but that's not the reason I want to do this. The reason is that distributed computing can provide a lot of things if we look at the architecture as a collection of monolithic processes.

One thing we can do is apply divide and conquer on the efficacy problem. That is to say, assuming that the communication layer is working correctly, we can ignore a lot of those functional entities because they do not constitute a bottleneck. Not really a distributed computing thing, but we've reduced the overall problem (getting better or any performance) a lot with that. Then we can address things on the architectural and the functional level.


No it's quite a valid observation, it's just not particularly valid for Eve, and when it is, there are good reasons for it.

The database btw., is the single area where you are quite correct, and is a potential long term bottleneck. An easily solvable one if we hit it though, and we gain considerable development speed from using it the way we do. We also put a lot of work into not using it, and are very efficient in both our caching strategies and in the load we put on it. It's something we have to be continuously careful with, and it is monitored extremely carefully by the DB team.

However, communication speeds, or latency do play a very key role in what we can and cannot distribute in some key areas, especially fleet fights.

Originally by: Bartholomeus Crane

For one, the static setup distribution is a restriction. If dynamic movement of the functional entities to computational resources were possible, we've not only increased the utilisation of the available resources a lot, but probably moved the scalability goalposts a lot.


We prefer to think of it as dynamic with a 1 day latency. It's not that we can't change the distribution at all, and it's being monitored all the time. However, making it truly dynamic is a work in progress. It will be useful in some areas, and certainly the inability to move SOLs around is important, but probably not as much as you suggest. Like many similar systems, Eve's load profile is surprisingly undynamic in many respects. We do see load shifting around the Eve Universe over time in response to player activities and territorial shifts, but this is proportionately slow.


CCP Warlock

Posted - 2010.08.20 14:47:00 - [156]
 

Originally by: Bartholomeus Crane

I'll try to give an example. Take a node running a couple of SOL systems. With a load-balancing mechanism like this, if a single SOL system gets hammered, you can either move it to another node, or, if more appropriate, move the other SOL systems to other nodes. There are many methods to decide what to move where, but given my AI background, I'm a strong advocate of learning classifier systems here, as the collection of these systems eventually provide a learnt model of the load of the system, which (eventually) provides for more derived insight (no more log staring) while, if implemented correctly, approximating optimal behaviour (in real-time: DDDAS here). And there are quite a number of interesting boundaries on what a Collective Intelligence can and can not do.


Just to clarify, physical communication constraints (bandwidth etc.) are not an issue at the moment anywhere in the cluster. Rather it is the induced computation time by messaging, and the corresponding latency it introduces that creates the issues. They're still communication related - this is where a good understanding of Information theory is extremely useful - but not necessarily in the TCP sense most people think of.

Work on dynamic load balancing is in progress. Code book methods such as you suggest are well known (in networking at least), ways to shift load by pre-distributing computational results. Eve already does a lot of that, the client simulation is effectively running in lock step with the servers and maintains state over time with remarkably little communication, modulo the occasional desync problems. There are certainly optimisations that can be done based on predictability, and with games we have the additional luxury that we can also design to try and create predictability. However, that leads us to the other element in all of this, the human factor.
Originally by: Bartholomeus Crane

But, in the end, this will only buy you time. Hopefully enough time to look at the functional entities themselves. The easiest step is to partition away integrated functionalities that aren't closely coupled. You mentioned that local chat is connected to SOL systems. It might be possible to separate those two, quite distinct, functionalities and move one away from the other if needed. Chat, for all the smacking it facilitates, is not time-critical (no one will lose sleep over a slight delay in the order of magnitude available on a well-connected cluster). But this is just reducing the granularity of the problem, and not necessarily a distributed computing thing.


When players are flying in a system, several physical nodes are actually involved in providing the game play, as well as the SOL server which is providing the real time simulation. You're quite rightly asking why we don't distribute that more.

Communication latency within today's data centre's is O(0.5ms). Communication latency on a multi-core system, through memory is O(100ns). In addition, the internal communication requirements within the SOL simulation are not insignificant, so if this were split over two physical nodes, it would be considerably more than one message going back and forward. The upshot of this, is that if you do try to split something like a real time fleet fight over multiple servers, the "join" as it were, where the servers overlap or meet, will be noticeable to the players. Now it is the holy grail of MMO systems to create systems that will do this, and there has been some success with lightly loaded situations, depending on the actual communication latency requirements of the underlying computation, but not much.

The issue is, if it is noticeable to the players, it can and will be exploited, sometimes with accompanying YouTube videos. This is a very large problem - well the player experience part - the videos are great. Players will create and use lag as a game mechanic.

...continued

CCP Warlock

Posted - 2010.08.20 15:12:00 - [157]
 

Originally by: Bartholomeus Crane

But the location-based example is evocative, and easy to explain. I doubt it will work, because it might introduce more problems than it may solve, but it is not the only solution in the distributed computing toolbox. Because, you may not be aware, there is this field of distributed agent-based computing that basically focusses on exactly these types of problems. If you want, you can call it distributed virtual-world computing, I hear it is quite in vogue across the pond now (brings in the defence contracts I hear), and we've been theorising, solving, and implementing these types of problems for a while now in various ways.


Yes, much of the impetus for network development that didn't come from the financial sector, came from the military, either in sensor networks or in the large scale real time conflict simulations, and those go back a long time. As you might imagine from the title of my thesis, I'm not unfamiliar with the work there.

Agent-based computing is certainly an interesting field, but most of the work is still simulation. The problem with simulations is that they very rarely tell you things you didn't build into the simulation. The problem with many agent-based simulations at present is that they're often not real-time and they either ignore network effects completely, or they are still using relatively low numbers of communicating agents. Consequently, they are often on the left hand side of the graph and haven't hit the hard limits yet. It's a very real problem - both for the people doing the work, since it's extremely hard to simulate these things - and also for the analysis that comes out from that work.

With today's hardware too, a "low number of agents" can be extremely large for some applications - the information space boundary between non-constrained and constrained systems is very application dependent. It was purely serendipitous that I hit it, since the work I was doing involved relatively low numbers of robots.
Originally by: Bartholomeus Crane

For example, you may end up partitioning SOL systems, meaning the 'in space' bit themselves. Again, distributed computing can provide a whole slew of paradigms, methods, and ideas there. You could partition over location for example, move one grid in a SOL system to one node, and the others to another, using basically the same mechanisms as above. Personally that I think that will only get you so far as big fleet fights are the problem, and they have a tendency to all happen on one grid. Also, ships warping from one grid to another means moving them from one core/node to another, and that necessitates a limited session-change (contact switch if you will), which will introduce problems of their own. Not to mention all the different ways of
But the point of all this, and the one I was trying to make earlier, that it is fine to look at distributed computing from a connectionist viewpoint, but that tends to under-emphasise what the computationalists can bring to the table. And I think that practically, there is still a lot to gain there ...


Certainly going multi-core will help - we're going to have to sneak around python a little there - and we can forsee that in the immediate future, hardware servers will be scaled to larger numbers of processors. However, communication constraints don't go away there either, the limits just hit a little later, which is also a reflection of the granularity points you were making earlier.

In summary, we look at everything, and don't discard anything that will bring better performance. Distributed computing, and this is why I enjoy it, at these scales requires every single trick in the computational science box that is available and then usually a few more.

And this has ended up being another wall of text - sorry - I failed art at school Smile

Camios
Minmatar
Sebiestor Tribe
Posted - 2010.08.20 16:42:00 - [158]
 

Edited by: Camios on 20/08/2010 16:59:39
While I find all this very interesting, I am not a tech guy, so I see things from a different point of view.
The average EVE player does not know much about EVE cluster technology, but he plays the game, and he can understand far better a discussion about game design.
This does not mean that every EVE player has a game mechanic solution to performance problems, but this is a ground we can actually discuss about.
Moreover, even you stated that without game design work EVE will always be affected by performance issues.

So, while I actually believe that the Tech gals and guys at CCP are epic, I don't see why CCP management didn't put a parallel game design effort to fix lag with gameplay changes.
Maybe in 18 months?


When discussing game design with players, extremely violent reactions and emorage can happen, epicly stupid or naive ideas can be expressed, while technology is usually a more neutral ground.

The matter of game theory is really complicated but CCP game designer should not be afraid of facing it periodically until this game is fixed.

If you don't want to discuss this sensible topic with your playerbase, do it internally, and fix the sov mechanic. The problem of designing a sov system that is "player proof" (in the sense that player will not overload your server while fighting) can be solved only exploring all the possible paths that players can follow, and this can efficiently be done with massive brainstorming sessions ([self advertisement]player posted threads like this can help you [self advertisement]).

For example, now it is not wise for the attacker to attack 2 systems at once if the attacker login time vs defender login time ratio is less than 5 (aka "the attacker must win 5 battles while the defender has to win just one"). And with current mechanic, attacking 2 different solar systems does not automatically mean that there will be 2 little, lag bearable battles at the same time, but maybe 2 large battles crippled by lag.

Of course, it could be great if you find a way of fixing sov warfare that will fix pos warfare too. Yes, I like dreaming.
In other words, I see a game design fix as a premise to a technical fix, not the contrary.

Trebor Daehdoow
Gallente
Sane Industries Inc.
Posted - 2010.08.20 17:39:00 - [159]
 

Originally by: Camios
If you don't want to discuss this sensible topic with your playerbase, do it internally, and fix the sov mechanic. The problem of designing a sov system that is "player proof" (in the sense that player will not overload your server while fighting) can be solved only exploring all the possible paths that players can follow, and this can efficiently be done with massive brainstorming sessions ([self advertisement]player posted threads like this can help you [self advertisement]).

With complex issues like sov warfare (and game-design solutions for fleet lag for that matter), I feel that it is essential that CCP explore using player expert focus groups to tiger-team proposals. The blunt fact of the matter is, no matter how smart the CCP designers are, the law of large numbers guarantees that some of the players will be smart enough to find a way to game any non-trivial, non-boring mechanic they come up with. The real name of this game we love, after all, is Unexpected Consequences Online.

Having player-experts (who, after all, live in the game) compete to find the holes in the design before it gets implemented makes a whole lot of sense to me. And the price is right.

Bartholomeus Crane
Gallente
The Crane Family
Posted - 2010.08.20 17:41:00 - [160]
 

Perhaps at this point it is best if we lay some aspects of the overall discussion aside and move forward on the other aspects. Otherwise I see us crafting longer and longer replies while never descending from abstract level issues.

One prime example would be the communication-computation issue as I think we're close to, or at consensus there. It's a discussion that has been gone on for a long time in this field, with some preferring to camp-out on either side of the fence. I'm not among those some, and clearly neither are you. I brought up the distinction mostly because the blog, and the presentation focussed so strongly on the communications side that I felt the 'computational' side seemed to be ignored.

It also to much resembles a chicken-and-the-egg discussion. With one side claiming that communication constraints inform the computational decisions, and the other side claiming that the computational decisions determine the communication requirements or methods. Neither is inherently right or wrong but in practice the emphasis is dictated by the circumstances of the distributed problem itself. And since we both acknowledge this, there seems to be little left to disagree on. I for one don't feel called to defend to the hilt an extreme position which I don't really subscribe to. So, onwards?

That still leaves the communication focus with respect to the EVE server to discuss. As I said, it seemed to me, from the blog and the presentation, that there is an abundance of attention on this when it comes to the EVE server. That didn't come as a surprise as such, as, as I explained earlier, there seems to me so little application of the computational aspects of distributed computing applied the EVE server architecture (examples I gave such as dynamic load-balancing). But then came this:
Originally by: "CCP Warlock"
Originally by: "Bartholomeus Crane"
<snip...>
And on that level of abstraction [where the EVE server can be viewed as a collection of monolithic functional entities], I think it safe to assume that none of the functional entities is distributed.

I'm afraid that would be an incorrect assumption.

I can neither confirm nor deny that this is the case. I just don't know what the architecture looks like beyond the general description. I've already given examples why I don't consider that some seemingly distributed functional entities (the market acting as a partitioned cache to protect the central shared state memory) to be just that, but even that is based on assumptions. As such, I'm afraid I have to ask you to back up this statement, preferably with an example to make it concrete.

And while I whole-heartedly agree with the statement that engineering complexity shouldn't be sought out just for the sake of it, and that in that respect, the central shared state memory, when protected, shouldn't be replaced when there is still no requirement for it (in that respect I believe that demand should pull design, and not the other way round), and especially not while it still provides advantages, I doubt that this is the case when it comes to dynamic load-balancing on the architectural level (moving functional entities around the distributed resources).

Although calling the static architecture setup a load-balancing algorithm with a 1-day latency is certainly quaint, (mis)using the law of large numbers over the whole architecture to state that EVE load-profile is undynamic might go too far. Isn't this looking at the problem from too great a distance? I'd be very surprised if computational bottlenecks did not occur topically, while, averaged over the whole cluster, those spikes would fall away. Meanwhile, we've already established that players in EVE (or any MMO) are notoriously unpredictable and the 'flash-mob' behaviour of such 'crowds' is a well known phenomenon and problem in MMOs, virtual-worlds, and (distributed) agent-based simulations alike.

Continued ...

Bartholomeus Crane
Gallente
The Crane Family
Posted - 2010.08.20 18:22:00 - [161]
 

As such, the dynamic load-balancing mechanism isn't intended to increase the averaged utilisation of the distributed resources, although that is probably a welcome side-benefit, but to provide adequate resources for the topical resource bottlenecks that can, and probably (I think it is safe to say) occur. And for identifying the need for such a thing, an averaged metric over the whole cluster seems to me rather useless. In this respect I am not particularly interested in the movement of the load caused by groups of players over the 1-day latency timespan, but rather the bottleneck load created by groups of players interested in all gathering in one spot/system of the world (for example, to bash a SOV structure there). It is on that time-scale that I think that a dynamic load-balancing mechanism, either reactively, or, if possible (but more difficult) pro-actively, can provide a clear benefit from the player's point of view. Territorial shifts can also be handled through the same mechanism, but that is, to me, rather beside the point. And if this is true, you'll understand that I don't think a 1-day latency cuts it, or ever will. As such, I welcome that you are putting effort into bringing it about, but I'm now worried that you underestimate what it can provide, with the corresponding de-emphasis on the priority that comes with that.

And, just to be clear on the definition, when I'm talking about load-balancing, I'm not referring to offloading some of the load from the servers to the client (and only exchanging the delta when required) either. Although that is all well and good in its own right, to me that has next to nothing to do with load-balancing.

But obviously it is good to hear that communication is not the bottleneck within the EVE server. I always suspected that it was computational load that put constraints on the performance. Which is also why I'm inquiring after ways to distribute computational load at the cost of communnication expenses. After all, the one is in short supply (even if topically) while the other is in relative abundance.

With respect to the remarks on the partitioning of SOL systems themselves. Yes, you are quite right to assume that if the partitioning has an effect in the logical world (noticable to the players), this will be taken advantage off. I certainly would (if I knew how to 'game' the partitioning system). And by no means do I want to imply that this is an easy problem to solve, for which I can magically pull the answer from the bookshelf. But, am I correct to assume that the responses to the players are already 'synchronised', i.e., that there already exists a certain timestep, or tick, or frame mechanism against which the EVE server has to send back the response events to the player? A real-time response constraint, no doubt, but wouldn't that one be equally useful for synchronising the responses even if distributed over multiple cores? I ask because this is a technique we commonly use in distributed real-time agent-based (virtual-world) simulation (with all the predictive, roll-back, and other caveats required for adhering to the real-time requirements).

As for you view of distributed agent-based simulation I'm afraid that it may have held 5 to 10 years ago, and that yes, some still do work in that age, but that a large part of the research and discussion has clearly moved on from there. I mentioned Dynamic Data Driven Application Systems (DDDAS), which more often than not include (agent-based) simulations, and are practically all, almost by definition, systems with real-time requirements. As for simulations doing only what you put into them, that to is a far too restrictive view. I've worked on large distributed simulations driven by AI where no prediction was possible of even the possible actions (sequences), let alone the simulation outcomes themselves. And many of these systems are already beyond the hard limits you described.

Continued ...

Bartholomeus Crane
Gallente
The Crane Family
Posted - 2010.08.20 18:46:00 - [162]
 

Edited by: Bartholomeus Crane on 20/08/2010 18:53:55
So, in that respect, I can only say that strides really have been made in the distributed agent-based/virtual world simulation field that should be applicable directly, and in a practical sense, to the EVE server. I cannot help but wonder if there isn't a bit of "Yes, but we are special/different" thinking going on. The difference between, for example, virtual worlds, and distributed agent-based simulation isn't that great really, and is practically non-existent between MMOs and virtual worlds in many respects. All these fields, well not happily, but still, are working together on these problems, each feeding solutions and mechanisms into the the other. The underlying distributed computing systems, designed to support these programs, have followed suit with the demands placed on them. I can only warn in the strongest possible terms against exceptionalism in this regard. Each system has it's own requirements, and poses its own problems, but many solutions can be crossed-over or adapted between them. Ignorance of these methods, especially wilfully brought about, is negligence in my view as an academic. The problems simply are to difficult to stick to reinventing the wheel here ...

And finally, I'm glad that CCP recognises the things that at least multi-core computing can do. But it seems to me CCP only recognises the immediate future for the hardware. What I can't seem to get a handle on is if, or how, this will effect the immediate future of EVE, in particular, the EVE server. Certainly, stackless python has limitations there, which can and needs to be circumvented, but is there, to begin with, a medium to long term requirement for multi-core computation in the EVE-server, and what is the medium to long-term view from CCP on that? Has CCP identified functional components as bottlenecks that, eventually, can only be cleared through multi-core computing? Because I can assume that this is the case until I'm blue in the brain but if you guys aren't at thatstage yet, it will be pretty difficult to drill down to specific suggestions that might be considered there.

Camios
Minmatar
Sebiestor Tribe
Posted - 2010.08.20 22:44:00 - [163]
 

Edited by: Camios on 20/08/2010 22:51:01
Originally by: Trebor Daehdoow
The blunt fact of the matter is, no matter how smart the CCP designers are, the law of large numbers guarantees that some of the players will be smart enough to find a way to game any non-trivial, non-boring mechanic they come up with.


QFT. This is actually what I would have typed if I were a bit better at English. Thanks Trebor.

Quote:
but is there, to begin with, a medium to long term requirement for multi-core computation in the EVE-server, and what is the medium to long-term view from CCP on that? Has CCP identified functional components as bottlenecks that, eventually, can only be cleared through multi-core computing?


I support this question, if someone cares.

CCP Warlock

Posted - 2010.08.23 13:53:00 - [164]
 

Originally by: Camios
Edited by: Camios on 20/08/2010 22:51:01
Originally by: Trebor Daehdoow
The blunt fact of the matter is, no matter how smart the CCP designers are, the law of large numbers guarantees that some of the players will be smart enough to find a way to game any non-trivial, non-boring mechanic they come up with.


QFT. This is actually what I would have typed if I were a bit better at English. Thanks Trebor.

Quote:
but is there, to begin with, a medium to long term requirement for multi-core computation in the EVE-server, and what is the medium to long-term view from CCP on that? Has CCP identified functional components as bottlenecks that, eventually, can only be cleared through multi-core computing?


I support this question, if someone cares.


Applications like Eve require every single trick in the distributed computing box. So recruiting more processing using multi-core is certainly on the medium to long term list, and at the moment we are exploring how best to do it. The idea that all scaling problems can be solved by multi-core is unfortunately not correct, but seems to be one that every new generation of distributed computing programmers has to learn by itself, so I'll leave it at that. In the limit, and this has also been commented on above by the CSM, some of these issues will eventually have to be dealt with in game design.

CCP is itself a distributed system - we're always working on more than one thing at a time.

Shandir
Minmatar
Brutor Tribe
Posted - 2010.08.23 21:47:00 - [165]
 

Well, then at the same time as working on multi-core processing - you should try to work out how to get multiple brains per programmer head. I think radiation should do the trick.

zz01shagsme
Posted - 2010.08.24 15:11:00 - [166]
 

/me likes the bit about "You all have a say in how good or bad eve is". STFU Trolls...[points finger] at the lovely "Can I h'as yer stuff" comments...gotta love em Razz

PJRiddick
Gallente
Posted - 2010.08.25 11:39:00 - [167]
 

To Tanis:
Tanis, i read the bit about the upgrades to SISI.
bud, if you all want to see what Tranquility is gonna do with the present system in place,...set up the Jove system to be gotten into, and allow just the people that sigh up for testing to be able to jump into that part of EVE Tanaquility and do your testing there.
In that part of EVE, you have all the new hardware, and its part of the live service.
Just keep the groups down to a minumum.
On the next down time, jsut make sure that everyone is out of the area on the restart, Im sure that you can do that from the server side.
Just throwing my Two cents in bud. I dont know just how feasable that is.
fly safe
-=+>xXx<+=-

Zilnam Haa
Gallente
Posted - 2010.08.25 16:07:00 - [168]
 

Thanks to all the CCP Teams, CSM's and all the positive repliers in this thread. Very interesting reading indeed.

Did anybody think at game release Eve could/would become the "Entity" it is today? I am only a three year old player but reading this thread has put into prospective the love of the game, on BOTH sides, CCP and Players, compared to any other MMO out there.

My take so far on this thread, teamwork is a must.I will attempt to log on for the tests on SiSi and have participated in approx 4 so far. Hopefully moar players will follow.

Eve is a unique virtual world in the gaming community and I for one am impressed at both the work and time involved by all involved.

We will beat the Lag-Boogie Monster!

See you's on SiSi o7





Eventy One
Magellan Exploration and Survey
Mordus Angels
Posted - 2010.08.31 12:52:00 - [169]
 

Edited by: Eventy One on 31/08/2010 12:54:47
In terms of getting the proper number of participants, is lag testing too specific that those numbers can't be obtained on the production server?

What I'm thinking is that when your "Live Event's" runs Live Events, there alway seems to be hundreds of players who participate. I'm sure no one would mind you collecting data then.

The downside is that the specific test you'd want to run would have to be coordinated with the Live Event's storyline, (and wouldn't be so specifically contrived), but I guarantee you'll always have participation.

The Live Events are always a lot of fun, and engage massive numbers of players, so why not use them to collect data?


Manofearth
Posted - 2010.09.06 21:35:00 - [170]
 

I was hoping that the Mass Test would be 3 hrs later or on the weekend....i have several accounts that i could log in and help with the test.....

Stick Cult
Posted - 2010.09.09 22:07:00 - [171]
 

Originally by: CCP Zulu
Originally by: Stick Cult
I hate to be so annoying, but could someone from CCP answer what I said back in post #20, a simple yes or no is fine...
Quote:
(I've said this before, but I want to put it where it will be read by devs..) But, I'd settle for less. Following the 2 day downtime, we got 100k skillpoint pools. What about this: for every mass test you get some amount of skillpoints (2-5 million) on your Singularity account. It's enough so that players won't leave TQ so they can go fly their titans on the test server, but enough to encourage participation. In the end, you'd also end up with more people on the test server, which ultimately leads to ~more testing~, which is always a good thing. Can a dev say "no this will never happen" so I can stop talking about it?


That's an interesting suggestion. I'm going to forward it to those responsible for Singularity and see if they're OK with it.

I don't know if people even read this thread, or if I even had anything to do with this... But the 2 mil bonus on sisi for a mass test: I love you.

Lederstrumpf
Posted - 2010.09.24 20:24:00 - [172]
 

If I remember right you were asking for honest feedback, so here it comes: The more often I have a CCP person finger pointing at me asking me to join mass testing as it would make eliminating bugs easier the more I get ****ed.

Rereading Tanis' "what EVE players think of the quality of the game is a truly vital indicator about the overall quality of EVE that we cannot ignore" makes me wonder if he's talking gibberish into my face or whether you guys at CCP fail to properly harvest user opinion just because you didn't spend enough thought on how to use what you get best.

People are reporting Mac client crashes while stargate jumping for months now. And still it didn't even get officially acknowledged. Why should ANY Mac user, giving free feedback, receiving nothing in return (not even an ACK!), agree to the hassle of investing even more time to help you in any way when it comes to tests on Singularity?

You've got some very obvious single points of failure in your end user <-> developer communication chains, one of which seems to be not to be able to extract some nasty stuff from the forums in time. You seem to not care much about forum posts and bugtracker reports, "as there is mass testing" (which ****ed off highly qualified people will never attend, as all one expects is more hassle instead of some rewarding experience)?!

Bhattran
Posted - 2010.10.04 12:14:00 - [173]
 

The title of this thread makes me laugh considering how well the bugs reported were addressed in the latest patch.



Pages: 1 2 3 4 5 [6]

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