EQemu on Cobalt servers

[razorz]

I seem to have found a certain infatuation with the cobalt raq servers and it isn't healthy. They aren't the greatest machines in the world and I am not the biggest fan of linux *couldnt get EQemu to compile on Solaris, if anyone has got it working on Solaris9/10 SPARC64 please let me know, I could put up a 8-14CPU Enterprise 4500 machine with 4gigs of ram to host quite a few players ;)*

Onto the real topic. How CPU intensive is EQemu in general? I can put together a cluster of about 4-8 Cobalt RaQ machines lower end with 512mb ram each to run EQ-Emu stuff for fun. The problem with these machines is they are usually only 450MHz or so *for the lower end, I am not gonna buy 4-8 of the high end ones, would cost too much*. Any top information from machines in the 450mhz range and above would be appreciated. Along with system specs, ram usage, clients connected, zone servers up, etc. As much specific information as possible!

You can find me on the eqemu irc server under the nickname razorz :shock:

[kathgar]

oh yeah.. getting eqmu to compile on a sparc64 and solaris.. that would take some doing.. I don't think anyone on the dev team has much if any experience with either. There are the obvious endian issues. Not to mention standard library differences.

[Raumuth]

I have two UltraSparc II's. One running Redhat and one running Solaris 9. I use gcc instead of cc. You can get it here. http://www.sunfreeware.com/

The hardest part was getting gcc to complie but the above link will guide you in the right direction.

I have had successful builds with the eqemu .5.0 source on my solaris box (9-30-2003) but have not been able to complie the latest source (as of 10-7-2003) under windows, linux or solaris. I usually wait until I get a good complie under windows, then complie under linux, debug and then complie under solaris and debug.

If you are using cc I can't help you. I've had too many problems compiling with cc.

Other sites:
http://www.ultralinux.org/

[Doodman]

Raumuth,
There are the obvious endian issues.

Will cause you a lot of problems. Intel is little-endian and Sparc is big-endian. Just getting it to compile on Sparc will not get you a working EQEmu server

Example, in one of the packets the following is sent as the zone_id for Butcher Block:
44 00

On Intel you get (correctly):
68

On Sparc you get:
17408

Currently structures are "laid on top of" the data from the packets, they are not converted to/from network byte order, etc.

If you want to port EQEmu to Sparc more power to you, and please contribute back the changes. But it is not as trivial as a recompile.

[Raumuth]

If you want to port EQEmu to Sparc more power to you, and please contribute back the changes. But it is not as trivial as a recompile.

I didn't mean to trivialize the effort it would take to get eqemu working on a sparc. I am all too aware of cross-arc porting. It's just that gcc has compile options for little endian and big endian data (-mhard-float -mmultiple -mbig etc) for the the desired mode (something I was unable to do in cc). The newest version for gcc also has support for the ultrasparc cpu and I am familiar with the Solaris OS (I work on it everyday). And I believe he would have better luck using this setup.


oh yeah.. getting eqmu to compile on a sparc64 and solaris.. that would take some doing
My post was directed more at getting eqemu to compile and run under Solaris on an ultrasparc. Getting it to work.....well just give me some time 8) .

[kathgar]

Yes.. compile and work /properly/. I think I will sticky this thread though, good information

[krich]

To take a stab at your performance question...

I've found that CPU is less of a priority than memory, especially if you are running the DB on the same machine as world and zones.

If you are going to run multiple physical servers, an average server with lots of RAM for the DB server and then average servers for world and zone would probably suffice.

Conventional wisdom states that RAM has more effect on DB performance than CPU speed (from my ORACLE days). This is arguably so for MySQL as well.

UberTards, use common sense before flaming me, clearly a 486 with 8Gigs of RAM isn't what I'm talking about. :roll:

Regards,

krich

[kathgar]

I would love to see one of these 486s that can address 8 gigs of ram!

[razorz]

So many answers, so many options.. SO LITTLE MONEY..! =/ oh well, I'm pretty happy playing on the Fish-Wolf server at the moment so I believe I will avoid taking on the daunting task of maintaining my own EQemu server again.

Thank you all for the replies! :shock: :shock: :shock:

[darksnipe]

I have gotten some portions to compile correctly, however, I had to do a lot of converting by hand. Last time I scripted the conversion and I got way too many compiling problems. Unfortunately, I think it has to be done fat fingered entirely.

Theoretically, a Solaris 8 or 9 machine running 4-16 procs will own as far as performance goes. The code has to be rewritten to handle threading, memory, etc.

If I had a Sun that wasn't single proc, I think I'd take more time to do a server. For now I guess I'll just stay a slave to MS.

[w1ntermute]

i'm taking a stab at it with my two dual sparc IIs.. 384MB ram each (should be fun to try at least).. running debian on them both..