[cod] Semi off topic: COD rentals

[Jase]

I think your missunderstanding me or maybe im missunderstanding you. I 
only have 1 copy of coduo_lnxded on my server. period. there arent 
multiple copies nor should there be. Why? when cod/uo support multiple 
users with fs_basepath and fs_homepath they use the same startup command.
ie cd /us/loca/games/cod/
./coduo_lnxded +set fs_basepath /usr/local/games/cod +set fs_homepath 
/home/blah/.callofduty +set dedicated 2 +exec coduoserver.cfg
So i guess im wondering what your point is? Im kinda lost. why symlink 
if every instance of a coduo server is using the same exact binary file?
sorry dont mean to sound like i disbelieve you Im jsut confused about 
why symlinking
Jase
lMark J. DeFilippis wrote:

>
> 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
>
>