EVE-Search ForumWatch http://eve-search.com/ The alternative EVE-Online Forum browser. en-us Tue, 6 Jan 2009 00:00:00 +0000 EVE-Search RSS Module v1.1 chribba@evemail <![CDATA[RE: Infiniband - Do it do it...just do it. - by Apple Boy]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=15#433
Also, when is the stackless IO source code going to be released?
]]> Fri, 28 Nov 2009 22:35:00 +0000 eve-search/guid/9269042 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Rachel Voegel]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=15#432 ]]> Fri, 28 Nov 2009 17:04:00 +0000 eve-search/guid/9267163 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Ray McCormack]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=15#431

[WTS] Tech II Component BPO Sets
]]> Fri, 28 Nov 2009 14:15:00 +0000 eve-search/guid/9266250 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Rachel Voegel]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=15#430 Originally by: Andrue
C++ empowers programmers to write code the way they want - more so than most other languages except assembler. The object orientation allows you to encapsulate your innermost thoughts and bring them to fruition.

It will allow a good programmer to produce high performance, high quality code.

It also allows a poor programmer to produce a screw up.

Listen to this man. Smile

Writing C++ is a bit like driving a car where as other languages are more like driving a train.

There is greater freedom but also greater responsibility.

The important thing is to follow the well established rules (wear a seatbelt / keep data members private, etc).
]]> Fri, 28 Nov 2009 14:07:00 +0000 eve-search/guid/9266249 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Sidrat Flush]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=15#429 Originally by: Zeba
Sweet, so a second (and final :-P) question would be when the rest of the new blades start shuffling in and your looking for regions to boost how about throwing 0.0 some love? I know that myself and many others would just adore not having an ad hoc fleet fight seven systems away ruin our pew pew or carebear small gang stuff by lagging us out. Crying or Very sad

Pretty please? ugh

As an added incentive I'll make my very first player corp ever with me as ceo with a promise of not leaving it for a year if you replace them on a one for one basis. Twisted Evil


I'm pretty sure if you let CCP (may via the petition system?) in advance that you're going to be taking 300+ pod pilots to systems x,y and z for some serious pew pew they'll do the best they can in order for your gaming experience (on both sides) to be as fluid as possible.

I'm sure not one dev would use inside information to rescue or prop up any assets should it be located within the declared strike zone.


--------------------------
Life is about memories the more the better.
]]> Fri, 28 Nov 2009 01:55:00 +0000 eve-search/guid/9263280 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Zeba]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=15#428 many others would just adore not having an ad hoc fleet fight seven systems away ruin our pew pew or carebear small gang stuff by lagging us out. Crying or Very sad

Pretty please? ugh

As an added incentive I'll make my very first player corp ever with me as ceo with a promise of not leaving it for a year if you replace them on a one for one basis. Twisted Evil



inappropriate signature. WeatherMan]]> Thu, 27 Nov 2009 22:07:00 +0000 eve-search/guid/9262253 <![CDATA[RE: Infiniband - Do it do it...just do it. - by CCP Mindstar]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=15#427 Originally by: Zeba
Edited by: Zeba on 27/11/2008 18:51:14
! That vid was very eye opening though after watching the entire m$ pitch for thier hpc I can safely say if your just interested in what this will do for eve then skip to 41:00 and the good stuff gets talked about again. The future looks very good for Eve. ugh

edit. About those new intel blades with win2008 on them. Who got them to use? Empire, low sec or 0.0? Seems to me 0.0 would get the moast benefit hint hint.Very Happy


At the moment its split between the heaviest loaded empire systems - ones that usually require their own node, and 0.0 systems that we anticipate major fleet engagements in.
--]]> Thu, 27 Nov 2009 21:29:00 +0000 eve-search/guid/9262000 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Zeba]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=15#426 very good for Eve. ugh



inappropriate signature. WeatherMan]]> Thu, 27 Nov 2009 18:40:00 +0000 eve-search/guid/9260976 <![CDATA[RE: Infiniband - Do it do it...just do it. - by CCP Mindstar]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=15#425 Originally by: CCP Mindstar
Originally by: Sazumaan Johnza
For those of you lucky enough to attend Fanfest '08, can you remember any specific mention of HPC / Infiniband?

I watched the On the Cutting Edge video but that pretty much focused on graphics only...

(More Fanfest '08 vids here)


There was a lecture by myself, Queeg500 and Microsoft on the Tranquility server, performance and the path to HPC. The video should be uploaded to the fanfest videos site soon(tm).


This has now been uploaded to the website. Its in the Fanfest 2008 part of the videos section.

The video is called "Fanfest 2008: TQ Servers; Making Mountains out of Molehills"

Mindstar
--]]> Thu, 27 Nov 2009 16:45:00 +0000 eve-search/guid/9260172 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Andrue]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=15#424 Edited by: Andrue on 25/11/2008 10:55:24
Originally by: Bimjo
Originally by: Rusty Hinge

Please excuse my poor knowledge in this area too as I am not a programmer.

From what I read C++ is ugly and should not be wished upon anyone.

one man's meat,is another man's poison.
I have seen/written(15 years) code in C++ and never thought it ugly,maybe only to those who don't understand itWink

Just like any "object/item/thing/film/sport/people/hobby/etc." there are good and bad, I never got on with C++ TemplatesCrying or Very sadYARRRR!!
C++ empowers programmers to write code the way they want - more so than most other languages except assembler. The object orientation allows you to encapsulate your innermost thoughts and bring them to fruition.

It will allow a good programmer to produce high performance, high quality code.

It also allows a poor programmer to produce a screw up.

If you are good at handcrafting minutae while knowing how to segregate architecture components then C++ is a great language. Unfortunately in my experience most programmers can only do one or the other.

Templates are great. They allow for more generic programming. I'm a very generic programmer. I have concepts for everything. Most of my programming consts of getting objects to talk to each other. Stick to RAII and insist that objects are fully functional after construction and you can't go far wrong :)
--
(Sarcastic mission running veteran, 4+ years)

[Brackley, UK]

My budgie can say "ploppy bottom". You have been warned.]]> Tue, 25 Nov 2009 10:53:00 +0000 eve-search/guid/9243360 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Sazumaan Johnza]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=15#423 Originally by: Bartholomeus Crane

I thought this thread was dead!

This thread will stick around until at least HPC is deployed, and possibly beyond... Cool
"Eve is more filling than roast steaks slowly grilling over a rotating fire whilst marinating in a combination of Australian fruity wines and the best imported herbs..." - SChimera [16.4.07]]]> Tue, 25 Nov 2009 00:44:00 +0000 eve-search/guid/9241099 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Bartholomeus Crane]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=15#422 Originally by: CCP Mindstar
Originally by: Sazumaan Johnza
For those of you lucky enough to attend Fanfest '08, can you remember any specific mention of HPC / Infiniband?

I watched the On the Cutting Edge video but that pretty much focused on graphics only...

(More Fanfest '08 vids here)


There was a lecture by myself, Queeg500 and Microsoft on the Tranquility server, performance and the path to HPC. The video should be uploaded to the fanfest videos site soon(tm).


Ohh, that's pretty interesting, I thought this thread was dead!

I liked the Cutting Edge video as well. By far the best one in the list so far, content-wise that it. I've been working to get my agent-based simulations running on these new video cards and am quite impressed with the performance, so it was interesting to see what those video cards are really supposed to do.

Nevertheless, I'd love to hear more about the HPC side of things (other than the promotion video from RedmondRolling Eyes), StacklessIO and 64 must have been the first steps. Can we expect some technical blogs about the 'work in progress'? Nothing definite is needed, just a bit more technical detail about what is going on, some hypothetical ideas you're playing around with. It's clear from the thread that there are players out there with some inkling of what is going on in HPC land and you never know what good it may do ...
--
Quis custodiet ipsos custodes?
]]> Mon, 24 Nov 2009 22:57:00 +0000 eve-search/guid/9240576 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Sazumaan Johnza]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#420 Originally by: CCP Mindstar

There was a lecture by myself, Queeg500 and Microsoft on the Tranquility server, performance and the path to HPC. The video should be uploaded to the fanfest videos site soon(tm).


Ok that's excellent news, thanks for confirming Mindstar...I'll be one of the first to download it when it becomes available! Wink
"Eve is more filling than roast steaks slowly grilling over a rotating fire whilst marinating in a combination of Australian fruity wines and the best imported herbs..." - SChimera [16.4.07]]]> Mon, 24 Nov 2009 14:55:00 +0000 eve-search/guid/9237382 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Bimjo]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=15#421 Originally by: Rusty Hinge

Please excuse my poor knowledge in this area too as I am not a programmer.

From what I read C++ is ugly and should not be wished upon anyone.

