Two CCP players, CCP Atlas and CCP Warlock have been killed in the fight. As they have been using ships, which are not seeded on Transquility (BH cargo ship, which isnt recognized by killboards), the killmails cannot be uploaded properly, so the ibis km is modified.

CCP Atlas km:

16:17:31 Notify Sqees <-42->(Vagabond) has started trying to warp scramble “CCP Atlas <C C P>(BH Mega Cargo Ship)”

[16:22:41] CCP Atlas > that wasn’t very nice :'(

Its rumored that the corpse of CCP Atlas has been auctioned for 5 billion isk right away.

A emergency meeting has been held during the battle in a an attempt to save the node, and look into the lag that at most of the time made the system unplayable, yet alive. Jita nod was connected to the system as well in order to make it work. Most players were seriously surprised that the node didn´t crash and CCP reloading it. Both groups accused each other in tries to crash the node with logins and logoffs.

At some point CCP have closed the node to new log ins in LXQ. With 5+ CCP employees in local, it showed for the first time serious care by CCP in the game experience of their paying customers. Even as lag is still here and will stay, its first such big performance after Dominion patch, that has killed hopes of many for epic battles of this scale.

We all hope that the data collected by CCP will be much better than any halfserious tests on Singularity (Test server) and will further help clear the lag cloud once and for all. As such battles is the best advertising EVE can get, period.

[00:45:45] omgdutch2005 > Originally by: CCP ExplorerSome maximum numbers recorded during the fight:

