open All Channels
seplocked EVE Information Portal
blankseplocked New Dev Blog by Explorer - More on StacklessIO and HARDWARE!
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: 1 [2] 3

Author Topic

CCP Explorer

Posted - 2008.10.01 20:01:00 - [31]
 

Edited by: CCP Explorer on 01/10/2008 20:01:40
Originally by: Tipz NexAstrum
Originally by: CCP Explorer
Finally there is a pool of dedicated dual-CPU, dual-core, machines that only run a single EVE64 node per machine
How does that work? If the solar system process can't be split over multiple CPU's then what is the second CPU doing?
There is a backup node running on each of these machines.

CCP Explorer

Posted - 2008.10.01 20:04:00 - [32]
 

Edited by: CCP Explorer on 01/10/2008 20:05:35
Originally by: Blyghme
Excellent, Well done CCP. Does this mean that we can have a 64bit client now?Smile
There is more 3rd-party middleware in the client than the server, for which we do not yet have 64-bit versions.

Chaos Incarnate
Faceless Logistics
Posted - 2008.10.01 20:46:00 - [33]
 

Are the uber superhamster-nodes that aren't Jita kept on standby elsewhere for fleet battle replacement, or do they support other tradehubs?

Hikaru Kobayashi
Posted - 2008.10.01 21:23:00 - [34]
 

Originally by: swoj
Isn't this just a case of changing the build output option to 64bit, then build and test? Or was the communication between 32bit and 64bit parts of the cluster a completely unknown factor?


Indeed, communication with 32-bit code (e.g. the client!) needs to happen in the correct format. Also, the increased integer size may cause other issues, such as that adding 0xFFFFFFFF to a number equals subtracting -1 on a 32-bit system, or XOR-ing by that inverts the number, but in 64-bit code the results are different. Also, when looping over and processing a certain amount of data (e.g. 64k), the loop needs to be half the size because a register can contain twice as much, etc.. I would imagine that when trying to port code to 64-bit this causes bugs which can be a little hard to track down.

Originally by: swoj
Will having a 64bit client make much difference? I don't have any apparent problems running the current client on Vista64, memory certainly isn't a problem just now, so I'd guess performance would not be improved much, if any.


Well, the 64-bit instruction sets have more internal registers available, so there is less memory I/O needed. Theoretically that should boost performance a little. But yeah, I guess memory size is not an issue for the EVE client, it stays well within 4GB. Though on a 64-bit OS like I’m running, maybe there are additional advantages to having the game running in the ‘native’ instruction set, I don’t know…

John McCreedy
Caldari
Eve Defence Force
Posted - 2008.10.01 21:35:00 - [35]
 

Can you fellas start making two blogs. The normal one and one that actually contains no technobabble? Razz


Mr Horizontal
Gallente
Posted - 2008.10.01 21:38:00 - [36]
 

So with 64 bits, does that mean we can finally issue dividends bigger than 2,147,483,648 ISK (Max unsigned Int32)?

Athanasios Anastasiou
The Illuminati.
Pandemic Legion
Posted - 2008.10.01 21:49:00 - [37]
 

Originally by: Mr Horizontal
So with 64 bits, does that mean we can finally issue dividends bigger than 2,147,483,648 ISK (Max unsigned Int32)?


Actually, that's a signed int iirc.
I think they will have to patch the client as well for that.

Imagine impossible autopilot routes that currently takes 2,147,483,647 jumps become 2^63 jumps away :P. The number of jumps would take up a quarter of the screen.

I can't believe there's more fanfare about this on scrapheap then here.

Havok Pierce
Gallente
Aperture Harmonics
K162
Posted - 2008.10.01 22:38:00 - [38]
 

