[cod] Semi off topic: COD rentals
Jay Vasallo
haze at clanwarz.net
Mon Sep 27 15:13:38 EDT 2004
Nice set up bro! Me likes ;-)
----- Original Message -----
From: "Chris Adams" <chris at fragzzhost.com>
To: <cod at icculus.org>
Sent: Monday, September 27, 2004 10:08 AM
Subject: RE: [cod] Semi off topic: COD rentals
> 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