EVE Search - How about putting null-sec on a separate shard?

All Channels

EVE General Discussion

How about putting null-sec on a separate shard?

» Click here to find additional results for this topic using Google

Monitor this thread via RSS [?]

Pages: 1 [2] :: one page
Author	Thread Statistics \| Show CCP posts - 0 post(s)
Captain Yifan Shadows Of The Requiem Controlled Chaos	Posted - 2010.07.30 15:45:00 - [31] All we need is more hamsters. We can gatecamp Blizaard and force them to hand over some of their WoW hamsters to work on EvE servers.
Yodabunny Gallente	Posted - 2010.07.30 15:46:00 - [32] An example of an issue with breaking up systems into grid/core. Fighters and Drones. You now occupy more than one grid. When you die your fighters have to stop shooting, immediately. If your fighters are in another grid and their firing calculations are happening on another cpu at the same time you blow up, what happened first?
Ishina Fel Caldari Terra Incognita Black Star Alliance	Posted - 2010.07.30 15:58:00 - [33] Originally by: Yodabunny An example of an issue with breaking up systems into grid/core. Fighters and Drones. You now occupy more than one grid. When you die your fighters have to stop shooting, immediately. If your fighters are in another grid and their firing calculations are happening on another cpu at the same time you blow up, what happened first? Meh. Even when orbiting my ship, my drones take 3-4 seconds to react to an order Signature? What signature?
John Ellsworth Gallente	Posted - 2010.07.30 16:08:00 - [34] Originally by: Aessoroz WTH is a shard? Also tranquility is already ran by many servers and the solar systems are distributed across the servers to even the load. a shard is from UO it means a separate server , what the op doesn't understand about eve is it separated by "nodes of servers" that are "connected" into one huge real-time server... as for individual lag in a certain node? report it and move on is about all you can do as a player... GL
Joe Skellington Minmatar JOKAS Industries Independent Faction	Posted - 2010.07.30 17:56:00 - [35] Edited by: Joe Skellington on 30/07/2010 17:56:40 All you armchair developers should apply for a job at CCP, so you can fix it.
Ioci Gallente Morrigna Order	Posted - 2010.07.30 18:03:00 - [36] Originally by: Yuki Kulotsuki Originally by: Ioci stuff No. That's wrong. There's no dynamic allocation because CCP don't want the overhead of running a hypervisor. They're using maximum resources on stressed nodes and don't want to decrease the ability of those nodes by running extra stuff on top. The current state of the art hardware isn't much better than what CCP already have. Processor speeds haven't increased like we were promised and the code is not capable of taking advantage of parallel processing. You also seem to be confusing graphical lag which is client side only with the big crushing issue of server side lag. The black screen is a server side issue. Module lag is a server side issue. There's a reason that CCP is developing thin clients that can be run in multiple instances on a single computer and log into the test server for "fleet fight in can". It's to stress the server, not the client. CCP isnt developing 'thin' clients though. They were but around a year ago, the EvE client went from a 600 MB to 5 GB download. I play mulitple clients in Windows mode and I get black screen all the time. EvE(Not responding) I know, thats not the same thing you are talking about. What I am saying is maybe they are looking at the wrong things? Client instability and lagg in the client creates black screening too. I used to be able to run 4 clients and not see black screening and client Not responding. Now it happens with two clients and its wierd requests like market or information on an Item that do it. Example, I do a show info on some named loot while in combat to see what the meta level is, black screen. I dont know what they did to create the current lagg. Neither do they, thats the thing. To assume this is all thier servers? To dismiss client side? That would be foolish of them.
Zeba Minmatar Honourable East India Trading Company	Posted - 2010.07.30 18:06:00 - [37] Originally by: Joe Skellington All you armchair developers should apply for a job at CCP, so you can fix it. You don't need to be an eve developer to get them to fix general day to day lag in nullsec. You simply need to refocus all this fleet fight rage into getting ccp to seed additional servers in each region so that when half of someones corp logs in to idle or form up for a fight it doesn't lag out your system that is 15 jumps away with 2 ratters and a miner in it. As it stands there are probably less total servers running all of nullsec than there are in just the few major trade and mission hubs. That is what is lagging you all out and not the borked code that messes up fleet fights. Originally by: Balsak Eve-Online, the game that is so awesome people are willing to give CCP money so that they may have the privilege to bash it.
SupaKudoRio	Posted - 2010.07.30 18:09:00 - [38] Fun fact: EVE is already sharded. It's just that all the shards are connected into a central database and are accessed through a single login pipe, which gives the illusion of a single shard server. Ye'llo?
Yuki Kulotsuki	Posted - 2010.07.30 18:13:00 - [39] Originally by: Ioci CCP isnt developing 'thin' clients though. Derp. The crippling lag is server side. Client side lag exists but it's not the thing that causes fleets to be lost with no one at the controls. Originally by: CCP Lemur THIS IS GOD: ... IF YOU HAVE ANY MORE REQUESTS I'M AVAILABLE SUNDAY FROM 10:30 TO 12:00 TO RECEIVE YOUR PRAYERS.
nu artiste Gallente Metalworks Majesta Empire	Posted - 2010.07.30 18:40:00 - [40] Originally by: Riley Moore They really need to get their code in line with parallel processing, getting to properly use multi cores would kickass, as well as making use of GPU's to do additional processing (have you seen how much raw power a GPU can bring if used right compared to a CPU?). I think CCP's main issue is that the original devs are long gone, and no one who still works there understands the very base of the entire code structure. So all they can do is add new code layers on top, so to speak. they totally need to give up windows if they haven't already maybe CCP can use linux, or sun OS or whatever is there to use hardware more efficiently.
Seishi Maru Organization for Nuclear Research	Posted - 2010.07.30 19:53:00 - [41] Anyone that thinks that collision detection of game physiscs are hard to parallelize has very low real knowledge on the field. Those tasks are easy to parallelize. Collision detection is done in hierarchical model that can dispatch diferent branches of the hierarchy to each processing node resulting in collision sets that are compared to each other on a final pass. EXTREMELY easy to implement with a VERY high degree of parallelism. Simple code to make collision detection parallelized. Prune and sweep on the 3 axis with a different thread ordering the objects on the 3 different axis. The result are grouping with crossign boundaries on that axis. Each group on the first axis can then trigger a different task on an independent thread to look for intersection on the other 2 lists that do not need to be changed (therefore no atomicity conflicts). THe resulting comapres will result in a second set of intersections. That set trigger tasks for each member on the set to comapre against the grouping of the first stage on the 3rd axis. Only the final results that match on the 3 axis need to go to a more refined collision test. EASILY you can spit 3 or more processors with very easily balanced work with that EXTREMELY simple approach. And ANY computer scientist that studied collision detection should know that. No 2 threads have race conditions or concomitant read and writing on the same data. I have done that even BEFORE I graduated in computer sciences 10 years ago. The problem CCP likely faces with parallelism is.. python is far from being good for that due to the way its reference countign works ( Altough I don know much about the special python CCP uses)
Yuki Kulotsuki	Posted - 2010.07.30 20:29:00 - [42] Originally by: Seishi Maru Parallel Collision detection An individual collision detection test can be parallelized. I'm pretty sure CCP's problem has more to do with scaling interactions collision based or otherwise. It's when these interactions are dependent on previous ones that this problem occurs. Things like damage which needs to make sure what you're applying it to still exists. An exponential problem. Never mind that stackless python is tied to a single CPU because of the global interpreter lock. I am curious about cheap parallel collision detection though. How well does it scale for n-many interactions? Originally by: CCP Lemur THIS IS GOD: ... IF YOU HAVE ANY MORE REQUESTS I'M AVAILABLE SUNDAY FROM 10:30 TO 12:00 TO RECEIVE YOUR PRAYERS.
Stick Cult Unspoken Autonomy.	Posted - 2010.07.30 20:37:00 - [43] Originally by: SupaKudoRio Fun fact: EVE is already sharded. It's just that all the shards are connected into a central database and are accessed through a single login pipe, which gives the illusion of a single shard server. You're an idiot. Stop talking. Now. Eve has nodes, which are the individual machines that make up the Tranquility cluster (Or Singularity, or Serenity, etc). Each node has something like a region, or a smaller area (maybe a constellation or two). If Eve were sharded, we could have 5 copies of The Forge, which were the same in the static things (geography, stations, npc everything), but different sets of players. Eve has no shards. It has nodes. Originally by: CCP Tuxford my bad. Rest assured I'm being ridiculed by my co-workers.
Xeross155 Minmatar NED-Clan Goonswarm Federation	Posted - 2010.07.30 20:55:00 - [44] From what I understand stackless python can run it's tasklets or whatever it calls them across multiple CPUs so unless we get CCP to confirm most of the CPUs are underutilized we are just guessing. And I highly doubt CCP is running CPUs at 5+Ghz but it is possible with some overclocking. [/serious] Also if they set up some mainframes that would be some serious nodes for fleet fights :) --------------------------------------------- Xeross' ventures into EVE
Yuki Kulotsuki	Posted - 2010.07.30 21:05:00 - [45] Originally by: Xeross155 From what I understand stackless python can run it's tasklets or whatever it calls them across multiple CPUs so unless we get CCP to confirm most of the CPUs are underutilized we are just guessing. Everything I've read points to the contrary; that stackless is still bound by the GIL. That's one of the reasons sol nodes are stuck on a single core. Originally by: CCP Lemur THIS IS GOD: ... IF YOU HAVE ANY MORE REQUESTS I'M AVAILABLE SUNDAY FROM 10:30 TO 12:00 TO RECEIVE YOUR PRAYERS.
Dr Slaughter Minmatar Forsaken Legions Mordus Angels	Posted - 2010.07.30 22:57:00 - [46] These threads have been done to death. A recent one which recently went, very computer science heavy, can be found elsewhere
Seishi Maru Organization for Nuclear Research	Posted - 2010.07.31 00:44:00 - [47] Originally by: Yuki Kulotsuki Originally by: Seishi Maru Parallel Collision detection An individual collision detection test can be parallelized. I'm pretty sure CCP's problem has more to do with scaling interactions collision based or otherwise. It's when these interactions are dependent on previous ones that this problem occurs. Things like damage which needs to make sure what you're applying it to still exists. An exponential problem. Never mind that stackless python is tied to a single CPU because of the global interpreter lock. I am curious about cheap parallel collision detection though. How well does it scale for n-many interactions? That model of implementation scales very well as long as most of things are not colliding. And that is true most of time in eve. In a fleet battle you might have 500 ships of which 30-40 are colliding at same time. The complexity of the collision and the application fop the collision effect can be parallelized quite a lot also as long as you do not expect hard constratnts. Sicne the collision in eve has never been hard constrained (you first enter the other object to then be expelled) this is not a huge problem. After that algortihm is applied you end up with a list of little groups of possible coledees (That might have 2 or more members on a single group) each group can be solved individually and the push force applied individually. At next tick if that force pushed it inside another object that was not in the collision, then the collision detection will reiterate over it. As I said it works well as long as you have a collision system as in eve when things can first penetrate to then be adjusted. The complete transversal of one object trough other in a single tick can be covered by performing the sweep on the bounding volume of the trajectory of the objects. The whole secret of thing is that in eve the absolute majority of time nothing will be colliding with anything, so you need an algorythim very focus on simple linear early rejects. Also this algorithm can explore spacial/temporal coherence quite well by not recreatign the lists all ticks, just adjusting its values and boundaries. But on overall yes, for parallelization, python might be a rock on CCP's shoe.
Jack Gilligan Caldari 1st Cavalry Division Circle-Of-Two	Posted - 2010.07.31 00:47:00 - [48] I don't think sharding this game would fix the problems at this point. A 100 vs 100 fight in a system would cause the same problem if we had 10 servers or just one. There is a defect in the current game code, the solution is a software fix, not hardware.
Omara Otawan	Posted - 2010.07.31 01:19:00 - [49] Edited by: Omara Otawan on 31/07/2010 01:20:42 Originally by: Kuar Z'thain Next time ask the hardware guys what they think of your programmer's wonderful idea of code that will require faster and faster processors with the more users you have on the system. They'll prolly tell you it is an inevitable issue anyway. Seriously, more lines of code being run on the same cpu will always mean more cpu power being needed. So more players means more cpu needed, no way to code around that problem. There might be ways to optimize certain routines (and this seems to be already being done for things that increase cpu load non-linear, see directional scanner "nerf" for example), but the general issue will always persist.
Yuki Kulotsuki	Posted - 2010.07.31 01:58:00 - [50] Originally by: Omara Otawan Edit: If all the people posting in these threads would actually participate in the mass tests, the fix would be a lot closer already. Before you can try to fix a bug you have to reproduce it properly after all. I'd love to help test. But working 9-5 at GMT-7 does not work out very well. I can get away with forum posting. Running a game client... not so much. So instead I follow discussions on the server architecture rather closely because it's interesting and chip in when people start from wrong assumptions (like client side lag). Originally by: CCP Lemur THIS IS GOD: ... IF YOU HAVE ANY MORE REQUESTS I'M AVAILABLE SUNDAY FROM 10:30 TO 12:00 TO RECEIVE YOUR PRAYERS.
Jack Gilligan Caldari 1st Cavalry Division Circle-Of-Two	Posted - 2010.07.31 04:19:00 - [51] Originally by: Kuar Z'thain CCP bet on processor speeds constantly increasing... And lost. Next time ask the hardware guys what they think of your programmer's wonderful idea of code that will require faster and faster processors with the more users you have on the system. There's a reason we don't have 4+ GHz CPUs and you should have seen the writing on the wall back in 2000. Were you guys praying cooling solutions would get better or what? Oh well, hindsight 20/20 and all that. Actually, the worst mistake CCP has made is running their server on Windows. Windows sucks. The last efficient OS Microsoft made was called DOS. Seriously, any variety of unix or linux would be better. Indeed, CCP should custom compile and make their OWN variety of it for their server. And why the hell are they using Microsoft SQL? It's only the most inefficient SQL server commonly used. My point is, only **** poor software people blame hardware rather than their crappy software implementation.
Tres Farmer Gallente Federation Intelligence Service	Posted - 2010.07.31 04:50:00 - [52] Originally by: Dr Slaughter These threads have been done to death. A recent one which recently went, very computer science heavy, can be found CCP Warlock (Jacky Mallett) vs LAG and MMO Scaling Nice read, thanks for the link Dr. Slaughter.. way better than most of the things you read in this thread here. Also thanks to the guys over there posting/discussing this!
Liranan H A V O C Against ALL Authorities	Posted - 2010.07.31 05:00:00 - [53] Edited by: Liranan on 31/07/2010 05:03:13 This isn't a problem encountered in just EVE, it's a software wide issue which needs resolving, otherwise PC's will get stuck in this hole. Fortunately AMD and Intel are working on this, as they share technologies openly with eachother, because Intels 80 core CPU is useless unless bits can be calculated simultaneously over multiple cores and then put back together in cache or in other ways. This is the result of Larabee and the future of AMD's Fusion/Firestream program. While CCP have really messed the code up, because problems weren't this bad during Dominion, it does come down, at the end of the line, to a hardware/software limitation. It will be solved, of course, but the question is when. One solution is the neuron CPU's being worked on but they're decades away. Hopefully this will get solved sooner or later and not just for EVE, imagine the future of computing when everything truly runs in parallel, Skynet will be a reality then... oh **... run for cover! Edit: I'm not making excuses for CCP because I want to go back to the days when we had 1800 in local fighting and not lag out when there're only 40 on grid, with 30s module lag. For those not participating in fleet fights: if you lag so badly with so few imagine what it's like when there're 200 shooting eachother and you will understand why we just can't have 800 man fights any longer. Farjung is my God** You people need to open your eyes and read threads before you mindlessly spam the New Thread link.

Pages: 1 [2] :: one page
First page \| Previous page \| Next page \| Last page

COPYRIGHT NOTICE
EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. CCP hf. has granted permission to EVE-Search.com to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-Search.com. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.