Any chances on tossing up a white paper on this or StacklessIO (or linking to it if it's an imported tech from elsewhere)? Or should I just go patent-hunting?

Ishina Fel
Caldari
Terra Incognita
Intrepid Crossing
Posted - 2008.10.01 22:51:00 - [39]
 

Im interested in this "missing the heartbeat" thing.

Does that mean the node crashed, and was disconnected to prevent cascades, or does it mean it went out of sync and had to be restarted to regain synchronity? Or did the CPU simply get backed up past a certain treshold of queued commands from overcrowding?

McFly
Peanut Factory
Posted - 2008.10.01 23:26:00 - [40]
 

Thumbs Up CCP, <Insert random request about something else here>, Go get a beer, I'll let u know if the whole thing comes crashing down while you're away.

--McFly--

Miss SmartyPants
Tollan Technologies
Posted - 2008.10.01 23:29:00 - [41]
 

Very interesting blog, thanks for taking the time to write it. Very Happy

I have a somewhat unrelated question - since I work in a datacenter ("closer" to the EVE one than one might think Wink) I'd find it really interesting if we could get some more information about the actual hardware - for example number of blades/blade centers used, occupied rack space, power consumption of the whole suite/cage where everything is located, total HDD capacity of the whole system or various parts of it (like market, database, petitions etc) and other similar bits of information for us geeks to wet our pants at. ugh

CCP Explorer

Posted - 2008.10.01 23:35:00 - [42]
 

Edited by: CCP Explorer on 01/10/2008 23:38:32
Originally by: Ishina Fel
Im interested in this "missing the heartbeat" thing. Does that mean the node crashed, and was disconnected to prevent cascades, or does it mean it went out of sync and had to be restarted to regain synchronity? Or did the CPU simply get backed up past a certain treshold of queued commands from overcrowding?
The nodes often need to communicate with other nodes and if they don't get a response because a node is inaccessible then requests will start building up.

Every node in the server cluster must report at very regular intervals to the database. If the other nodes discover that a significant amount of time has passed since the last heartbeat from a particular node then the cluster integrity watchdog will remove that node from the cluster and remap its solar systems to backup nodes. It will then restart that node and integrate back into the cluster as a backup node.

The server logs from the fleet battle gave us enough information on why the node missed its heartbeat and we are working on fixing it.

Bernman
Posted - 2008.10.02 00:41:00 - [43]
 

Great work guys!

Thanks for your efforts and keeping us informed.

Bernman

matarkhan
Suprema Exstinctio
Numerus Ruina.
Posted - 2008.10.02 01:20:00 - [44]
 

Edited by: matarkhan on 02/10/2008 01:31:13
Quote:
The server nodes will run a mix of 32- and 64-bit nodes since most nodes in the cluster don't have memory requirements requiring EVE64.


So what's the situation with 0.0 nodes that tend to spike for fleet battles? What I'm wondering is:

1) Are systems that are *known* battle hotspots being moved to 64bit?
2) Can nodes that were previously quiet and now see massive fleet battles be shifted?
3) Is someone/some system watching for this kind of activity to proactively prepare the nodes for heavy use?

I understand that hardware's not cheap, but if you've got a system in place to handle massive fleet battles, and fleet battles continue to experience lag/node death, people are going to get ****ed.

Not that we don't appreciate the work you've done here, we do. It's a little disconcerting to find out that we waited ALL this time for something that you did in a week, but at the same time I recognize that you may have been waiting for the technology to become available.

I just hope that you're taking all of this into account for implementing it.


Thanks folks.

Steely Dhan
Perkone
Posted - 2008.10.02 01:55:00 - [45]
 

Edited by: Steely Dhan on 02/10/2008 02:11:55
Edited by: Steely Dhan on 02/10/2008 02:10:02
"This Monday, 29 September, we saw a fleet battle with over 1100 pilots reported in local. Field reports indicate that the fight was quite responsive for the first 10 minutes but then the node "missed its heart beat" as we call it and was removed from the cluster by our cluster integrity watchdog routines. This again is another exciting problem as we can address that as well under our StacklessIO world and that will be the subject of the next blog".

Holding my breath not.

I for one am glad you were excited..I wasn't. The prospect of ratting another 8hrs to replace my ship and fittings doesn't fill me with pleasure.

However it's great you are addressing the problem but it seems quite a few paid in isk to beta test so to speak. Maybe you could have had a 1000+ fleet battle on SIS instead of using a fight over vital territory

Reptzo
Channel 4 News Team
Veritas Immortalis
Posted - 2008.10.02 05:12:00 - [46]
 

Originally by: Steely Dhan
Edited by: Steely Dhan on 02/10/2008 02:11:55
Edited by: Steely Dhan on 02/10/2008 02:10:02
"This Monday, 29 September, we saw a fleet battle with over 1100 pilots reported in local. Field reports indicate that the fight was quite responsive for the first 10 minutes but then the node "missed its heart beat" as we call it and was removed from the cluster by our cluster integrity watchdog routines. This again is another exciting problem as we can address that as well under our StacklessIO world and that will be the subject of the next blog".

Holding my breath not.

I for one am glad you were excited..I wasn't. The prospect of ratting another 8hrs to replace my ship and fittings doesn't fill me with pleasure.

However it's great you are addressing the problem but it seems quite a few paid in isk to beta test so to speak. Maybe you could have had a 1000+ fleet battle on SIS instead of using a fight over vital territory


While I agree that doing these things on the test server would be best. It is often extremely difficult to replicate actual scenarios in the lab (test server). Mainly it is hard to have a node go from minimal usage to massive overload, and get the people to do what they would actually do on the real server. It would be very hard to get 1100+ people on the test server to stay logged in, and trying to fight for a few hours, while things kept dieing.

So, in one sense yes it sucks that we the players are "beta" testing as you call it. But, if this only has to happen once or twice per "problem". Than I would say it is worth it in the long run.

Irongut
Sex Money Guns
Posted - 2008.10.02 05:32:00 - [47]
 

Another great tech blog and follow up answers. Keep up the good work Explorer!

Originally by: CCP Explorer

The server logs from the fleet battle gave us enough information on why the node missed its heartbeat and we are working on fixing it.


The logs showed something!?!?! OM the sky is falling! Laughing

PewPewLePewPew
Posted - 2008.10.02 06:14:00 - [48]
 

Missed its heartbeat = node crash?


