[cod] Semi off topic: COD rentals

[admin at typhoonservers.com]

Thanks for you help. I for one agree with you.
This is what this mail ist is all about...HELP !
----- Original Message ----- 
From: "Jay Vasallo" <haze at clanwarz.net>
To: <cod at icculus.org>
Sent: Saturday, September 25, 2004 5:15 AM
Subject: Re: [cod] Semi off topic: COD rentals


> Oh and if anyone is wondering why I am helping the server providers and
> server admins out, it's becasue I can. I am not to worried about the
> competition by far. There are thousands of customers and 100's of
providers,
> I just so happen to be the best! But I am also a gamer and I rather see
> great servers than crappy ones. Not to be modest but I would like to
> continue to help anyone who needs it.
>
> Cheers.
> Jay Vasallo
>
> ----- Original Message ----- 
> From: "Jase" <shoefly at sover.net>
> To: <cod at icculus.org>
> Sent: Friday, September 24, 2004 11:18 PM
> Subject: Re: [cod] Semi off topic: COD rentals
>
>
> > 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
> >>>
> >>>
>
>>--------------------------------------------------------------------------
--
> >>---
> >>Mark J. DeFilippis                    defilm at acm.org
> >>                                      defilm at ieee.org
> >>
> >>
> >
> >
>
>
>
>