one man's meat,is another man's poison.
I have seen/written(15 years) code in C++ and never thought it ugly,maybe only to those who don't understand itWink

Just like any "object/item/thing/film/sport/people/hobby/etc." there are good and bad, I never got on with C++ TemplatesCrying or Very sadYARRRR!!
====================
]]> Mon, 24 Nov 2009 14:55:00 +0000 eve-search/guid/9240575 <![CDATA[RE: Infiniband - Do it do it...just do it. - by CCP Mindstar]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#419 Originally by: Sazumaan Johnza
For those of you lucky enough to attend Fanfest '08, can you remember any specific mention of HPC / Infiniband?

I watched the On the Cutting Edge video but that pretty much focused on graphics only...

(More Fanfest '08 vids here)


There was a lecture by myself, Queeg500 and Microsoft on the Tranquility server, performance and the path to HPC. The video should be uploaded to the fanfest videos site soon(tm).
--]]> Mon, 24 Nov 2009 14:34:00 +0000 eve-search/guid/9237381 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Thargat]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#418 Don't get me wrong I'd love to see CCP spread threads over multiple CPUs but then again I think it'd have to be a custom built system for that particular purpose (like supercomputing). At wich point you make modifying the system hard and expensive (by a large multiplier).


There's only one sig that matters... and that's Radius.]]> Mon, 24 Nov 2009 13:37:00 +0000 eve-search/guid/9236958 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Sazumaan Johnza]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#417
I watched the On the Cutting Edge video but that pretty much focused on graphics only...

(More Fanfest '08 vids here)

"Eve is more filling than roast steaks slowly grilling over a rotating fire whilst marinating in a combination of Australian fruity wines and the best imported herbs..." - SChimera [16.4.07]]]> Mon, 24 Nov 2009 13:11:00 +0000 eve-search/guid/9236764 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Rusty Hinge]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#416 Edited by: Rusty Hinge on 22/11/2008 07:25:40
I can not get through all 14 pages right now but I did find an interesting thing that may not help.

Please excuse my poor knowledge in this area too as I am not a programmer.

I gather that eve is written in Python. I have found that there are compilers that can convert Python to C++. From what I read C++ is ugly and should not be wished upon anyone.

Well it seems Intel is working on "CT" a multi-threading version of C++ that can cope with and scale to many cores.


This is a paper on the subject that hurts me but might help you with getting to multi-core threading.


It is late and my Google search finger is tired.

Hope this is new info and I hope it helps.

If you have not done so already it may be worth while to contact Intel directly on this matter and see if they are willing to work with you in multi-threading your code. Sometimes they have a soft spot for projects like this.


_______________________________________________

Running with scissors. Want to play?]]> Sat, 22 Nov 2009 07:22:00 +0000 eve-search/guid/9222590 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Dr Slaughter]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#415 Edited by: Dr Slaughter on 07/10/2008 00:08:14
Originally by: sg3s
Originally by: Nicho Void
In light of the recent dev blog.

I'm curious to know what placing a system on a node actually entails. Is it a physical process of switching blades, wires, plugs, etc? Or is it a matter of changing code to define which systems report to which blade?


It's Virtual, and the problem is that you cannot move the process on the machine to an other machine without interfering with anything it's doing... it's just not possible.
Didn't watch that video of a streaming video server switching hosts did you...

http://mschnlnine.vo.llnwd.net/d1/edge/7/7/6/1/livemig_edge.wma

It certainly is possible but with the majority of the server hardware being the same somewhat pointless, plus, to work nicely they would need a iScsi (if using MS stuff, FC SAN if using VmWare etc.) implemented and separate networks for that traffic etc. etc.

ANYWAY...

I too, would love to know what the process is to move system to a re-enforced node. CCP talk about mapping... so I guess there's a cache that the proxy servers read to know which node is running which systems services. Likewise for nodes re-booting, I guess they read the same cache to figure out what they should be doing.

CCP care to comment how it's done?

Also, I don't suppose you would explain the work flow of a session change while you're at it? :)]]> Tue, 7 Oct 2009 00:07:00 +0000 eve-search/guid/8893285 <![CDATA[RE: Infiniband - Do it do it...just do it. - by sg3s]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#414 Originally by: Nicho Void
In light of the recent dev blog.

I'm curious to know what placing a system on a node actually entails. Is it a physical process of switching blades, wires, plugs, etc? Or is it a matter of changing code to define which systems report to which blade?


It's Virtual, and the problem is that you cannot move the process on the machine to an other machine without interfering with anything it's doing... it's just not possible.
Originally by: Tarminic
Because even when EVE sucks, it sucks less than every other MMO out there.
]]> Mon, 6 Oct 2009 21:34:00 +0000 eve-search/guid/8892496 <![CDATA[RE: Infiniband - Do it do it...just do it. - by MotherMoon]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#413 Originally by: Nicho Void
In light of the recent dev blog.

I'm curious to know what placing a system on a node actually entails. Is it a physical process of switching blades, wires, plugs, etc? Or is it a matter of changing code to define which systems report to which blade?


that's a good question, but something tells me it's virtual :P


]]> Mon, 6 Oct 2009 21:23:00 +0000 eve-search/guid/8892421 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Nicho Void]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#412 recent dev blog.

I'm curious to know what placing a system on a node actually entails. Is it a physical process of switching blades, wires, plugs, etc? Or is it a matter of changing code to define which systems report to which blade?
]]> Mon, 6 Oct 2009 20:57:00 +0000 eve-search/guid/8892284 <![CDATA[RE: Infiniband - Do it do it...just do it. - by SiJira]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#411 jita can handle 10000 pilots at once with no lag
a pvp battle can handle 5000 pilots at once with no lag

will ccp bring about a massive campaign to get more subscriptions?
will big alliances do their best to push the limits?
will there be no more lag as the technology stays ahead of the max populations?

Trashed sig, Shark was here]]> Thu, 2 Oct 2009 18:36:00 +0000 eve-search/guid/8867814 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Dr Slaughter]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#410 Originally by: Bartholomeus Crane
but I don't think it can be done seamlessly.
'They' can move virtualised hosts seemlessly these days. For a cute example using Hyper-V (seeing as CCP are a MS shop) take a look at this link as an example. It's near the top of this page

and.. CCP... RARH!

more StacklessIO please.. sir... Very Happy
]]> Tue, 30 Sep 2009 16:34:00 +0000 eve-search/guid/8852099 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Bartholomeus Crane]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#409
I was wondering though what the performance mark is that CCP should be aiming for. 1000 ships in a fleet battle without noticeable lag enough? 2000 ships? What's realistic here? Are there that many 1000 ship fleet battles out there? I can't help but think that if CCP can handle 500 to 600 without noticeable lag, players really should stop complaining. I mean the time and effort of getting 300 a side to a battle must be really prohibitive ...
--
Quis custodiet ipsos custodes?
]]> Sun, 28 Sep 2009 20:34:00 +0000 eve-search/guid/8840073 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Zeba]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#408 Originally by: Sazumaan Johnza
Sounds like InfiniBand is the next logical step? Wink
Of course it is and has been in planning for ages with the Soon soon to give way to deployed. But don't expect the 19% of the playerbase who have issues with sov mechanics to be happy even if they can pew pew with 1000 ships lag free. It will simply go right back to waaaaa we brought 1500 ships and the node crashed.. again. U sux cccp. Evil or Very MadEvil or Very MadEvil or Very MadEvil or Very Mad However that is something that needs a gameplay tweak and not moar hardware to fix. Wink



inappropriate signature. WeatherMan]]> Sun, 28 Sep 2009 07:32:00 +0000 eve-search/guid/8836995 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Sazumaan Johnza]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#407 Edited by: Sazumaan Johnza on 28/09/2008 07:19:59
CCP have confirmed that they are planning an upgrade to Windows HPC Server 2008.

In other news: CCP Explorer on StacklessIO & deployment on TQ. (Must-read Dev blog!)

Sounds like InfiniBand is the next logical step? Wink


"Eve is more filling than roast steaks slowly grilling over a rotating fire whilst marinating in a combination of Australian fruity wines and the best imported herbs..." - SChimera [16.4.07]]]> Sun, 28 Sep 2009 07:17:00 +0000 eve-search/guid/8836968 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Bartholomeus Crane]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#406 Originally by: Kal Shakai
Although I believe that load balancing and parallel processing are both important aspects of this project, it's the paralleling that offers the biggest payback. Being able to reduce a single node down to one Sol, or even grid, doesn't get us 800 v 800 lag free fights. The ability to process that fight over 16 shared nodes (for example) does get us closer. Load balancing becomes important at this point because, by sharing nodes, more Sols will need to be run on the same shared nodes assuming the same number of blades.