Great to see the dev blogs cranking out though =D Hopefully this quiets the "CCP isn't fixing lag" whiners.

Franga
NQX Innovations
Posted - 2008.10.02 07:08:00 - [49]
 

This is the type of dev-blog we were looking for.

Huan CK
Gallente
Garoun Investment Bank
Posted - 2008.10.02 07:47:00 - [50]
 

Wow, another great blog. Guys, you really have to keep the blogs flowing at that rate ;) It's awesome. So, while you're all working on 64bit on the server, when do we get 64bit versions of the client :)

Silevran Levanadel
Gallente
Posted - 2008.10.02 08:32:00 - [51]
 

Very HappyYay! New dev blog.Very Happy

Good job on taking on the "beaten-with-ugly-stick" lagmonster.

Way to go guys, i'm impressed

Sincerely

Silevran

Cergorach
Amarr
The Helix Foundation
Posted - 2008.10.02 08:52:00 - [52]
 

I'm curious, with the advent of servers with 16GB on board for high traffic systems, is memory still the limiting factor, or is processing speed the limiting factor? If it's the memory, are you looking at motherboards that support more then 16GB of memory?
This Intel Xeon based one supports 128GB
This Intel Xeon MP based one supports 192GB
This AMD Opteron based one supports 128GB
This AMD Opteron MP based one supports 256GB

If processing speed is a limiting factor, have you considered overclocking the processors for high traffic systems (with adequate cooling)? While overclocking isn't generally attempted with a server, if you absolutely need the extra speed, it might be an option worth considering for a select few systems. The added cost of maintainability (and possibly failure) might be outweighed by the user experience, and possibly new users attracted by the smooth Eve Online experience...

Chavu
Minmatar
GK inc.
Posted - 2008.10.02 09:15:00 - [53]
 

WIN WIN WIN WIN WIN WIN WIN WIN WIN.

LaVista Vista
Conservative Shenanigans Party
Posted - 2008.10.02 09:25:00 - [54]
 

Once again, very amazing blog.

The question quickly arises about how you now apply this to "random" systems on the fly. 0.0 fleet fights can happen anywhere, and it would be awesome to have this kind of performance everywhere if at all possible.

Are you guys now able to move a system to a 64-bit node if you have to? Or will these systems have to be allocated during a downtime?

I'm very excited about the future. It sure seems like lag will be a thing in the past inside the scope of this year/early next year Very HappyCoolShocked

MotherMoon
Huang Yinglong
Posted - 2008.10.02 10:56:00 - [55]
 

Originally by: LaVista Vista
Once again, very amazing blog.

The question quickly arises about how you now apply this to "random" systems on the fly. 0.0 fleet fights can happen anywhere, and it would be awesome to have this kind of performance everywhere if at all possible.

Are you guys now able to move a system to a 64-bit node if you have to? Or will these systems have to be allocated during a downtime?

I'm very excited about the future. It sure seems like lag will be a thing in the past inside the scope of this year/early next year Very HappyCoolShocked


you should know better people will bring more people into fleet fights. AS in 1000 on 1000 fights.

hopefully this won't happen to offen and normal sized fleet fights will be flawless thoughVery Happy

Niraco79
Gallente
Black Nova Corp
IT Alliance
Posted - 2008.10.02 11:23:00 - [56]
 

Edited by: Niraco79 on 02/10/2008 11:25:06
hope you guys adress the fact that most players that try to log in in a system with a battle will not be able to even the battle is with 350 in local (seen in M-O next day).

Lord EmBra
Cutting Edge Incorporated
RAZOR Alliance
Posted - 2008.10.02 11:51:00 - [57]
 

Originally by: Niraco79
Edited by: Niraco79 on 02/10/2008 11:25:06
hope you guys adress the fact that most players that try to log in in a system with a battle will not be able to even the battle is with 350 in local (seen in M-O next day).

This, and perhaps change the login priorities a bit. The ship should be the last thing to "spawn" ingame when logging in, you shouldn't be able to be shot and killed while still looking at your character selection screen.

Astria Tiphareth
Caldari
24th Imperial Crusade
Posted - 2008.10.02 13:57:00 - [58]
 

Edited by: Astria Tiphareth on 02/10/2008 14:00:20
Superb blog and as a dev myself, I can't help but find this sort of stuff fascinating.
Originally by: CCP Explorer
We are currently working with our vendors on testing out even more powerful hardware options now that we can utilise the hardware much better.

How does this relate to the Infiniband project? I presume the two are concurrent - i.e. you're improving existing hardware whilst looking at ways to completely revamp the system?

Chainsaw Plankton
IDLE GUNS
IDLE EMPIRE
Posted - 2008.10.02 21:18:00 - [59]
 

zomg so many new dev blogs Very Happy

and the next devblog sounds like infiniband (or w/e you guys are calling it) Twisted Evil

Zex Maxwell
Caldari
Posted - 2008.10.03 02:55:00 - [60]
 

Does this mean, you will have a 64 bit client soon? I am running 64bit vista right now. I would love to have all my games to use all my ram if need be.


Pages: 1 [2] 3

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only