[cod] Semi off topic: COD rentals
Mark J. DeFilippis
defilm at acm.org
Sun Sep 26 12:50:45 EDT 2004
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/3dc16f59/attachment.htm>
More information about the Cod
mailing list