Identifying places in code that can be paralleled isn't particularly difficult once you get the hang of it. It usually involves looking for loops that involve significant CPU cycles per iteration. Things get tricky when data is modified in any way during this process. However, when data is "frozen" it's rudimentary. Therefore, anything based on time slices is usually a snap. I don't know enough about the code being used in EVE to offer any insight into easy or hard it's going to be for them. I would suggest they start at this point and test to even see if a large number of actors is possible before going too far.


I'd have to agree with Kal Shakai. Even after distributing all the other services from the node, you're still stuck with a whole in-space system to run on a single CPU. Putting that in a VM and distributing that around will help, but I don't think it can be done seamlessly. I think you'll have to parallelise on a lower granularity, either by grid, or even by ship. By grid seems the most promising to me since you have to jump between grids most of the time. It'll still leave you (in the worst case scenario) with one big grid to handle on a node, so 1k vs 1k battles will be lagged, but an upper limit will be unavoidable, and I think those types of battles will be rare. Distribution by ship will be much more difficult, but perhaps Infiniband and RDMA will make it efficient enough to be useful.

So, I agree with Kal Shakai, this is where I would suggest CCP devote their efforts.
--
Quis custodiet ipsos custodes?
]]> Sat, 27 Sep 2009 11:53:00 +0000 eve-search/guid/8832455 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Kal Shakai]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#405
Identifying places in code that can be paralleled isn't particularly difficult once you get the hang of it. It usually involves looking for loops that involve significant CPU cycles per iteration. Things get tricky when data is modified in any way during this process. However, when data is "frozen" it's rudimentary. Therefore, anything based on time slices is usually a snap. I don't know enough about the code being used in EVE to offer any insight into easy or hard it's going to be for them. I would suggest they start at this point and test to even see if a large number of actors is possible before going too far.
]]> Fri, 26 Sep 2009 20:10:00 +0000 eve-search/guid/8829610 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Bartholomeus Crane]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#404
The problem lies, I think, with the 'contact-switch' involved with moving VMs from one blade to another. In a non-interactive game, or one with less interactivity, using VMs would be no, or less of a problem. But in EVE, which is highly interactive when it comes to the in-space service, it is. Copying the entire state of a whole system from one VM to another (on another blade), takes time, I think, to much time. Infiniband, and such things as RDMA, if applicable, will help, but it will nevertheless lead to 'lag-spikes' for all inhabitants of the system.

The problem is where to draw the line of distribution; at what granularity do you do distribution. Personally, I don't think full system distribution will cut it, even if all other services where to be distributable. I believe the best possible place 'to draw the line' is by distribution on the ship level. This doesn't mean individual ships need to be distributable however, this level of distribution also allows for groups of ships to be distributed.

Example: when a fleet battle is raging in one grid in a system, this level of distribution allows for other grids in that system to be distributed away from the node, for example those 20 ships having a mining op on the other side of the grid.

Distributing ships from the same grid will probably remain difficult, since there is so much information needed by all ships on the grid to remain functioning. So even this low granularity of distribution has an upper-limit, but without other services, and with other grids already running on other nodes, I would be surprised to see the that upper-limit to be so low as to have an effect in most pratical situations.

tl;dr: I don't thing distributing with VMs will cut it.
--
Quis custodiet ipsos custodes?
]]> Fri, 26 Sep 2009 18:36:00 +0000 eve-search/guid/8829162 <![CDATA[RE: Infiniband - Do it do it...just do it. - by SiJira]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#403 Trashed sig, Shark was here]]> Fri, 26 Sep 2009 17:17:00 +0000 eve-search/guid/8828805 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Dr Slaughter]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#402 Originally by: Pan Crastus
because it shares a CPU/node with other busy stuff
Which is NOT what I'm talking about.

I'm saying that if it's the ONLY process taking up CPU. I'm sorry if I was totally unclear in my earlier posts.

Originally by: Pan Crastus
and that seems to be the case often with 0.0 fleet battles erupting in usually empty systems that are on the same node as mission hubs

Which is why I said 'future' and specifically mentioned when CCP are able to run individual grids on cpu's/cores. You seem to be talking about now, and what would help now and totally misunderstanding what I have been trying to tell you.

Originally by: Pan Crastus
Sure, if it's moved to some other node, it'll probably utilize 100% of a CPU as well, but it will run faster.
Quote:

I totally understand what you're saying btw but it's not what I was talking about at all.

Originally by: Pan Crastus

Well peak CPU speed will not increase quickly, so it's a natural limitation that need not be part of the discussion because it can't be influenced.
Fine. I wasn't 'discussing' it I was just trying to point out that it will be just as much of a problem as it is now, in the future, even after Infiniband is deployed IF the combat engine can't be distributed across cores/nodes.

Anyway I'm going on holiday today so no more posts from me for a while. Very Happy

There is no parody in this thread. Honest.]]> Fri, 26 Sep 2009 09:17:00 +0000 eve-search/guid/8826370 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Pan Crastus]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#401 Originally by: Dr Slaughter
I hope you're not trying to tell me that if you have two identical CPU's and when CPU A is processing a battle and hits 100%, and CPU B is doing nothing, that the 'solution' is moving the process from CPU A to CPU B by using virtualization or similar.

If the CPU's are the same, and the overloading process can be moved from CPU to CPU, at the end of the day it doesn't matter where it is, it will overload any of the CPU's it ends up on as they're all the same.


I can just repeat myself: it matters if the "overloading process" as you call it is currently not running at the full possible speed because it shares a CPU/node with other busy stuff and that seems to be the case often with 0.0 fleet battles erupting in usually empty systems that are on the same node as mission hubs. Sure, if it's moved to some other node, it'll probably utilize 100% of a CPU as well, but it will run faster.

Quote:

I just don't agree that peak CPU speed isn't a problem. It will be until they find a distributed method of conducting combat + have enough physical resource to run it on.


Well peak CPU speed will not increase quickly, so it's a natural limitation that need not be part of the discussion because it can't be influenced.

How to PVP: 1. buy ISK with GTCs, 2. fit cloak, learn aggro mechanics, 3. buy second account for metagaming
]]> Fri, 26 Sep 2009 05:46:00 +0000 eve-search/guid/8825746 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Dr Slaughter]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#400 Originally by: Pan Crastus
Originally by: Dr Slaughter
i.e. when CCP have implemented Infiniband, re-worked their SOL services, and have the grid / battle sim running exclusively on a CPU core where are you going to put it when it runs out of CPU? as.. the blades CPU cores are pretty much all the
same.

My point is, eventually, the battle simulation will run out of available CPU no matter where you run it as it's a serial process.


There are already a lot more solar systems than CPU cores in the cluster, there will be many more grids than CPU cores and as soon as a single node has too many busy grids so that some of them cannot run on one core exclusively, they would benefit from moving to a node with fewer loaded grids.

The problem isn't the peak CPU speed, it's the number of solar systems (now) or grids (in the future) sharing the same CPU core/node. Without dynamic load balancing (= moving the load to other nodes) you will often not get the peak CPU performance for one process whether it's for one grid or one solar system.

I hope you're not trying to tell me that if you have two identical CPU's and when CPU A is processing a battle and hits 100%, and CPU B is doing nothing, that the 'solution' is moving the process from CPU A to CPU B by using virtualization or similar.

If the CPU's are the same, and the overloading process can be moved from CPU to CPU, at the end of the day it doesn't matter where it is, it will overload any of the CPU's it ends up on as they're all the same.

I have already agreed with you that virtualization + vmotion, or for that matter CCP's own load balance system + improvements, will help spread the resources available to best effect.

I just don't agree that peak CPU speed isn't a problem. It will be until they find a distributed method of conducting combat + have enough physical resource to run it on.

At least Infiniband provides a fabric that should aid any distributed solution.

There is no parody in this thread. Honest.]]> Thu, 25 Sep 2009 21:36:00 +0000 eve-search/guid/8824014 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Pan Crastus]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#399 Originally by: Dr Slaughter
i.e. when CCP have implemented Infiniband, re-worked their SOL services, and have the grid / battle sim running exclusively on a CPU core where are you going to put it when it runs out of CPU? as.. the blades CPU cores are pretty much all the
same.

My point is, eventually, the battle simulation will run out of available CPU no matter where you run it as it's a serial process.


There are already a lot more solar systems than CPU cores in the cluster, there will be many more grids than CPU cores and as soon as a single node has too many busy grids so that some of them cannot run on one core exclusively, they would benefit from moving to a node with fewer loaded grids.

The problem isn't the peak CPU speed, it's the number of solar systems (now) or grids (in the future) sharing the same CPU core/node. Without dynamic load balancing (= moving the load to other nodes) you will often not get the peak CPU performance for one process whether it's for one grid or one solar system.