Maximum CPU usage: 100%
Maximum memory: 7.5 GB
Maximum population: 3,242 pilots


  1. Lykouleon

    serious claps towards CCP for keeping that node alive

    October 31, 2010 at 8:51 am Reply
  2. TSharky

    I hope CCP will sort their shit out and do something, tired of those stupid posts they make about lag testing etc. and nothing changes after that. It could be one of the epic battles in eve if not lag. I jumped into system with my alt, grid was loading 30 minutes, then I heard sound of my hull. I was dying there for about 5 minutes, then I just decided to log 😀

    October 31, 2010 at 9:03 am Reply
  3. Someguy

    The NC had close to 2k in system and the Drone Russians tried to jump in at least 1200 more. The fact that nothing caught fire was fantastic. Being logged in and able to see some of what's going on around you is infinitely better then black screens. I'll take 20 minute module lag over 20 minute log on screen any day.

    Lets hope ccp has made a breakthrough and there's more and better soon to come.

    October 31, 2010 at 9:07 am Reply
  4. tsharky you are reta

    I mean seriously, if you are expecting 3,000 in local to work well, when it has never been close before, then you are retarded, how can you honestly complain about that? CCP deserves applause for calling a meeting, switching LXQ to the jita node, and getting 5 employees in there, even after they had to reship :).

    October 31, 2010 at 9:11 am Reply
  5. Argle

    CCP have done good lately. The lag felt about the same as in a fight we had back in may with 400 on an unreinforced node, maybe better.

    October 31, 2010 at 9:32 am Reply
  6. Blazde

    Should probably correct: It's not the *first* time certain CCP employees showed 'serious care'. They've been at quite a few late/weekend fights over the last few months but it's really cool that their efforts are showing good results, and for sure they deserve continuing props for it

    October 31, 2010 at 9:51 am Reply
  7. some guy in wtf that

    to be frank, as much as we malign ccp (and as much as they deserve it a fair amount of the time) simply keeping that node running is pretty damn impressive in my book. hopefully they got a lot of useful data from this single truest mass test 😀

    October 31, 2010 at 10:00 am Reply
  8. CoN

    Having worked with OS-calibration and some network load balancing, I'm a bit surprised by the slow, progress from CCP's side in this regard. The feeling is that they are running on a shoestring set-up or are not aware of which parameters to adjust. Most systems these days have paremeters that can be calibrated in order to insure the right [email protected] right time.

    I hope they can improve it further in the near future. Apart from some of the lag-issues I love EVE! 😉

    October 31, 2010 at 10:31 am Reply
  9. Dragan

    Good job CCP, even if there's still much to do/learn/improve

    October 31, 2010 at 10:46 am Reply
  10. Provipilot

    HAHA! I love Atlas' response to the warp scramble…

    October 31, 2010 at 10:48 am Reply
  11. Muhajay

    way to less nc losses in the whole fight.

    fucking russians are even to stupid to kill some carebears

    October 31, 2010 at 10:59 am Reply
  12. someone

    @CoN: Doesn't really matter if your code is single threaded :/

    October 31, 2010 at 11:47 am Reply
  13. Jeff

    "We all hope that the data collected by CCP will be much better than any halfserious tests on Singularity (Test server)"

    I too hope that the data CCP collected while they barely kept alive a system that two parties actively tried to break by heavily overloading it in any possible way will be better than the data they collected during their Mass Test Events where they prepared a System for data logging and where they set up scenarios with predictable loads to identify causes of lag.

    I also hope that the people who really care about CCP fixing the lag stop backseat programming and join said Mass Test Events more often.

    October 31, 2010 at 12:22 pm Reply
  14. Carlos

    @ Muhajay

    lol kinda funny, you try and be outnumbered 4 to 1 with inability to show grid etc. ITs not a case of lack of skill from the ruskies but more of the system capabilities. Anyone that has those odds and technical issues will loose. I am sure of the tables were turned the same would have happened to the NC. Bytherway, you think wayyyy to much of the NC. Time will teach you the error of your ways…

    October 31, 2010 at 12:32 pm Reply
  15. Thomas

    My hope is, seeing that 3000+ on one node was holding even with a fight (if you can call it that, i was not there), the more usual scale of a fight like 200 – 1000 in system in the future runs more smoothly then it has in the past months.

    Also props to CCP because i think we all noticed that those more usual fights got much better allready since about 1 or 2 months now. There is no way to get rid of lag forever as we are running all this on limited mashines no matter how advanced they are. I feel we are back to the status that we were in before Dominion when it comes to the usual numbers in system, so in my book CCP is on the right way again after it got really bad in Dominion

    October 31, 2010 at 12:46 pm Reply
  16. Provi resident

    Maybe it gave them some information but for the most part I dont think it did. Heres some major issues that cause the majority of the lag…

    1.) Drones.. every drone is another item on grid that everyone needs constant status of.. 5 drones flying with MWD is a lot of status update, not to mention the "AI" as it were on the node CPU. So we have network bandwith and CPU thats taken up.

    2.) Missiles.. again with status updates while their flying through space and then the "AI" for them to track a target. So more missiles (ungrouped missiles for the loss!) more CPU and more network bandwith being used.

    3.) AOE weapons. Items like bombs, smartbombs, and AE Ewar. Hitting multiple targets at once is a CPU hog. Not to bad on network but it is a big burst spike on network usage for a mass update.

    4.) Bookmarks.. no one knows why these things cause lag but they do… it appears to cause network lag from what I have seen.. maybe their mapping system is fubar so the coordinates for bookmarks are insane in size is about all i can think about.

    5.) Log ins, warp ins, jump ins.. anyone loading system causes a lot of information to be sent from the server to them.. Network lag majorly. Not much CPU wise tho individually.

    6.) Rats believe it or not.. not much here really.. they just take up some CPU and memory bandwith. This is where I am split on whether its better to have multiple rats with simple AI or just a few with complex AI. It would drop node CPU and memory by just a miniscule amount if they were to essentially turn rats of during large invasions/battles. Maybe 2-3%.

    All told this is why it makes it difficult for them to isolate what causes that much lag on the live server with no coordination. Without seeing how they thread their processes I couldnt speculate anymore on how they could isolate problem children down more. Needless to say if you can spread out the processes and threads the bigger the benefit of extra CPUs and CPU cores.

    October 31, 2010 at 12:48 pm Reply
  17. Drazi1

    @Jeff We knew that the DRF was gonna come in force, numbers we didn't know at the time. We didn't go there to intenionally crash the server, even though i did hear rumours that the DRF was trying to do so ( its not confirmed ). The state of eve atm is leaning towards huge blobs slugging it out.

    CCP did a good job of keeping the node alive, everything was ok until DRF jumped in, then the lag monster kicked in. The end result was the station being taken over and system sov taken from DRF.

    October 31, 2010 at 12:49 pm Reply
  18. some guy in wtf that

    even though i did hear rumours that the DRF was trying to do so ( its not confirmed )

    whether or not this is true doesnt even matter imo (i heard the same things, dunno how much stock to put in them though)

    the thing im really wondering is why when it became clear the node would hold the DRF didnt continue to try and contest the situation. to be frank i hold many of the drone regions forces and allies in high esteem, and even though they were outnumbered in that situation they could really have given us a run for our money, and even if they lost it would have left something to the number of 1700 NC pilots exhausted, which would account for a fair chunk of our RUSS/EURO tz capabilities, thus giving them the edge in retaking the system or in other fights generally, for a few days at least…

    October 31, 2010 at 1:21 pm Reply
  19. Hykke

    @Provi Resident: Reading the dev blog lately, it's revealed that the server code is written using Python, which is a scripting language that's not very good at multithreading, in fact it can use threads, but two threads will never execute at he same time. This means that the EVE servers are unable to use multicore CPU's to their full potential.

    Since CPU's from now on are going to get most of their performance increase by adding more cores, this is bad for the future of EVE. Rewriting the server code in a language that supports real multitasking is also a daunting task that is bound to introduce new bugs.

    Best value for money right now is to find the issues/bugs that are causing lag.

    October 31, 2010 at 1:29 pm Reply
  20. Jeff

    @Drazi1: my post was more directed at the silly commentary in the article about CCP's efforts to fix lag. What CCP did with LXQ is impressive, but there's only so much they can do on a live server where people primarily care about achieving an objective, not about collecting server performance data. Players should be joining Mass Test Events if they seriously care about getting lag fixed.

    That said, the NC brought 1600 pilots into system before the russians came and the reason for that can only be "to make it extremely hard for the russians to enter system and outlive it". Lag was an integral part of the NC plan, a node crash was part of the DRF plan to counteract the NC advantage of a loaded system. I'm not blaming either side, it's a perfectly valid tactic that's been used for as long as I've played the game by all large powerblocks.

    October 31, 2010 at 2:12 pm Reply
  21. Drazi1

    I would class the lxq fight as a mass test lol. And to intentionally crash the server is against the EULA, correct me if am wrong

    October 31, 2010 at 3:12 pm Reply
  22. Carlos

    Well its obvious what they did. I dont particularly think they did set the Jita node for no other reason than to make sure it does not crash. This way they can get as much reading as they can for as long as possible. This probably was a good event for them to get some good concrete readings. I am sure if another similar battle happens they would do something similar. This although did not help players atm it probably will help in the future. But what i see often is ppl expecting miracles. This is rather unfortunate and unrealistic. You can push the boundaries more and more but once you are at the limit, it becomes almost impossible to do so in a stable and safe way.

    Expect changes sure but to tell you the truth the changes probably wont make much of a change. Besides, what other game you know that can have around 3000ppl in one sand box and simultaneously calling commands, activating all sort of modules, doing all the AI trajectory and causing events that can affect all those ppl simultaneously???

    We are playing one of the most advanced games in its technology and with a mountain of interaction. This probaly one of the most, if not the most competitive alliance games out there. And I have to say that many across many alliances are pushing well beyond the server capabilities or what it was intended to do. Yes, CCP may have made some mistakes but they have also given us alot more. You can perhaps minimise the lag a bit but when too many ppl take advantage of it, its like CCP did not do nothing…So dont be unrealistic for you can only fill the water to the top of the glass.

    What i suggest is to help and allow CCP continue their testing by providing those mayor fights what ever the outcome.

    October 31, 2010 at 3:56 pm Reply
  23. bobbit

    posting fakemails on eve-kills is bad mhkay?

    October 31, 2010 at 5:26 pm Reply
  24. Mechanics

    That was almost a proper fleet fight. I for one am waiting for proper big fleet fights to happen. Some where around 10000vs10000 people should be a good start.

    October 31, 2010 at 6:17 pm Reply
  25. So Sad

    Wow, I hope the node was properly instrumented and logged – it would totally suck if the data was lost. This could be a goldmine in terms of scaling Eve.

    Good job CCP!

    October 31, 2010 at 8:57 pm Reply
  26. Liz Laser

    "That said, the NC brought 1600 pilots into system before the russians came and the reason for that can only be “to make it extremely hard for the russians to enter system and outlive it”." – Jeff


    Over 40 enemy Motherships were spotted in LXQ2 the day before. That alone assured that thousands of people would show up. Everyone wants to get on those killmails.

    Flowing in steadily to get in on the fun is something our opponents could have chosen, but did not. Ask yourself why they didn't choose to flow in like us (my guess: they didn't have a promise of NC mothership killmails). There could have been epic fights all day and night if they had.

    October 31, 2010 at 9:43 pm Reply
  27. WTM

    TBH, both sides wanted the system, so both sides threw everything they had at it.

    Accusing either side of trying to create lag or crash the node is probably unfair on all sides.

    I know in my fleet (on the NC side) the order was clearly given to keep drones in, to AVOID lag..

    Hopefully this gave CCP some data to work towards fixing the issues, and giving us the performance we need.

    … oh and props to DRF for actually jumping in, even if it equalled lag city.

    October 31, 2010 at 9:49 pm Reply
  28. Shadowguy

    "posting fakemails on eve-kills is bad mhkay?"


    I was there on gate and saw CCP Atlas die. His ship was an Incursus model. Donno why he was not in his Polaris Frigate. Heh heh.

    November 1, 2010 at 1:59 am Reply

Leave a Reply