Server Tech

[torgum]

What kind of server tech will be needed for the emu?
multicore-highend-i-need-my-own-power-plant-machine ?
What about the operating system?

[ZexisStryfe]

generally speaking the server you need is all dependant upon how many players you are expecting. If this EMU follows the EQEMU model on server side, which i believe it is, you load a certain number of dynamic zones by default. The more zones, the bigger hit. When you start adding static zones to that, you take bigger hits since they are always active. That said however, I fully expect a gaming desktop to be able to run the EMU without problems, as long as you don't expect SoE like response times.
Personally, the server I have set up for it is a P4 3.6 ghz, with 2 gb of RAM and PCI-E vid card (nvidia6900) running Windows 2003 server.

[techguy84]

Its going to boil down mostly to RAM and Bandwidth.
More RAM means more zones can boot up, which means more areas for more players. More Bandwidth means your internet can handle more outbound data for more players to use.
CPU is somewhat of a factor, but any prev-gen processor will work, like P3, P4, Athlon. It doesnt need to be bleeding fast, but faster does help. Dual Core wont matter as the emu is a single core program. Could be made into dual, but it will only apply to the truly hardcore MMO servers.
HD space is kind of a given. EQEmu took about 1-1.5 GB of space because of map files. Most servers should do fine by this amount. The only thing that is goign to grow is your DB, but not by much.
Graphics cards do not matter on the server front. You only need something display a command window.
Now if you plan on running a server on the same comp as EQ2, you of course will need a beefy system as EQ2 has steep requirements anyhow. I know when i play, I try to cut out all other processes to maximize performance, so for me, I will be running server on another computer. p4 1.7, 756MB Ram, 20G IDE, Radeon 7000 AGP (funny I know). This computer will be more than adequate to hold the server and run it fairly well.

[LethalEncounter]

To clear up some confusion: As it is being designed right now, you will only need to run one world.exe to run a server. Because instances are a very large part of EQ2, it doesnt make sense to start a new zone program for each instance like eqemu. Instead, once it is completed there will be a configurable amount of zones that are always up and never spawn instances like on live (city zones) in addition to the regular instances that spawn a new instance as needed. I also also thinking about having a configurable option that will give zones high priority than other zones. Obviously combat instances will be more time critical that someone running through a city zone. No matter the type of zone it is, the zone will be an additional thread created from world. There are some benefits and some drawbacks to doing this:
Benefits:

• Reduced total memory used for 'X' number of zones, increasing number of zones that can be run per machine

• Reduced number of windows opened

• Increased performance

The only drawback I can think of really is that the stability of world might suffer if a single instance crashes, but with properly exception handling and well debugged code we should be able to prevent that from happening. We have tried to balance performance with reliability and ease of use as much as possible.
As far as dual core processors are concerned, Windows "should" automatically share the work load between them. I havent looked it up lately, but AFAIK windows should take care of that automatically. That is one of the purposes of an operating system. Linux (yes, world will be multi-platform), however I dont have a clue about.

[Cadimiom]

To clear up some confusion: As it is being designed right now, you will only need to run one world.exe to run a server. Because instances are a very large part of EQ2, it doesnt make sense to start a new zone program for each instance like eqemu. Instead, once it is completed there will be a configurable amount of zones that are always up and never spawn instances like on live (city zones) in addition to the regular instances that spawn a new instance as needed. I also also thinking about having a configurable option that will give zones high priority than other zones. Obviously combat instances will be more time critical that someone running through a city zone. No matter the type of zone it is, the zone will be an additional thread created from world. There are some benefits and some drawbacks to doing this:
Benefits:

• Reduced total memory used for 'X' number of zones, increasing number of zones that can be run per machine

• Reduced number of windows opened

• Increased performance

The only drawback I can think of really is that the stability of world might suffer if a single instance crashes, but with properly exception handling and well debugged code we should be able to prevent that from happening. We have tried to balance performance with reliability and ease of use as much as possible.
As far as dual core processors are concerned, Windows "should" automatically share the work load between them. I havent looked it up lately, but AFAIK windows should take care of that automatically. That is one of the purposes of an operating system. Linux (yes, world will be multi-platform), however I dont have a clue about.

The way things are now as long as each zone process is handled with try-catch it will have no effect on the world server or any other zone servers connected.
Plus now that threading is used for each individual zone, it is easily possible to change the priority of the thread for individual zones. Finally for multicore processing, it may require some additional programming and personally I don't know if there may be difference between Intel and AMD multi core processors. I am only somewhat familiar with Intel's methodology through the Threading Building Blocks (http://www.threadingbuildingblocks.org/).
Until we start having advanced systems like NPC movement, aggro, and heavy combat I don't see any problems with cpu or memory usage. So multi-core can be coded a bit later on.

[ZexisStryfe]

As far as multi cores go, there are some differences that i have noticed across various computers with different CPUs. Intel Pentium D processors seem to be the problem child due to the lack of a communication bridge between the two cores (the data must travel out into the MB to communicate between cores. Also, the FSB was not doubled to deal with the increased data flow. On these CPUs I notice the primary core will hit 95%+ before the second core starts to take a significant load (40%+). Core 2 Duos and AMD x2s are different. These processors share the onboard cache (Duos at the L2 lvl and AMDs via a crossbar)and that acts as a communications bridge along with the doubled FSB. Because of this most apps tend to properly balance out between the cores. Theoretically however, any application which supports multi-threading will use both cores and work properly on a Windows based dual core system. Again, like LE, I can't speak for Linux.
Coincidently, one of the apps that seems to max out one core first even on the Duos and x2s just happens to be EQ2, so who knows.

[masterfreek64]

I don't think you even need special libraries to have multiprocessing support. Most modern OS (I have definitely seen it on some unix thingy , also i dunno what specifically ) automatically schedule the individual threads to the CPUs so as long at it is multithreaded the OS will distribute the threads to all CPUs.

[techguy84]

Correct me if I am wrong though, but doesnt there have to be some code in the emu to support multi threading or multi cores. I know Windows can balance the load amongst two cores, but its ineffecient at best. I figured it the emu was written specifically with a dual core patch, it could better execute things on both cores, far better than Windows could on its own.
Maybe I am completly wrong on this, I have not really dove deep into what makes Dual Cores work effeciently, just going off of the knowledge I currently have.
Anyhow though, with a good processor that is dual core, like a C2D, its really not going to matter as the emu is not likely to be a huge resource hog, like a video encoder or something.

[LethalEncounter]

I dont think that is correct. It *might* be possible to take away an OS function like that and manage it yourself, but I really doubt it would help anything. In fact it would more than likely crash your OS. The emu is multi-threaded. It has to be to handle multiple clients and zones.

[alfa]

It's depend of application for exemple as far I know EQ2 Client not assume Multi processing (I have an Core2Duo with Vista and EQ2 Client nos use the 2 core...)

[techguy84]

I know some apps are written to take better advantage of dual/quad core CPU's, other than Windows/Linux assign threads to each core on its own. Oh well, Im changing my name to something else, pfft.