[cod] Semi off topic: COD rentals

Tue Sep 28 05:15:50 EDT 2004

Hi Jay and Chris,

Can i ask a couple of questions about your control panels?

Do you host your control panel on a central server or is it a web server thats on the game server?
If its the first (and i am presuming it is the first) how do you push the changes out to the game servers?
I am not asking for trade secrets but if you could explain things in general terms it would be appreciated.

Ta,
Richard.

Jay Vasallo <haze at clanwarz.net> wrote:
I keep on knocking but I can't get in....

----- Original Message ----- 
From: "Chris Adams" 
To: 
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" 
> To: 
> 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
>>> > >
>>> > >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
>>> >
>>> >
>>> >
>>>
>>>
>>
>>
>>
>> 
> 
> 
> 
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/cod/attachments/20040928/ba12589c/attachment.htm>