[cod] Semi off topic: COD rentals
Jay Vasallo
haze at clanwarz.net
Sun Sep 26 15:57:34 EDT 2004
Mark,
I will give you all three servers for 200.00 a month.
2- 24 man servers
1 -32 man uo server
;-)
----- Original Message -----
From: Mark J. DeFilippis
To: cod at icculus.org
Sent: Sunday, September 26, 2004 9:50 AM
Subject: Re: [cod] Semi off topic: COD rentals
Nor do I resell. But I must admit, between my current servers (2.4 Pent (NO HT), 100Mbs) I run 2 x 24 slot COD
for my clan. This server at EV1 runs me $149/mo. For UO, I just picked up a 3.0 Ghz Pentium HT, 1GB Ram, 100Mbs) for $119/mo, and it looks like it will only run the UO binary for about 24-30.
I was hoping I could run 2 x cod 24 man, plus the UO @ 1x24 man on the same server as I really can't
afford $300/mo for a clan of friends and my son's. That is getting to be serious $.
Er.. Sorry son... You have to go to community college... but you had Great servers for COD! ;-)))
I wonder if I should just upgrade to a Dual Xeon system. That should be able to handle
the 3. But if I do that, we are still talking $250+/mo. My wife is going to kill me!
I am open to any suggestions if someone wants to email me with any alternatives.
I pay for everything for the entire clan. With website, PHP code, flash, it is turning
in to a real big $$$ venture for fun...
Shared virtual servers, and by the slot I don't deal with anymore. There are
often have issues when they run a BFV server and some clan accidently turns on
Co-op mode and sucks the CPU dry impacting all other virtual servers on the host,
usually during a match.
Ironically.... I don't play.
Mark
At 11:31 PM 9/25/2004, you wrote:
Ok, thanks for clarifying that. I understand now. I have done the sticky thing on the executable :)
I dont run servers for rent just for myself and friends :)
Jase
Mark J. DeFilippis wrote:
If you are executing the same executable and can use parameters on the command line that is
fine. It is the same inode. The question I was answering was for a person who appeared to
not understand why, if Linux is in fact a multiuser/multi-tasking OS, what difference does
it make if I load from one file or many copies of the file.
In the scenario you present... if you are executing the same file, it is the same
inode. Make it sticky... and you have the same as the symlink scenario.
For those admins that wish to have a separate executable in the user
space (on perhaps a server where the admin choose to have the executable
in the users space with his other files and configs) the symlink method works
very well.
If your servers are being spawned by calling the same executable, you in fact
are correct, you get the same benefits. For added savings on load, make the executable
sticky, and your golden.
Dr. D
At 03:51 PM 9/25/2004, you wrote:
But we execute the same binary in the same path for each server&? Why the symlink?
------------------------------------
Chris Adams
Fragzzhost
T (07005) 964 855
F (07005) 964 857
www.fragzzhost.com <http://www.fragzzhost.com>
-----Original Message-----
*From:* Mark J. DeFilippis [mailto:defilm at acm.org]
*Sent:* 25 September 2004 20:33
*To:* cod at icculus.org
*Subject:* Re: [cod] Semi off topic: COD rentals
You are thinking application level. This is Kernel level.
I spent lots of time in my career developing real time embedded coding
in Unix/Linux kernels.
Look at two linuxded files that are not sym linked. But use this:
ls -li
Note the left side has a value called an inode. An inode is a unique
identifier for that file. Notice that your two files have different inodes?
When the loader goes to load code for your two servers using those
files, each is copied in to swap (so your swap space is n servers * sizeof executable)
The same is true of code segments.
If you sym link the two executables (Note they must be on the same
filesystem to do so. If you symlink two files on different file systems,
obviously Linux will have to copy the file to the new file system, and it
will have a new inode number. (This is because each filesystem has
it's own superblock, which maps Inodes to file blocks, and file names.
The filename if only for human consumption. All Linux cares about is that
inode number.
anyway... If you symlink the two server files, and now do a "ls -li",
notice the inode numbers are the same!
When you execute the server (with sticky bit on) it is copied to swap,
then pages copied in to ram and executed. When the second server
is executed, even though the file has a different path, it has the same
Inode. The linux kernel looks up the inode, and notes this inode has
the sticky bit set, and in fact that it already exists in Swap. It copies
the pointers to the code segments as I previously mentioned, and
begins execution.
You ask why?
Because 10 servers your way will load 10 copies in to swap, 10
copies in to memory, etc. Using the method of symlinks, which
is really nothing more than a link in the super block. The super block
maintains all information about which disk blocks belong tio which
files. For your simlink the new file entry simply gets the same
inode id copied to the table. Same inode, same code... With
shared libraries in memory, for the 10 servers only 1 copy
exists in swap. Only 1 copy exists in memory.
I hope this is more clear.
Dr. D
At 02:18 AM 9/25/2004, you wrote:
Guess im a little confuused here, why would you symlink when cod (all quake3 base games) support multiple users. using fs_basepath and fs_homepath accomplishes the same thing as symlinking doesnt it?
Jase
NateDog wrote:
Woah......now there's a guy who knows his stuff! Awesome tips man! You
really explain things well. Much appreciated.
--
NateDog
----- Original Message ----- From: Mark J. DeFilippis
To: cod at icculus.org
Sent: Friday, September 24, 2004 9:59 PM
Subject: RE: [cod] Semi off topic: COD rentals
I had written much about this a while back. I will repeat a bit of
it here for the sake of those who wish to do this. Want to know why
you should do this, why it works and a bit on how it works...
Linking the binaries allows the CPU to share the same Code segment pages.
Servers
will be allocated their own data segments for both Heap and Stack
(Which grow towards one another)... One of the reasons Ryan was able
to so quickly find that original prob back in 1.1.)
If there is a write attempt to the code segment, that server/user is given
their own copy. In the case of most of the shared libs in Linux, the code
is reentrant, and hence these writes don't happen.
One other recommendation, I am not certain if I made...
You can reduce the spikes you get when a server is restarted by
setting the "Sticky" bit on the executable. (Do a man on "mode" command)
What this does is the first time the executable is loaded, the entire
executable is copies to SWAP space. Once copied to swap, executable
pages are copied in to ram to be executed.
The best way to keep a server at optimum is to never have to page.
However, under certain conditions, this does happen. It the executable
is sticky, it remains in swap, and the page segment need only be
brought back in to memory from swap.
Also note, when a second and subsequent user of the Sym Linked executable
starts his/her server, the executable IS NOT copied in to swap again, it
uses
the one already in swap (hence the concept "sticky")... it sticks there.
Thus on new startup, A call is made to load the executable, however the
Kernel immediately updates the CS and ES code pointers to the shared
memory mbufs where the executable code exists, allocates a DS data
segment, and moves your process back to the scheduler for CPU as
your I/O is complete.
You skip the copy of the executable to SWAP.
You skip the copy of pages to Real RAM.
You execute off shared pages in memory already with your own set of
executable
registers CS, ES. Get your data segment, and your server starts up.
Not only do you save ram, but start impact on the other servers due to I/O
DMA transfer setup, and context switching between system and user space,
but you spare the CPU spike as well.
Regards
Dr. D
At 05:08 PM 9/24/2004, you wrote:
I just had that question recently also. I did some research on the internet
and a lot of peeps are doing symlinks. I tried it with MOH:AA and it works
beautifully, not sure if that's the "right" way to do it but it's pretty
cool cause' you have one base install and symlinks in the other client
folders.
--
NateDog
-----Original Message-----
From: John Kennington [mailto:john.kennington at buzzcard.gatech.edu]
Sent: Friday, September 24, 2004 3:04 PM
To: cod at icculus.org
Subject: RE: [cod] Semi off topic: COD rentals
Depending on the number of cpus in the box, you can run 10 to 15 CoD
servers per
box. So it is quite cost effective.
John Kennington
-----Original Message-----
From: Jafo [mailto:jafo at nowhere.ca]
Sent: Friday, September 24, 2004 3:58 PM
To: cod at icculus.org
Subject: [cod] Semi off topic: COD rentals
Hello,
If this isn't the forum for this question, please forgive me for asking
here.
There seems like a lot of people on this list that run "server rental"
operations. Just curious how people are doing that cost effectively?
Obviously one can't run each customer's game server on seperate hardware.
Are people using some sort of "virtual linux" installs to run multiple
servers on one box with seperate IP addresses? If that is the case how
many servers would one dual 2.4 Xeon w/2gig RAM run?
Thanks,
Jafo
----------------------------------------------------------------------------
S2-------------------------------------------------------------------------------
Mark J. DeFilippis, Ph. D EE defilm at acm.org
defilm at ieee.org
S2-------------------------------------------------------------------------------
Mark J. DeFilippis, Ph. D EE defilm at acm.org
defilm at ieee.org
-------------------------------------------------------------------------------
Mark J. DeFilippis defilm at acm.org
defilm at ieee.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/cod/attachments/20040926/33a36e35/attachment.htm>
More information about the Cod
mailing list