How to PVP: 1. buy ISK with GTCs, 2. fit cloak, learn aggro mechanics, 3. buy second account for metagaming
]]> Thu, 25 Sep 2009 20:49:00 +0000 eve-search/guid/8823746 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Dr Slaughter]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#398 Edited by: Dr Slaughter on 25/09/2008 20:02:54
Originally by: lucy9
Or is there some ever cleverness that goes on ?
Yeah you don't move the OS image, it sits in the same place on a FC SAN. You just move the OS state in memory to the other machine which as you say causes a delay but it's not too hideous.

Also remember that we're talking to the proxy servers which talk to the nodes on our behalf so it would be possible to tweak the proxy servers to be 'more understanding' while it's happening.

Frankly a blank screen for 5 seconds and then the rest of the battle lag free would be well worth it. Might be funny watching everything catch-up on fast forward.

There's real cleverness in moving the network sessions (it's all on VMware website if you're really interested).

There is no parody in this thread. Honest.]]> Thu, 25 Sep 2009 19:57:00 +0000 eve-search/guid/8823515 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Dr Slaughter]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#397 Originally by: Pan Crastus
It will because there's not only 1 process running per node and not all processes require the same amount of CPU time to deliver acceptable service.

We just don't understand what each other writes do we? I'm not talking about NOW, I'm talking about the future..

..
after
..
they've got grids down to running on single cpu cores?

Does that make more sense to you now?

i.e. when CCP have implemented Infiniband, re-worked their SOL services, and have the grid / battle sim running exclusively on a CPU core where are you going to put it when it runs out of CPU? as.. the blades CPU cores are pretty much all the same.

My point is, eventually, the battle simulation will run out of available CPU no matter where you run it as it's a serial process.

If CCP are unable to re-write it to be distributed eventually it would always run out of CPU. I was in system for Goonswarm invading LV to destroy the baby titan and even if both sides of that star gate's grid had been on it's own CPU I'm sure they would have lagged out.

In that situation, virtualisation, and infiniband are not going to save the day. How much of an improvement they would give is another debate.

There is no parody in this thread. Honest.]]> Thu, 25 Sep 2009 19:54:00 +0000 eve-search/guid/8823514 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Pan Crastus]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#396 Originally by: Dr Slaughter
Edited by: Dr Slaughter on 25/09/2008 16:27:52
Edited by: Dr Slaughter on 25/09/2008 16:24:09
Originally by: Pan Crastus
What does the equal power of the blades have to do with anything? Equal power does not mean equal load.

So tell me, exactly where do you move a node that's at 100% after they've got grids down to running on single cpu cores?


You move the busy solar system process to a node that has to execute fewer busy processes (= run queue length = Unix "load" lower) so you increase the percentage of CPU time available for all processes.

Quote:

If the blades are running the same CPUs and the service that's hitting 99% CPU is the problem, how will vmotioning it elsewhere help you?

i.e. ultimately in the end vmotion doesn't help you.


It will because there's not only 1 process running per node and not all processes require the same amount of CPU time to deliver acceptable service.

How to PVP: 1. buy ISK with GTCs, 2. fit cloak, learn aggro mechanics, 3. buy second account for metagaming
]]> Thu, 25 Sep 2009 19:09:00 +0000 eve-search/guid/8823265 <![CDATA[RE: Infiniband - Do it do it...just do it. - by lucy9]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#395
Shuffling that much data across just the PCI-X bus is going to take a theoretical best case of 500m/s, no idea what once you put Inifiniband into the mix.

Or is there some ever cleverness that goes on ?
]]> Thu, 25 Sep 2009 18:01:00 +0000 eve-search/guid/8822854 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Drykor]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#394
]]> Thu, 25 Sep 2009 16:51:00 +0000 eve-search/guid/8822447 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Bartholomeus Crane]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#393 here. It allows distribution on the agent granularity, but has some drawbacks.

Basically, it what it tries to do is eliminate mutable information (and thus locks) and assumes a time-sliced sliced system. One buffer (public buffer) is used to make available current information about the agent. The other buffer (result buffer) is used to store results but sequentially, and it is not available for determining action. The buffers eliminate the needs for (wait) locks, but do partition up the timeslice in phases.

It could work something like this:
1. start time slice
2. initialise public buffer from result buffer, make public buffer available (immutable)
3. block until all public buffers are available (information phase)
4. retrieve action (input), use (other) public buffers as needed
5. block until all actions and information have been retrieved (retrieval phase)
6. calculate result, output into (other) result buffer (mutable, but sequential)
7. block until all result calculations are done (calculation phase)
8. resolve result buffer
9. block until all result have been resolved (resolution phase)
10. end time slice

The result buffer needs an example: if two agents shoot at another agent, the damage is stored in the other agent, but as a list. For that time-slice, the total damage is then the sum of the damages stored in the list. The list itself is still important when figuring out what has happened, but, importantly, there is not ordering of the list. Resolving the result buffer is supposed to be an atomic action, calculated sequentially over all agents.

One could argue that by using phases, or blocks, the 2-buffer approach implements wait-locks.

A number of drawbacks are: the need for time-slices, the explicit synchronicity of the phases, and when distributed the many communication interactions (I research AI for smart dynamic load-balancing algorithms to reduce this). But it does allow for distribution on the agent level.

Returning to Infiniband; low-latency interactions between the agents reduces the stress on the dynamic load-balancing algorithm, making distribution of the agents more viable.

Would something like this be interesting? Or is it maybe similar to what you already have.
--
Quis custodiet ipsos custodes?
]]> Thu, 25 Sep 2009 16:33:00 +0000 eve-search/guid/8822361 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Dr Slaughter]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#392 Edited by: Dr Slaughter on 25/09/2008 16:24:09
Originally by: Pan Crastus
What does the equal power of the blades have to do with anything? Equal power does not mean equal load.

So tell me, exactly where do you move a node that's at 100% after they've got grids down to running on single cpu cores?

If the blades are running the same CPUs and the service that's hitting 99% CPU is the problem, how will vmotioning it elsewhere help you?

i.e. ultimately in the end vmotion doesn't help you.

Originally by: Pan Crastus
One of the main problems right now seems to be the fact that each node runs something like 20-50 -snip- being not noticeable higher load everywhere else.
I agree that Vmotion or similar would be useful from the perspective of providing better over-all resource usage right now. It's been suggested, pretty much, since it came out (as it happens I became a VmWare technical partner a couple of years ago and developed some systems management software for it), but CCP haven't made any noises about adopting it.

There is no parody in this thread. Honest.]]> Thu, 25 Sep 2009 16:23:00 +0000 eve-search/guid/8822216 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Pan Crastus]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=14#391 Edited by: Pan Crastus on 25/09/2008 15:46:33
Originally by: CCP Lingorm
Originally by: Pan Crastus

What does the equal power of the blades have to do with anything? Equal power does not mean equal load. One of the main problems right now seems to be the fact that each node runs something like 20-50 systems and an arbitrary number of these can suddenly/unpredictably become loaded. I.e. you have a busy mission hub and 49 empty systems assigned to it at DT, then suddenly 2 fleet fights erupt in these other 49 systems. At this point it makes sense to move away 1-2 of these fleet fight solar systems to another blade to distribute the load because 1 blade will be extremely busy while most others will be at an average 20-30% or so load.

It'd actually be useful to have 10 idle nodes on standby all the time to move big fleet fights to (so they don't end up on 30% loaded blades), for the sake of better peak performance for fleet fights with the drawback being not noticeable higher load everywhere else.

That would be really cool. But a Node is the Python service (we run 1 node per CPU Core so each blade had 2 nodes on it). Each node can handle multiple solar systems. So we can not dynamically move 1 solar system from out of the node while leaving the others still running. To do this we have to either shutdown the node (Kicking everyone out of the game that has been connected to it) and then remap all the solar systems to our spare nodes or remap the solar system, which will kick everyone still and then bring itself up on the new node.


This could be done more or less seamlessly using Virtualization. Each node would host several VMs and each solar system process would live in its own VM all the time. Then the VMs could be moved to some other node using "live migration" without having to shut down the solar system process. Citrix and VMWare offer this feature already, I'm just not sure how they handle existing TCP connections (they are probably interrupted, but should be easy to restart).

Unfortunately, the current blades probably won't have enough RAM to hold as many VMs as they hold systems currently and I doubt that Citrix/VMWare can resize VMs or share physical RAM among VMs until it's allocated by guest OSes (and even if they did, the guest OSes probably tend to grab memory too greedily). But the host OS will probably swap out inactive VMs so it might work.

Edit: I just saw Rab See's post, which is pretty much what I was thinking, only that I totally forgot about the OS overhead (Windows, ugh). 20-50 instances of Windows per blade is a bit much - but then again, x86 hardware is cheap *cough*.

