<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2180" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Mark,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I will give you all three servers for 200.00 a
month.</FONT></DIV>
<DIV><FONT face=Arial size=2>2- 24 man servers</FONT></DIV>
<DIV><FONT face=Arial size=2>1 -32 man uo server</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>;-)</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV> </DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=defilm@acm.org href="mailto:defilm@acm.org">Mark J. DeFilippis</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=cod@icculus.org
href="mailto:cod@icculus.org">cod@icculus.org</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Sunday, September 26, 2004 9:50
AM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [cod] Semi off topic: COD
rentals</DIV>
<DIV><BR></DIV><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. 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. 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. 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 class=cite cite="" type="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 class=cite cite="" type="cite"><BR>If you are executing the
same executable and can use parameters on the command line that
is<BR>fine. It is the same inode. 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. 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) 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 class=cite cite="" type="cite">But we execute the same
binary in the same path for each server&? Why the
symlink?<BR><BR> <BR><BR>------------------------------------<BR><BR>Chris
Adams<BR><BR>Fragzzhost<BR><BR> <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> <<A
href="http://www.fragzzhost.com/"
eudora="autourl">http://www.fragzzhost.com</A>><BR><BR> <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> <BR><BR><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><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!
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><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.
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><BR>----------------------------------------------------------------------------<BR><BR>S2-------------------------------------------------------------------------------<BR>Mark
J. DeFilippis, Ph. D
EE
defilm@acm.org<BR>
defilm@ieee.org</BLOCKQUOTE><BR>S2-------------------------------------------------------------------------------<BR>Mark
J. DeFilippis, Ph. D
EE
defilm@acm.org<BR>
defilm@ieee.org<BR><BR></BLOCKQUOTE></BLOCKQUOTE><X-SIGSEP>
<P></X-SIGSEP><TT>-------------------------------------------------------------------------------<BR>Mark
J.
DeFilippis
defilm@acm.org<BR>
defilm@ieee.org<BR><BR><BR></TT></P></BLOCKQUOTE></BODY></HTML>