[cod] Semi off topic: COD rentals

Chris Adams chris at fragzzhost.com
Mon Sep 27 13:08:40 EDT 2004


Error?

---------------------------------------
Chris Adams
Fragzzhost
 
T (07005) 964 855
F (07005) 964 857
www.fragzzhost.com
 

-----Original Message-----
From: Jay Vasallo [mailto:haze at clanwarz.net] 
Sent: 27 September 2004 20:03
To: cod at icculus.org
Subject: Re: [cod] Semi off topic: COD rentals

I keep on knocking but I can't get in....


----- Original Message ----- 
From: "Chris Adams" <chris at fragzzhost.com>
To: <cod at icculus.org>
Sent: Monday, September 27, 2004 9:53 AM
Subject: RE: [cod] Semi off topic: COD rentals


> 
> Technically you shouldn't have to be logged in, but that tour is a bit
> out-dated.
> 
> http://cp.fragzz.com/fragzzPanel
> u: trial
> p: sparrow
> 
> That should give you a slightly better view of things :-)
> Let me know when you're done looking and I'll change the pass again...
I
> got bored of turning the server off every so often last time someone
> asked for the trial details :-)
> 
> ----------------------------------------------
> Chris Adams
> Fragzzhost
> 
> T (07005) 964 855
> F (07005) 964 857
> www.fragzzhost.com
> 
> 
> -----Original Message-----
> From: Jay Vasallo [mailto:haze at clanwarz.net] 
> Sent: 27 September 2004 19:05
> To: cod at icculus.org
> Subject: Re: [cod] Semi off topic: COD rentals
> 
> Hi Chris,
> 
> http://cp.fragzz.com/tour
> 
> Do I have to be logged in to see this? I would like to see it. We have
> one 
> almost done. Even thou it says sof2, it will work for any gamne with a

> config. But then this is the old one and not the updated one.
> http://www.clanwarzgamingservers.com/sof2/index.php
> 
> Anyone familar with kkron?
> 
> 
> ----- Original Message ----- 
> From: "Chris Adams" <chris at fragzzhost.com>
> To: <cod at icculus.org>
> Sent: Monday, September 27, 2004 8:55 AM
> Subject: RE: [cod] Semi off topic: COD rentals
> 
> 
>> Yeah we used to do things like that but since I've written the
>> all-powerful multi-gaming control system ;-) it handles all that for
> us
>> (thank god) so we don't really do anything with IPs and ports these
> days
>> since we have our master lists imported into a query / join program
>> luckily. Also it's a bit impractical on the larger boxes that can
hold
>> up to say 20 customers since most ISPs will only give up to 5 or 8
> free
>> IPs, if any at all and often less for dedicated servers.
>>
>> -------------------------------------------
>> Chris Adams
>> Fragzzhost
>>
>> T (07005) 964 855
>> F (07005) 964 857
>> www.fragzzhost.com
>>
>>
>> -----Original Message-----
>> From: Nathan P. [mailto:natedog550 at hotmail.com]
>> Sent: 27 September 2004 16:27
>> To: cod at icculus.org
>> Subject: RE: [cod] Semi off topic: COD rentals
>>
>> The main reason in my opinion for doing virtual interfaces is so that
>> you
>> can give each client their own IP - it still hits the same physical
>> adapter
>> but it's nice having separate IPs per server.  The only thing
> hindering
>> some
>> people from that is having to buy the IPs.  Most sell for like
> $10/month
>> an
>> IP.  But if you were short on cash you could do the port thing but I
>> like
>> having my own IP personally.  Easier to keep up with client servers
in
>> my
>> opinion :)
>>
>> --
>> NateDog
>>
>>
>>> -----Original Message-----
>>> From: Chris Adams [mailto:chris at fragzzhost.com]
>>> Sent: Monday, September 27, 2004 10:05 AM
>>> To: cod at icculus.org
>>> Subject: RE: [cod] Semi off topic: COD rentals
>>>
>>> No problem - good luck! :-)
>>>
>>> You don't even need virtual interfaces actually if you just change
> the
>>> port number with the net_port cvar :-). I can't remember exactly how
>> CoD
>>> deals with it, but if you put it on your command line and also in
>>> autoexec.cfg followed by a net_restart, you'll definitely be safe
> :-).
>>>
>>> Does anyone know exactly how CoD deals with it? It seems to vary
>> between
>>> the Q3-based games so I have our control engine just do it in every
>>> possible way usually to make sure it works. Would be nice to know
:-)
>>>
>>> ----------------------------------------
>>> Chris Adams
>>> Fragzzhost
>>>
>>> T (07005) 964 855
>>> F (07005) 964 857
>>> www.fragzzhost.com
>>>
>>>
>>> -----Original Message-----
>>> From: Jafo [mailto:jafo at nowhere.ca]
>>> Sent: 27 September 2004 14:42
>>> To: cod at icculus.org
>>> Subject: RE: [cod] Semi off topic: COD rentals
>>>
>>> Hello everyone,
>>>
>>> Thanks to everyone who responded to this thread! I was really
>> expecting
>>> hosting companies to be pretty closed lipped about this! Picked up
>> some
>>> REALLY good information from people's posts thank you very much!
>>>
>>> I'm going to purchase a box, co-lo it and get things started!
>>>
>>> I never even thought about running one set of binaries with virtual
>>> interfaces, that really beats virtual OS installs! Not to mention
the
>>> gains by running one set of binaries with sticky bit set!
>>>
>>> Mark, you provided some really good in depth feedback, I really
>>> appreciate
>>> it!
>>>
>>> Thanks all,
>>> Keith.
>>>
>>> On Sat, 25 Sep 2004, 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
>>> > >
>>> > ><http://www.fragzzhost.com>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
>>> >
>>> >
>>> >
>>>
>>>
>>
>>
>>
>> 
> 
> 
> 
> 
>






More information about the Cod mailing list