Quote:

What we have looked at for 0.0 is to go the other way and to dynamically shutdown and relaunch empty solar systems on to new nodes there by removing their resource overheads from the server supporting the fight. This is less disruptive than trying to dynamically move a loaded solar system.

We do have a number of node reserved for this stuff. And we make use of it when we become aware of the situation (usually when the node supporting the fight dies) when then try to use this to give the main system in contention it's own node, but if the fight moves then this effort is wasted.


Sounds good - is there any hope that this could be done on request somehow in case of a pending fleet fight, as a temporary solution? For example, there could be an ingame interface for people to vote on a system restart and if 3/4 of those in system and more than 200 people total have voted in favor of it, the system would be shut down and restarted on a spare node until the next DT - without any GM/Dev intervention.

How to PVP: 1. buy ISK with GTCs, 2. fit cloak, learn aggro mechanics, 3. buy second account for metagaming
]]> Thu, 25 Sep 2009 15:36:00 +0000 eve-search/guid/8822215 <![CDATA[RE: Infiniband - Do it do it...just do it. - by CCP Lingorm]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#389 Originally by: Bartholomeus Crane
Edited by: Bartholomeus Crane on 25/09/2008 14:59:06
I just realised that we can now deduct a more general description of the software running EVE. It might help clear-up some of the terminology and make it easier to discuss things. Apologies if this seems a bit belated (it isn't for me), and please feel free to correct me where you think I'm wrong or where I left something out.

At it's most basic, the software is divided up into nodes, one node running on each CPU/blade/core (however you want to call it). All nodes handle all code, but some nodes only handle things like chat, market and other small things. I assume that the database is separate as well (but not as a node?). Nodes that handle systems handle one (as in the case of Jita) or more systems, although there are some 'spare' nodes for load-balancing. Due to practical and implementation issues load-balancing systems over nodes is (currently) only really possible during down-time, but not dynamically. A session change happens when information has to be transmitted from one node to another, and this happens when a player migrates from one system to another (from one node to another). Nodes themselves are (currently) implemented monolithicly, apart from the separate services mentioned above, although they do use threads (in the Python sense).

As for the ongoing Core work: Infiniband should reduce time spend on session-changes, as it should reduce time spend on sending information from node to node. It may have other positive effects as well. At the same time, the monolithic implementation of a node is to be/being broken down in smaller pieces, in order to make some of these services (e.g. dealing with things happening in-station, perhaps like Ambulation) distributable as well. This should release computational resources for a node, so that it can concentrate on handling in-space services more (fleet battles).

Is this about correct?

Pretty much.

CCP Lingorm
CCP Quality Assurance
QA Engineering Team Leader

Originally by: Lord Fitz
Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.

]]> Thu, 25 Sep 2009 15:09:00 +0000 eve-search/guid/8821826 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Bartholomeus Crane]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#388
At it's most basic, the software is divided up into nodes, one node running on each CPU/blade/core (however you want to call it). Separate from this are things like chat, market and other small things. I assume that the database is separate as well. Nodes handle one (as in the case of Jita) or more systems, although there are some spare nodes for load-balancing issues. Due to practical and implementation issues load-balancing systems over nodes is only really possible during down-time, not dynamically. A session change happens when information has to be transmitted from one node to another, and this happens when a player migrates from one system to another (from one node to another). Nodes themselves are (currently) implemented monolithicly, apart from the separate services mentioned above, although they do use threads (in the Python sense).

As for the ongoing Core work: Infiniband should reduce time spend on session-changes, as it should reduce time spend on sending information from node to node. It may have other positive effects as well. At the same time, the monolithic implementation of a node is to be/being broken down in smaller pieces, in order to make some of these services (e.g. dealing with things happening in-station, perhaps like Ambulation) distributable as well. This should release computational resources for a node, so that it can concentrate on handling in-space services more (fleet battles).

Is this about correct?
--
Quis custodiet ipsos custodes?
]]> Thu, 25 Sep 2009 14:44:00 +0000 eve-search/guid/8821665 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Rab See]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#387 Originally by: CCP Lingorm
Originally by: Pan Crastus

Nodes on standby concept

That would be really cool. But a Node is the Python service (we run 1 node per CPU Core so each blade had 2 nodes on it). Each node can handle multiple solar systems. So we can not dynamically move 1 solar system from out of the node while leaving the others still running. To do this we have to either shutdown the node (Kicking everyone out of the game that has been connected to it) and then remap all the solar systems to our spare nodes or remap the solar system, which will kick everyone still and then bring itself up on the new node. (I think that is how it works, I am not 100% sure on these details but am pretty sure that I am right in the guts of the concept).

What we have looked at for 0.0 is to go the other way and to dynamically shutdown and relaunch empty solar systems on to new nodes there by removing their resource overheads from the server supporting the fight. This is less disruptive than trying to dynamically move a loaded solar system.

We do have a number of node reserved for this stuff. And we make use of it when we become aware of the situation (usually when the node supporting the fight dies) when then try to use this to give the main system in contention it's own node, but if the fight moves then this effort is wasted.


This is very interesting for me, coming late, Ive trawled the thread to get my head into EvEs model.

I work for a large online gambling company, that runs all of its services on very light VMs under vmware on multiple blades, and a quite a few larger 'grunt boxes' - basically the fastest things we can find on a 6 monthly rotation. Nagios watches load on each Virtual Machine (might be your Windows Box with Python service, plus 3 Sols) and as it hits a certain level (player interest on event typically), the VM is dynamically migrated to a 'grunt' for the event. The delay on migration is small (its not a real time game), and is dictated mostly by the network, but its not a killer for us.

I can see why Infiniband would help, the PCI anaology is fine, and it would speed migration of 'player state' from Sol to Sol within your cluster, jumping might become a rather pleasant experience with constant state rather than reconstruction. Of course, the problems come with jumping a blob and all the states, not necessarily becuase of I/O but sudden increased load.

My cusiosity, given that we are looking for fast VM migration - Infiniband is our aim, is that you could conceivably run VM instances of Windows with a statistically busy Sol and other 'far away' but statistically quiet one on the VM. When blob hits, you migrate it to a 'grunt' for action. The grunt might be a spare node per blade (for backplane speed), or something optimal in your mesh that can haul a lump as big as your VM footprint around quicker than the current 'blob lag time'.

VM migratiuon wouldnt dump players, and wouldnt even be seen by the OS as an event, so it gets into the idea that Pan Crastus, but I note that granularity isnt as nice as I've made it, and it might not be feasible to take 10 blades (20 nodes) and split it finer inside VMs giving you 40+ nodes for example. The OS overhead with the VM is obviously the fly in this ointment. On a sidenote, a decent 8 core blade (we use AMD x4 CPUs) can handle 40 of our light VMs easily.

Im also curious about how you monitor things, and of your ability to preemptively strike and get a node ready for an impending battle.

Hell - it would be nice trying to solve your problems.


.
.
8/ everyone]]> Thu, 25 Sep 2009 14:25:00 +0000 eve-search/guid/8821640 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Bartholomeus Crane]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#386 Edited by: Bartholomeus Crane on 25/09/2008 14:09:54
Thanks for those posts Lingorm, at the least it tells us what you're working on and what you're planning to do with Infiniband and concurrency in general.

That Infiniband will reduce the time spend on session changes (moving from node to node) is clear. It's a bit of a shame that migrating systems from node to node is not (well) supported (without shutting down the node etc.), but I'm not surprised, it's a very difficult thing to do seamlessly, and in the case of migrating empty systems, the benefits could well be slight. Although it may seem a straightforward target for distribution/load-balancing, I doubt that it is.

Instead, I'm glad you're thinking about dismantling the monolithic code (except for chat, market, etc.) dealing with a system on a node. I think is safe to assume, this will be needed for decoupling Ambulation from having an effect on whatever else happens in the system, as referenced in other posts/dev blogs.

However, as I see it, there's a limit to what can be gained from that. This is what I mean: suppose that in the ideal case, all other threads or services can be distributed away from the node, and you're left with the supporting the grid only (ignoring inevitable overhead for convenience), then the number of players on a grid will still be limited to the computational power of the node (or CPU the node is running on). This is compounded by the fact that several systems are handled by one node.

The question I would like to ask is, are you also looking (however far off) into distributing the handling of the in-space aspect over several nodes?

