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