<html>
<body>
<br>
You are thinking application level. 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. An inode is a
unique<br>
identifier for that file. 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. (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. All Linux cares about
is that<br>
inode number.<br><br>
anyway... If you symlink the two server files, and now do a "ls
-li",<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. When the second
server<br>
is executed, even though the file has a different path, it has the
same<br>
Inode. 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. Using the method of symlinks, which<br>
is really nothing more than a link in the super block. The super
block<br>
maintains all information about which disk blocks belong tio which<br>
files. For your simlink the new file entry simply gets the
same<br>
inode id copied to the table. Same inode, same code... With<br>
shared libraries in memory, 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>
<blockquote type=cite class=cite cite>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>
<blockquote type=cite class=cite cite>Woah......now there's a guy who
knows his stuff! Awesome tips man! You<br>
really explain things well. 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 "Sticky" bit on the executable. (Do a man on
"mode" 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. 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 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 "sticky")... 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>
registers CS, ES. 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. I did some research on the
internet<br>
and a lot of peeps are doing symlinks. I tried it with MOH:AA and
it works<br>
beautifully, not sure if that's the "right" 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>
<br><br>
<blockquote type=cite class=cite cite>-----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. 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 "server
rental"<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 "virtual linux" 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>
<br>
</blockquote>----------------------------------------------------------------------------</blockquote></blockquote>
<x-sigsep><p></x-sigsep>
<tt>S2-------------------------------------------------------------------------------<br>
Mark J. DeFilippis, Ph. D
EE
defilm@acm.org<br>
defilm@ieee.org<br><br>
<br>
</body>
</html>