Looking forward to the (nerd) blogs BTW.
--
Quis custodiet ipsos custodes?
]]> Thu, 25 Sep 2009 14:09:00 +0000 eve-search/guid/8821639 <![CDATA[RE: Infiniband - Do it do it...just do it. - by CCP Lingorm]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#385 Edited by: CCP Lingorm on 25/09/2008 11:41:00
Originally by: Pan Crastus

Thanks for the reply, that sheds some light on the way this is going ... I suppose this means that we can assume that:

- jumping into systems (also logging on, undocking - all session changes that put you in a system) has a noticeable cost currently, especially in busy systems, because copying data between nodes is slow and even recreating it is faster

- grids have their own process already, putting it on another node is thus not terribly complicated but unfeasible at the moment because too much data needs to be passed around in a short time

Some questions I dare ask now:

1) at what point do grid processes get created and how will they be assigned to different nodes in the future? I take it that right now, grids with stuff on them get created at DT while grids with no stuff on them (safespots etc.) get created dynamically. Since most fleet battles happen where there's always something happening (stations, gates, POSes so the grid process is always present), does this mean that without dynamic relocation of grid processes to other nodes (i.e. dynamic load balancing for grids) we'd be stuck in a similar situation with grids as we have now for solar systems? (i.e. sudden load spikes on some nodes with no way to move around the processes for load distribution)

2) will solarsystem jumps be as "seamless" as grid warps at some point, i.e. will be be able to keep our cloaks/modules active when jumping, as it is probably easier on the servers then (copy data + modifiy it to switch off modules vs. just copy data)? Also, will gang modules work across solar systems then, since they'd have to work across grids (on different nodes) as well, or will they only work on grids?


Grids do not currently have their own process. It is currently monolithic (except for Chat, Market and some other little things). This is one of the things that is due for a change (step one is to pull all station services out so that the 'solar system process' just does the inspace stuff). After that we can look at further breaking it down.

CCP Explorer is working on a couple of really nice blogs that should be hitting the news feeds Soon(TM) that will explain more on the StacklessIO that he mentioned and the changes this has brought to the server and what it will allow us to do going forward.

On another note the reasons Windows was chosen as the OS was because of a nice little feature called IO Completion that came with WinSock 2, so it was a deliberate architecture decision for a feature that was only supported on Windows. As I understand it Linux now has this but not all the features of it that we make use of from the windows side.

CCP Lingorm
CCP Quality Assurance
QA Engineering Team Leader

Originally by: Lord Fitz
Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.

]]> Thu, 25 Sep 2009 11:40:00 +0000 eve-search/guid/8820773 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Pan Crastus]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#384 Edited by: Pan Crastus on 25/09/2008 11:34:01
Edited by: Pan Crastus on 25/09/2008 11:31:37
Originally by: CCP Lingorm
Originally by: Pan Crastus

...

Infiniband offers a number of advantages.

1) It is an industry standard, this means that we can remove our own legacy code that does this work and rely on hardware acceleration offered by Inifiband. We are also looking onto making use of RDMA offered by Infiniband for passing of objects from memory from one node to another. Where we see this working would be to copy the memory object of your session from one node to the next, rather than just rebuild it on the new server (cos this is currently faster, but copying the memory object would 'technically' be quicker.

2) HPC. Infiniband is already compliant with HPC infrastructures.

Infiniband will initiall not have a major impact on Fleet combat, as the load from that is in other systems. Longer term with the memory object sessions this will reduce the load as the node supporting the combat will have the memory object passed to it rather than building it. This will free up CPU cycles at jump in. Even longer term with the splitting of services from the current monolithic architecture we can then make grids run own their own node and by moving objects in memory from cpu to cpu we can dedicate the CPU on these nodes to just running the combat. Most of this is some distance off (Quite some distance) but we have to lay the ground work first.



Thanks for the reply, that sheds some light on the way this is going ... I suppose this means that we can assume that:

- jumping into systems (also logging on, undocking - all session changes that put you in a system) has a noticeable cost currently, especially in busy systems, because copying data between nodes is slow and even recreating it is faster

- grids have their own process already, putting it on another node is thus not terribly complicated but unfeasible at the moment because too much data needs to be passed around in a short time

Some questions I dare ask now:

1) at what point do grid processes get created and how will they be assigned to different nodes in the future? I take it that right now, grids with stuff on them get created at DT while grids with no stuff on them (safespots etc.) get created dynamically. Since most fleet battles happen where there's always something happening (stations, gates, POSes so the grid process is always present), does this mean that without dynamic relocation of grid processes to other nodes at any moment (i.e. dynamic load balancing for grids) we'd be stuck in a similar situation with grids as we have now for solar systems? (i.e. sudden load spikes on some nodes with no way to move around the processes for load distribution)

2) will solarsystem jumps be as "seamless" as grid warps at some point, i.e. will be be able to keep our cloaks/modules active when jumping, as it is probably easier on the servers then (copy data + modifiy it to switch off modules vs. just copy data)? Also, will gang modules/bonuses work across solar systems then, since they'd have to work across grids (on diffent nodes possibly) anyway, or will they only work on the same grid anymore?

How to PVP: 1. buy ISK with GTCs, 2. fit cloak, learn aggro mechanics, 3. buy second account for metagaming
]]> Thu, 25 Sep 2009 11:31:00 +0000 eve-search/guid/8820732 <![CDATA[RE: Infiniband - Do it do it...just do it. - by CCP Lingorm]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#383 Originally by: Pan Crastus

What does the equal power of the blades have to do with anything? Equal power does not mean equal load. One of the main problems right now seems to be the fact that each node runs something like 20-50 systems and an arbitrary number of these can suddenly/unpredictably become loaded. I.e. you have a busy mission hub and 49 empty systems assigned to it at DT, then suddenly 2 fleet fights erupt in these other 49 systems. At this point it makes sense to move away 1-2 of these fleet fight solar systems to another blade to distribute the load because 1 blade will be extremely busy while most others will be at an average 20-30% or so load.

It'd actually be useful to have 10 idle nodes on standby all the time to move big fleet fights to (so they don't end up on 30% loaded blades), for the sake of better peak performance for fleet fights with the drawback being not noticeable higher load everywhere else.

That would be really cool. But a Node is the Python service (we run 1 node per CPU Core so each blade had 2 nodes on it). Each node can handle multiple solar systems. So we can not dynamically move 1 solar system from out of the node while leaving the others still running. To do this we have to either shutdown the node (Kicking everyone out of the game that has been connected to it) and then remap all the solar systems to our spare nodes or remap the solar system, which will kick everyone still and then bring itself up on the new node. (I think that is how it works, I am not 100% sure on these details but am pretty sure that I am right in the guts of the concept).

What we have looked at for 0.0 is to go the other way and to dynamically shutdown and relaunch empty solar systems on to new nodes there by removing their resource overheads from the server supporting the fight. This is less disruptive than trying to dynamically move a loaded solar system.

We do have a number of node reserved for this stuff. And we make use of it when we become aware of the situation (usually when the node supporting the fight dies) when then try to use this to give the main system in contention it's own node, but if the fight moves then this effort is wasted.

CCP Lingorm
CCP Quality Assurance
QA Engineering Team Leader

Originally by: Lord Fitz
Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.

]]> Thu, 25 Sep 2009 11:23:00 +0000 eve-search/guid/8820692 <![CDATA[RE: Infiniband - Do it do it...just do it. - by CCP Lingorm]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#382 Originally by: Pan Crastus

I'd like to know how this is supposed to help fleet battles or even the situation with several loaded systems running on the same CPU/blade ... So far there has been no mention of several blades being involved in such things currently, almost all the stuff that is happening in one solar system runs on the same blade, except market and DB (and chat naturally).

One thing Infiniband would help with would be virtualization + live migration to other blades, if they decided to try to implement dynamic load balancing that way. VMWare and Citrix offer that for Windows already and Microsoft is trying to catch up: Linkage. It would probably be worthwhile to try this, not much programming required (maybe some networking to handle dropped tcp connections) and it would be nice to be able to move fleet battles to idle nodes with the users only seeing a brief "entering space" popup.

Infiniband offers a number of advantages.

1) It is an industry standard, this means that we can remove our own legacy code that does this work and rely on hardware acceleration offered by Inifiband. We are also looking onto making use of RDMA offered by Infiniband for passing of objects from memory from one node to another. Where we see this working would be to copy the memory object of your session from one node to the next, rather than just rebuild it on the new server (cos this is currently faster, but copying the memory object would 'technically' be quicker.

2) HPC. Infiniband is already compliant with HPC infrastructures.

Infiniband will initiall not have a major impact on Fleet combat, as the load from that is in other systems. Longer term with the memory object sessions this will reduce the load as the node supporting the combat will have the memory object passed to it rather than building it. This will free up CPU cycles at jump in. Even longer term with the splitting of services from the current monolithic architecture we can then make grids run own their own node and by moving objects in memory from cpu to cpu we can dedicate the CPU on these nodes to just running the combat. Most of this is some distance off (Quite some distance) but we have to lay the ground work first.


CCP Lingorm
CCP Quality Assurance
QA Engineering Team Leader

Originally by: Lord Fitz
Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.

]]> Thu, 25 Sep 2009 11:13:00 +0000 eve-search/guid/8820633 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Pan Crastus]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#381 Originally by: Dr Slaughter
Somehow I doubt VMotion or similar technology will be much use as all the blades are roughly equal in power. We had our little discussion earlier about possibly using Power6 blades but it seems unlikely anything like that will be implemented.


What does the equal power of the blades have to do with anything? Equal power does not mean equal load. One of the main problems right now seems to be the fact that each node runs something like 20-50 systems and an arbitrary number of these can suddenly/unpredictably become loaded. I.e. you have a busy mission hub and 49 empty systems assigned to it at DT, then suddenly 2 fleet fights erupt in these other 49 systems. At this point it makes sense to move away 1-2 of these fleet fight solar systems to another blade to distribute the load because 1 blade will be extremely busy while most others will be at an average 20-30% or so load.

It'd actually be useful to have 10 idle nodes on standby all the time to move big fleet fights to (so they don't end up on 30% loaded blades), for the sake of better peak performance for fleet fights with the drawback being not noticeable higher load everywhere else.

How to PVP: 1. buy ISK with GTCs, 2. fit cloak, learn aggro mechanics, 3. buy second account for metagaming
]]> Thu, 25 Sep 2009 11:05:00 +0000 eve-search/guid/8820632 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Dr Slaughter]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#380 Originally by: Pan Crastus
Originally by: Dr Slaughter

CCP are adding Infiniband to the mix. This will improve all instances of passing data from one blade to another. As CCP Lingorm has said they have a Cell devoted to implementing HPC mechanism to leverage the Infiniband infrastructure once it's rolled out.


I'd like to know how this is supposed to help fleet battles or even the situation with several loaded systems running on the same CPU/blade ... So far there has been no mention of several blades being involved in such things currently, almost all the stuff that is happening in one solar system runs on the same blade, except market and DB (and chat naturally).

One thing Infiniband would help with would be virtualization + live migration to other blades, if they decided to try to implement dynamic load balancing that way. VMWare and Citrix offer that for Windows already and Microsoft is trying to catch up: Linkage. It would probably be worthwhile to try this, not much programming required (maybe some networking to handle dropped tcp connections) and it would be nice to be able to move fleet battles to idle nodes with the users only seeing a brief "entering space" popup.
Somehow I doubt VMotion or similar technology will be much use as all the blades are roughly equal in power. We had our little discussion earlier about possibly using Power6 blades but it seems unlikely anything like that will be implemented.

Infiniband won't help locally on blades although a common IPC/Shared Memory interface between cores and blades might help move data from one core to another (or equally to a core on a different blade), none of that is going to help fleet battles much.

Even if they allow individual grids to be run on their own CPUs, and can pass data to the grid quickly due to shared memory/IB, they're still stuck with processing the grid's combat sequentially. As Lingorm said back on page 9 (or so), Infiniband won't fix everything.

It might make getting into system easier though Very Happy

There is no parody in this thread. Honest.]]> Thu, 25 Sep 2009 10:39:00 +0000 eve-search/guid/8820527 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Pan Crastus]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#379 Originally by: Dr Slaughter

CCP are adding Infiniband to the mix. This will improve all instances of passing data from one blade to another. As CCP Lingorm has said they have a Cell devoted to implementing HPC mechanism to leverage the Infiniband infrastructure once it's rolled out.


I'd like to know how this is supposed to help fleet battles or even the situation with several loaded systems running on the same CPU/blade ... So far there has been no mention of several blades being involved in such things currently, almost all the stuff that is happening in one solar system runs on the same blade, except market and DB (and chat naturally).

One thing Infiniband would help with would be virtualization + live migration to other blades, if they decided to try to implement dynamic load balancing that way. VMWare and Citrix offer that for Windows already and Microsoft is trying to catch up: Linkage. It would probably be worthwhile to try this, not much programming required (maybe some networking to handle dropped tcp connections) and it would be nice to be able to move fleet battles to idle nodes with the users only seeing a brief "entering space" popup.

How to PVP: 1. buy ISK with GTCs, 2. fit cloak, learn aggro mechanics, 3. buy second account for metagaming
]]> Thu, 25 Sep 2009 10:30:00 +0000 eve-search/guid/8820489 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Dr Slaughter]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#378 Originally by: Kal Shakai

Real mature. Your misinterpretation of his post and subsequent flame only makes you look like the short bus rider.
If everyone actually read the thread, the various links from the thread to other material, they would be far less likely to make ill informed comments and posts.

This thread started out as a really nice, informative, low signal-to-noise debate and as it's grown, it's turning to shit. People keep re-hashing the language/os/why CCP are idiots and can't program a game points again and again.

I suppose this is the Tragedy of the conversational commons.

As far as flaming Pan, if I got it totally wrong, my apologies. I was ****ed off at my favorite thread turning into a debate about my OS/language is better than yours.

I will return to the back of the bus now. Rolling Eyes


There is no parody in this thread. Honest.]]> Thu, 25 Sep 2009 09:53:00 +0000 eve-search/guid/8820488 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Dr Slaughter]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#377 Originally by: Jaabaa
Windows isn't the issue here, its Python's lack of real support for multi-core/MP/SMP systems because of the GIL.
Exactly. All these comments about 'lets have CCP re-write in (insert perceived better language) on (insert perceived better OS)' is a waste of time.

It's written in Python.
It's running on Windows.
It's running on IBM blades.

They're adding Infiniband (that appears to be in the thread title still, and not 'non-CCP system architecture gurus thoughts and ideas of programming Eve').

The SOL code is microthreaded, combat is serial, when leaving python to do something in C++ CCP use their own extensions to Python that help deal with GIL issues.

Each instance of the SOL code on a blade is run as a separate process. So they don't need [insert solar systems number] / [insert blades] to have one star system per SOL. They would need [insert solar systems number] / [CPU cores] to do that.

CCP are adding Infiniband to the mix. This will improve all instances of passing data from one blade to another. As CCP Lingorm has said they have a Cell devoted to implementing HPC mechanism to leverage the Infiniband infrastructure once it's rolled out.

CCP are re-factoring their code. This will also add performance improvements, they're also changing from a monolithic architecture by breaking out as many services as makes sense which will allow them to run some parts of todays SOL services on different cores or machines.

They are not, as far as they have posted doing any of the following:

  • Implementing non-IBM non-Intel based CPUs
  • Re-writing Eve in something other than Python
  • Planning on moving to a different operating system


So for the love of god please can you take all those thoughts and comments into another thread and leave this one, specifically, to comments about INFINIBAND and how it might improve the game. Perhaps if people stopped trying to tell CCP how to suck eggs in this thread CCP Lingorm might grace us with his presence again with an update about how the Infiniband deployment and testing is going.

Although.. if you check the CCP hiring page, they're hiring a distributed computer architect and also a core network programmer. Seems like they're looking to improve the team to take full advantage of the infrastructure changes.





There is no parody in this thread. Honest.]]> Thu, 25 Sep 2009 09:34:00 +0000 eve-search/guid/8820311 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Jaabaa]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#376 Edited by: Jaabaa on 24/09/2008 20:17:35
Originally by: lucy9
Creating a new process in Windows is really really really slow as is task switching, so the only suitable option for concurrency is threads.

Unix forks are pretty quick as are task switches, so it's a reasonable alternative to implement concurrent code with multiple processes.

Forks are, compared to threads, extremely slow in their creation, regardless of the platform. A fork on a unix system creates a new process and AFAIK, it completely copies the call stack and memory in the process. Threads on the the other hand use the same memory but require other methods to control concurrency (Mutex semaphores, etc.). And any thread/process/context change involves CPU interaction, only that a thread change doesn't necessarily mean that the memory map has to be switched out as long as the thread in question belongs to the same process as the previous one.
Originally by: lucy9
So it is quite lol really that Python doesn't like threads, and it's being run on Windows - which doesn't like forking Laughing

Windows isn't the issue here, its Python's lack of real support for multi-core/MP/SMP systems because of the GIL.
--
EVE Mobile Skill Planner V3 !!
http://evemsp.sourceforge.net/]]> Wed, 24 Sep 2009 20:17:00 +0000 eve-search/guid/8817292 <![CDATA[RE: Infiniband - Do it do it...just do it. - by lucy9]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#375 Originally by: Dr Slaughter
Originally by: Pan Crastus
Also, lol, CCP is using Windows on the servers as far as I know.

Well.. as far as you know.. WOW. They use Windows as FAR AS YOU KNOW...

WTF. We all KNOW it runs on Windows. So thanks for adding that gem of information.


Creating a new process in Windows is really really really slow as is task switching, so the only suitable option for concurrency is threads.

Unix forks are pretty quick as are task switches, so it's a reasonable alternative to implement concurrent code with multiple processes.

So it is quite lol really that Python doesn't like threads, and it's being run on Windows - which doesn't like forking Laughing
]]> Wed, 24 Sep 2009 20:01:00 +0000 eve-search/guid/8817137 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Jaabaa]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#374 Originally by: Bartholomeus Crane
I think when you said multi-threaded, you mean concurrent. In the common meaning, threads are usually one CPU only.

Not really, IMO multi-threading = concurrent. If you have a multi-core/MP/SMP system then the concurrency of operation *should* be invisible to the application, but that may be going slightly off topic Smile
--
EVE Mobile Skill Planner V3 !!
http://evemsp.sourceforge.net/]]> Wed, 24 Sep 2009 19:08:00 +0000 eve-search/guid/8816848 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Xessej]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#373 Originally by: Bartholomeus Crane
I'm not in complete disagreement, I just don't agree with the focus. I DO believe that components of the code should be coded in C/C++, but not for performance reasons, as I don't think there's that much to gain from such an exercise.

I think you misunderstand how considerable the performance gains can be in a large system. For instance duck typing adds considerable overhead to every method invocation while static typing handles this in the compiler at compile time. Even a couple of hundred clock cycles per method invocation adds up when you're talking about a system as large and as complex as server side Eve.
]]> Wed, 24 Sep 2009 19:07:00 +0000 eve-search/guid/8816847 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Bartholomeus Crane]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#372 Originally by: Jaabaa
With Python's GIL being the way it is, it seems that CCP has their work cut out for them making the server code SMP/MP or even multi core capable Confused


You got that right :)

Quote:
It would be fantastic if every grid was on it's own process/thread but as I understand it the whole solar system is running on a single thread on a single CPU, regardless of the HW capabilities present.


Well, as I see it, all ships have their own thread, but several systems are run on a single CPU, but all this multi-threading doesn't make a shred of difference, as all the threads are run in serial anyway. It's just easier to understand the programming that way.

Quote:
We have to be aware of some of the real lag causing issues though:

  1. When you enter a system, your client has to load all of the state information for that system, other ships, characters in local, your bookmarks, etc..

  2. When you enter a grid, your client has to retrieve all the state information for all of the ships and all of the objects present in the grid.

  3. Anyone firing a weapon, taking damage, changing direction and what ever else causes a change in the current game state has to be broadcasted to all the clients in the grid and possibly the system (docking, jumping, etc).



I don't see how you can avoid 1 and 2, as you simply need that information to do function in the world. Although on the positive side, a lot of that information loading is delayed until you use it.

As for 3, yes, that's a huge bottleneck. there's a lot of interaction between ships, they all need to know things from each other, and talk to each other. Which is why I think this can only be done efficiently on one CPU. Even with Infiniband, this exchange of information will create a huge problem if everything is distributed.

Quote:
I really do think that having a real multi-threading solution would help in heavily populated systems (like Jita) but I don't want to think of the programming difficulties that would have to be addressed when trying to coordinate the events inside of a single grid (i.e. fleet battle) when using the multi-threaded paradigm.

Its all a lot harder than "upgrade the hardware" or "switch the language".


I think when you said multi-threaded, you mean concurrent. In the common meaning, threads are usually one CPU only. But yes, the 'interaction' problem is the big bottleneck IMHO. Which perhaps means that you should make all the other stuff concurrent and out of the way, leaving you, in the worst case scenario, with nothing but the code handling the interaction on one node, and all the other stuff distributed to other CPUs. It's probably overstating it, because at least some other stuff will have to be there, but if I'm right, and the 'interaction' is the big bottleneck, it makes sense to do it like this.

Anyway, theorycrafting again ...
--
Quis custodiet ipsos custodes?
]]> Wed, 24 Sep 2009 19:00:00 +0000 eve-search/guid/8816801 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Bartholomeus Crane]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#371 Originally by: Xessej
Originally by: Bartholomeus Crane
OK, my reply got mangled by the forum, as I wasn't finished writing this post while I was called away and it was posted it anyway.

However, I don't think it would have made any difference. You're clearly convinced that simply rewriting EVE in C/C++ will make all lag problems disappear, and I, obviously, think that's a load of bunk. So in all good grace, why don't we just agree to disagree, and leave it at that?

That's a misstatement of my position.

What I'm saying is there is a significant performance gain to be realized by going to a more efficient language. This is a big undertaking but IME it is far simpler than rewiring computers or developing a new network protocol or whatever the infiniband project is really doing on the server to server connectivity side.


I'm sorry, I didn't want to misrepresent you, but this is what I got from the discussion so far.

I'm not in complete disagreement, I just don't agree with the focus. I DO believe that components of the code should be coded in C/C++, but not for performance reasons, as I don't think there's that much to gain from such an exercise.

Instead, I think components should be written in C/C++ to circumvent the GIL through extensions, so that, in connection with some middleware, call it MPI, or I/O distributor, or scheduler, or load-balancer, or whatever, concurrency over multiple cores/CPU can be used. It's not a clean solution, but could provide the best of both worlds. You could use Python to have all the micro-threads and message handling and leave the basic code untouched, but leave the actual calculations of combat and such to C/C++ coroutines distributed over the cluster. It's not pretty, and certainly not ideal, but it would allow distribution of the core calculations of handling a grid/system to be distributed over the rest of the cluster, with leaving a large portion of the code untouched. At the same time, it would leave the basic knowledge base as it exists in CCP (which concerns Python) in tact as well.

Infiniband, in that context, would greatly enhance the performance of that middleware by cutting away a lot of the latency inherent in such types of setups.

Whether this is worthwhile depends on developments within Python, which is anyone's guess. Obviously, if Python where to drop the GIL elegantly tomorrow, and become Erlang-like concurrency supporting, it wouldn't. But the chances of that happening are rather slim it would seem.
--
Quis custodiet ipsos custodes?
]]> Wed, 24 Sep 2009 18:45:00 +0000 eve-search/guid/8816647 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Jaabaa]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#370

It would be fantastic if every grid was on it's own process/thread but as I understand it the whole solar system is running on a single thread on a single CPU, regardless of the HW capabilities present.

We have to be aware of some of the real lag causing issues though:

  1. When you enter a system, your client has to load all of the state information for that system, other ships, characters in local, your bookmarks, etc..

  2. When you enter a grid, your client has to retrieve all the state information for all of the ships and all of the objects present in the grid.

  3. Anyone firing a weapon, taking damage, changing direction and what ever else causes a change in the current game state has to be broadcasted to all the clients in the grid and possibly the system (docking, jumping, etc).



I really do think that having a real multi-threading solution would help in heavily populated systems (like Jita) but I don't want to think of the programming difficulties that would have to be addressed when trying to coordinate the events inside of a single grid (i.e. fleet battle) when using the multi-threaded paradigm.

Its all a lot harder than "upgrade the hardware" or "switch the language".
--
EVE Mobile Skill Planner V3 !!
http://evemsp.sourceforge.net/]]> Wed, 24 Sep 2009 18:44:00 +0000 eve-search/guid/8816646 <![CDATA[RE: Infiniband - Do it do it...just do it. - by Xessej]]> http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=682229&page=13#369 Originally by: Pan Crastus
Originally by: Xessej

Simply put C/C++ code is faster than interpreted code no matter the language. Since performance is an issue here this needs to be considered.


Getting theoretical now - your statement is certainly true for most practical problems and corresponding solutions in C/interpreted languages, in theory though the latter can often be optimized better using information available only at runtime (read up on "partial evaluation") and then dynamically compiled to native code with comparable speed as C but with a specialized program for the actual input. One of the problems atm. is that "good" compilation to native code is still comparatively slow.

In short: statically compiled programs are at a disadvantage compared to dynamically compiled ones, although current dynamic compilation technology (for interpreted languages) hasn't really managed to reap these theoretical benefits.

Sorry for the nit-picking. ;-)

(PS. as an exercise for the reader: write a C function that computes something from its arguments only (should take a while). Compare a program containing this function that takes args from the command line with a program that reads "function calls" from stdin, then generates a C file containing the function and a main() containing the function call with explicit arguments and compiles that C file as a .so/dll, then loads it using dlopen() and prints out the results. Which way of calling the function results in faster execution?)

I've seen those claims but as you admit none of the dynamic compilers has yet achieved the results predicted. Personally writing a dynamic compiler that writes super efficient code on the fly such that the compile time + execution time is faster than can be achieved with a statically compiled program seems to be a problem of sufficiently high complexity that it may not be possible to write such a solution at this time.

But I will point out that a dynamically compiled language is not an interpreted language even if they share the same syntax a