Re: [hlds] RE: DoDS cpu and SMP time-line
-- [ Picked text/plain from multipart/alternative ] That's the answer I was looking for :) Yeah, I'm surprised WolfServers hasn't got more bad media around...with the gmod and all. I wonder if they stuff them all on the same box? On 4/17/07, RMaioroff <[EMAIL PROTECTED]> wrote: > > We are not a GSP. We do however offer the largest number of GMOD pubs > currently listed. The nice thing about GMOD is it's Lua capabilities. Very > flexible and many innovations are being not only conceived, but developed > for this neat mod. Does it crash a lot? Yes. Is it demanding on the > system? > Absolutely. Is it wildly popular? Better fucking believe it. If you know > Gmod, you know what a large community of players there are. Our servers > are > constantly full, and as long as we follow the development trends (within > reason) and provide the games the community is hungry for, we continue to > get that kind of volume. > > We run currently at 16 slots per pub (sandbox pubs mind you) for the very > reason of the potential for increase of CPU requirements at any given > time. > Think about it: A single garrysmod player can do enough in-game to max the > CPU. ONE PLAYER... So with 16 players, it is pretty damn heroic that we > have > smooth, fast, and consistent gameplay. If it weren't for several Lua > scripts > managing the prop overhead, a 16 player server in sandbox mode would be > out > of the question. > > As far as lagging every server on the box were we to get SMP; I disagree. > I > think that with the appropriate optimizations for the server code, and > with > a diligent admin whom sets affinity and process priority correctly, would > stand to gain a huge performance increase without "lagging other servers". > > So yeah- in a nutshell, without Linux Binaries, and with current > process-CPU > usage, GMOD is definitely NOT ready to be offered in a rental platform. I > totally agree. I can only imagine how much of a gut full of the shit > WolfServers will take before they say piss on it, and stop offering it as > a > rental option. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Cc2iscooL > Sent: Tuesday, April 17, 2007 6:31 PM > To: hlds@list.valvesoftware.com > Subject: Re: [hlds] RE: DoDS cpu and SMP time-line > > -- > [ Picked text/plain from multipart/alternative ] > The problem with that, if you are a game server provider, is that that one > process is going to load up every single core. Honestly. Now you have > every > single server on your box lagging. Honestly I don't even know why GSP's > offer Garry's Mod at all. You might as well put up a 32 slot CSS server @ > 100 tick full of bots...because honestly that's what it's like when you > put > that kind of stuff on your box. > > I'd be curious to see what kind of usage these Gmod servers have when > full, > I've never tried running them on anything but a spare box at home because > I > don't have the money to put a box in a datacenter just for one or two Gmod > servers. > > On 4/17/07, RMaioroff <[EMAIL PROTECTED]> wrote: > > > > Indeed. Which is why those of us in the Gmod serving arena can benefit > > greatly from balancing that load across multiple CPU's / Cores. You've > > obviously got experience with GMOD servers and know how demanding they > can > > be. It's frustrating to see it first hand, and then think that Valve > > *might* > > not be doing much to help our situation. > > > > In reality, Garry's Mod is probably the most demanding source game out > > there, bar none. > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Cc2iscooL > > Sent: Tuesday, April 17, 2007 4:02 PM > > To: hlds@list.valvesoftware.com > > Subject: Re: [hlds] RE: DoDS cpu and SMP time-line > > > > -- > > [ Picked text/plain from multipart/alternative ] > > Wow, I don't know who's dumber, the people thinking Garry's mod for some > > reason is *low load* or that SRCDS is the problem behind that. > > > > Just a quick reminder for you guys... Garry's Mod works by spawning > > entities > > which kiddies like to fling about the map. Now I don't know if you've > > noticed, but when you attach quite a few objects to a single point and > > spin, > > move, well hell, do anything to them, the load shoots up...this is not > due > > to SRCDS or Garry's Mod itself, but to the way the entities work. If you > > think that Garry's mod servers are going to run low l
RE: [hlds] RE: DoDS cpu and SMP time-line
We are not a GSP. We do however offer the largest number of GMOD pubs currently listed. The nice thing about GMOD is it's Lua capabilities. Very flexible and many innovations are being not only conceived, but developed for this neat mod. Does it crash a lot? Yes. Is it demanding on the system? Absolutely. Is it wildly popular? Better fucking believe it. If you know Gmod, you know what a large community of players there are. Our servers are constantly full, and as long as we follow the development trends (within reason) and provide the games the community is hungry for, we continue to get that kind of volume. We run currently at 16 slots per pub (sandbox pubs mind you) for the very reason of the potential for increase of CPU requirements at any given time. Think about it: A single garrysmod player can do enough in-game to max the CPU. ONE PLAYER... So with 16 players, it is pretty damn heroic that we have smooth, fast, and consistent gameplay. If it weren't for several Lua scripts managing the prop overhead, a 16 player server in sandbox mode would be out of the question. As far as lagging every server on the box were we to get SMP; I disagree. I think that with the appropriate optimizations for the server code, and with a diligent admin whom sets affinity and process priority correctly, would stand to gain a huge performance increase without "lagging other servers". So yeah- in a nutshell, without Linux Binaries, and with current process-CPU usage, GMOD is definitely NOT ready to be offered in a rental platform. I totally agree. I can only imagine how much of a gut full of the shit WolfServers will take before they say piss on it, and stop offering it as a rental option. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cc2iscooL Sent: Tuesday, April 17, 2007 6:31 PM To: hlds@list.valvesoftware.com Subject: Re: [hlds] RE: DoDS cpu and SMP time-line -- [ Picked text/plain from multipart/alternative ] The problem with that, if you are a game server provider, is that that one process is going to load up every single core. Honestly. Now you have every single server on your box lagging. Honestly I don't even know why GSP's offer Garry's Mod at all. You might as well put up a 32 slot CSS server @ 100 tick full of bots...because honestly that's what it's like when you put that kind of stuff on your box. I'd be curious to see what kind of usage these Gmod servers have when full, I've never tried running them on anything but a spare box at home because I don't have the money to put a box in a datacenter just for one or two Gmod servers. On 4/17/07, RMaioroff <[EMAIL PROTECTED]> wrote: > > Indeed. Which is why those of us in the Gmod serving arena can benefit > greatly from balancing that load across multiple CPU's / Cores. You've > obviously got experience with GMOD servers and know how demanding they can > be. It's frustrating to see it first hand, and then think that Valve > *might* > not be doing much to help our situation. > > In reality, Garry's Mod is probably the most demanding source game out > there, bar none. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Cc2iscooL > Sent: Tuesday, April 17, 2007 4:02 PM > To: hlds@list.valvesoftware.com > Subject: Re: [hlds] RE: DoDS cpu and SMP time-line > > -- > [ Picked text/plain from multipart/alternative ] > Wow, I don't know who's dumber, the people thinking Garry's mod for some > reason is *low load* or that SRCDS is the problem behind that. > > Just a quick reminder for you guys... Garry's Mod works by spawning > entities > which kiddies like to fling about the map. Now I don't know if you've > noticed, but when you attach quite a few objects to a single point and > spin, > move, well hell, do anything to them, the load shoots up...this is not due > to SRCDS or Garry's Mod itself, but to the way the entities work. If you > think that Garry's mod servers are going to run low load, you are sorely > mistaken. > > On 4/17/07, James Gray <[EMAIL PROTECTED]> wrote: > > > > Sounds more like a Garry's Mod issue than a Source DS one. > > > > On 4/17/07, RMaioroff <[EMAIL PROTECTED]> wrote: > > > Steve, do you / have you run any Garry's Mod servers in sandbox mode? > We > > > have machines that are 4 physical Xeons (i.e. 8 cores), machines that > > are > > > dual AMD opterons, etc... and the same old story with maxxing out the > > CPU. I > > > assume you run GMod 10 servers, and would love to hear your secret to > > > getting stable, consistent behavior with more than 16 players in > sandbox > > > mode. We've run 32 players before
Re: [hlds] RE: DoDS cpu and SMP time-line
-- [ Picked text/plain from multipart/alternative ] The problem with that, if you are a game server provider, is that that one process is going to load up every single core. Honestly. Now you have every single server on your box lagging. Honestly I don't even know why GSP's offer Garry's Mod at all. You might as well put up a 32 slot CSS server @ 100 tick full of bots...because honestly that's what it's like when you put that kind of stuff on your box. I'd be curious to see what kind of usage these Gmod servers have when full, I've never tried running them on anything but a spare box at home because I don't have the money to put a box in a datacenter just for one or two Gmod servers. On 4/17/07, RMaioroff <[EMAIL PROTECTED]> wrote: > > Indeed. Which is why those of us in the Gmod serving arena can benefit > greatly from balancing that load across multiple CPU's / Cores. You've > obviously got experience with GMOD servers and know how demanding they can > be. It's frustrating to see it first hand, and then think that Valve > *might* > not be doing much to help our situation. > > In reality, Garry's Mod is probably the most demanding source game out > there, bar none. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Cc2iscooL > Sent: Tuesday, April 17, 2007 4:02 PM > To: hlds@list.valvesoftware.com > Subject: Re: [hlds] RE: DoDS cpu and SMP time-line > > -- > [ Picked text/plain from multipart/alternative ] > Wow, I don't know who's dumber, the people thinking Garry's mod for some > reason is *low load* or that SRCDS is the problem behind that. > > Just a quick reminder for you guys... Garry's Mod works by spawning > entities > which kiddies like to fling about the map. Now I don't know if you've > noticed, but when you attach quite a few objects to a single point and > spin, > move, well hell, do anything to them, the load shoots up...this is not due > to SRCDS or Garry's Mod itself, but to the way the entities work. If you > think that Garry's mod servers are going to run low load, you are sorely > mistaken. > > On 4/17/07, James Gray <[EMAIL PROTECTED]> wrote: > > > > Sounds more like a Garry's Mod issue than a Source DS one. > > > > On 4/17/07, RMaioroff <[EMAIL PROTECTED]> wrote: > > > Steve, do you / have you run any Garry's Mod servers in sandbox mode? > We > > > have machines that are 4 physical Xeons (i.e. 8 cores), machines that > > are > > > dual AMD opterons, etc... and the same old story with maxxing out the > > CPU. I > > > assume you run GMod 10 servers, and would love to hear your secret to > > > getting stable, consistent behavior with more than 16 players in > sandbox > > > mode. We've run 32 players before, and things are fine until large > > > contraptions are created and Gmod requires huge amounts of CPU. > > > > > > -Thanks > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Steven > Hartland > > > Sent: Tuesday, April 17, 2007 1:10 PM > > > To: hlds@list.valvesoftware.com > > > Subject: Re: [hlds] RE: DoDS cpu and SMP time-line > > > > > > Not sure what you class as top-of-the-line machines but you should be > > able > > > to run more than 16 players total on a good Intel Core 2 / AMD 64 box. > > > > > >Steve > > > > > > - Original Message - > > > From: "RMaioroff" <[EMAIL PROTECTED]> > > > To: > > > Sent: Tuesday, April 17, 2007 5:30 PM > > > Subject: RE: [hlds] RE: DoDS cpu and SMP time-line > > > > > > > > > > We're in the same boat- Too much load and not enough CPU. We host > > about 10 > > > > Garry's mod public servers, and are unable to reasonably run > anything > > more > > > > than 16 players (sandbox). It's very disheartening to think that we > > pay > > > $500 > > > > /mo. for top-of-the-line machines, and STILL see cpu loads > > consistently > > > > hitting 90-100%. > > > > > > > > Valve, we NEED server side support and optimization!! How sad to > have > > to > > > > explain to provisioning that no, we don't want the free sub-upgrade > to > > the > > > > Xeons, but instead flop us back to the Pentium D 950. :-( > > > > > > > > Come on Valve. Please revisit the issue of server side SMP. If
RE: [hlds] RE: DoDS cpu and SMP time-line
Indeed. Which is why those of us in the Gmod serving arena can benefit greatly from balancing that load across multiple CPU's / Cores. You've obviously got experience with GMOD servers and know how demanding they can be. It's frustrating to see it first hand, and then think that Valve *might* not be doing much to help our situation. In reality, Garry's Mod is probably the most demanding source game out there, bar none. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cc2iscooL Sent: Tuesday, April 17, 2007 4:02 PM To: hlds@list.valvesoftware.com Subject: Re: [hlds] RE: DoDS cpu and SMP time-line -- [ Picked text/plain from multipart/alternative ] Wow, I don't know who's dumber, the people thinking Garry's mod for some reason is *low load* or that SRCDS is the problem behind that. Just a quick reminder for you guys... Garry's Mod works by spawning entities which kiddies like to fling about the map. Now I don't know if you've noticed, but when you attach quite a few objects to a single point and spin, move, well hell, do anything to them, the load shoots up...this is not due to SRCDS or Garry's Mod itself, but to the way the entities work. If you think that Garry's mod servers are going to run low load, you are sorely mistaken. On 4/17/07, James Gray <[EMAIL PROTECTED]> wrote: > > Sounds more like a Garry's Mod issue than a Source DS one. > > On 4/17/07, RMaioroff <[EMAIL PROTECTED]> wrote: > > Steve, do you / have you run any Garry's Mod servers in sandbox mode? We > > have machines that are 4 physical Xeons (i.e. 8 cores), machines that > are > > dual AMD opterons, etc... and the same old story with maxxing out the > CPU. I > > assume you run GMod 10 servers, and would love to hear your secret to > > getting stable, consistent behavior with more than 16 players in sandbox > > mode. We've run 32 players before, and things are fine until large > > contraptions are created and Gmod requires huge amounts of CPU. > > > > -Thanks > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Steven Hartland > > Sent: Tuesday, April 17, 2007 1:10 PM > > To: hlds@list.valvesoftware.com > > Subject: Re: [hlds] RE: DoDS cpu and SMP time-line > > > > Not sure what you class as top-of-the-line machines but you should be > able > > to run more than 16 players total on a good Intel Core 2 / AMD 64 box. > > > >Steve > > > > - Original Message - > > From: "RMaioroff" <[EMAIL PROTECTED]> > > To: > > Sent: Tuesday, April 17, 2007 5:30 PM > > Subject: RE: [hlds] RE: DoDS cpu and SMP time-line > > > > > > > We're in the same boat- Too much load and not enough CPU. We host > about 10 > > > Garry's mod public servers, and are unable to reasonably run anything > more > > > than 16 players (sandbox). It's very disheartening to think that we > pay > > $500 > > > /mo. for top-of-the-line machines, and STILL see cpu loads > consistently > > > hitting 90-100%. > > > > > > Valve, we NEED server side support and optimization!! How sad to have > to > > > explain to provisioning that no, we don't want the free sub-upgrade to > the > > > Xeons, but instead flop us back to the Pentium D 950. :-( > > > > > > Come on Valve. Please revisit the issue of server side SMP. If we > can't > > take > > > advantage of our big machines to finally run your game binaries with > > > adequate CPU, then I for one will be forced to give up the source > hosting, > > > which would be a real disappointment. > > > > > > > > This e.mail is private and confidential between Multiplay (UK) Ltd. and > the > > person or entity to whom it is addressed. In the event of misdirection, > the > > recipient is prohibited from using, copying, printing or otherwise > > disseminating it or any information contained in it. > > > > In the event of misdirection, illegible or incomplete transmission > please > > telephone +44 845 868 1337 > > or return the E.mail to [EMAIL PROTECTED] > > > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlds > > > > > > > > ___ > > To unsubscribe, edit your list preferences, or v
RE: [hlds] RE: DoDS cpu and SMP time-line
Thanks for the feedback. I am aware of the various pros and cons to the different CPU brands. I didn't mean (nor did I say) that we cannot have multiple instances of srcds on the machine. In fact, we run 4-5 16 player servers without much problem. The issue is getting a higher slot count in each srcds instance, for example 32 players. Regards -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Hartland Sent: Tuesday, April 17, 2007 3:40 PM To: hlds@list.valvesoftware.com Subject: Re: [hlds] RE: DoDS cpu and SMP time-line Your saying you have true 8 way machines and you cant get more than 16 players total. There simply must be something wrong there as src is for all intensive purposes single threaded so if you can run 1 * 16 player you can run 8 assuming you have enough ram and you don't start hitting context switch / kernel contention issues. Obviously if your talking Hyperthreading forget that as its useless and you could only run 4 that being the real number of cores. Opterons are a step above that a 2.8Ghz Opteron will eat any P4 based Xeon you can find for breakfast and 3Ghz Core 2 does the same to Opteron. I'm not speaking from any experience running Garry's mod but from a general stand point you should be able to get at least 64 players, 16 players per core, out of good spec 4 core machine if not more. If your currently running 3.6Ghz P4 based and that's peaking at 16 you should be good for 20 may be more on current top end kit. If your looking for the fastest individual core performance then look at either Intel Xeon 5160 ( Dual Core ) or the Intel QX6800 ( Quad Core ) both ~3Ghz per core, don't even consider the old P4 architecture stuff as it wont even come close in performance. Note: Due to the Xeon's use of FBDIMM's its often slower than the desktop version which is DDR2 based. Steve - Original Message - From: "RMaioroff" <[EMAIL PROTECTED]> > Steve, do you / have you run any Garry's Mod servers in sandbox mode? We > have machines that are 4 physical Xeons (i.e. 8 cores), machines that are > dual AMD opterons, etc... and the same old story with maxxing out the CPU. I > assume you run GMod 10 servers, and would love to hear your secret to > getting stable, consistent behavior with more than 16 players in sandbox > mode. We've run 32 players before, and things are fine until large > contraptions are created and Gmod requires huge amounts of CPU. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] RE: DoDS cpu and SMP time-line
-- [ Picked text/plain from multipart/alternative ] Wow, I don't know who's dumber, the people thinking Garry's mod for some reason is *low load* or that SRCDS is the problem behind that. Just a quick reminder for you guys... Garry's Mod works by spawning entities which kiddies like to fling about the map. Now I don't know if you've noticed, but when you attach quite a few objects to a single point and spin, move, well hell, do anything to them, the load shoots up...this is not due to SRCDS or Garry's Mod itself, but to the way the entities work. If you think that Garry's mod servers are going to run low load, you are sorely mistaken. On 4/17/07, James Gray <[EMAIL PROTECTED]> wrote: > > Sounds more like a Garry's Mod issue than a Source DS one. > > On 4/17/07, RMaioroff <[EMAIL PROTECTED]> wrote: > > Steve, do you / have you run any Garry's Mod servers in sandbox mode? We > > have machines that are 4 physical Xeons (i.e. 8 cores), machines that > are > > dual AMD opterons, etc... and the same old story with maxxing out the > CPU. I > > assume you run GMod 10 servers, and would love to hear your secret to > > getting stable, consistent behavior with more than 16 players in sandbox > > mode. We've run 32 players before, and things are fine until large > > contraptions are created and Gmod requires huge amounts of CPU. > > > > -Thanks > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Steven Hartland > > Sent: Tuesday, April 17, 2007 1:10 PM > > To: hlds@list.valvesoftware.com > > Subject: Re: [hlds] RE: DoDS cpu and SMP time-line > > > > Not sure what you class as top-of-the-line machines but you should be > able > > to run more than 16 players total on a good Intel Core 2 / AMD 64 box. > > > >Steve > > > > - Original Message - > > From: "RMaioroff" <[EMAIL PROTECTED]> > > To: > > Sent: Tuesday, April 17, 2007 5:30 PM > > Subject: RE: [hlds] RE: DoDS cpu and SMP time-line > > > > > > > We're in the same boat- Too much load and not enough CPU. We host > about 10 > > > Garry's mod public servers, and are unable to reasonably run anything > more > > > than 16 players (sandbox). It's very disheartening to think that we > pay > > $500 > > > /mo. for top-of-the-line machines, and STILL see cpu loads > consistently > > > hitting 90-100%. > > > > > > Valve, we NEED server side support and optimization!! How sad to have > to > > > explain to provisioning that no, we don't want the free sub-upgrade to > the > > > Xeons, but instead flop us back to the Pentium D 950. :-( > > > > > > Come on Valve. Please revisit the issue of server side SMP. If we > can't > > take > > > advantage of our big machines to finally run your game binaries with > > > adequate CPU, then I for one will be forced to give up the source > hosting, > > > which would be a real disappointment. > > > > > > > > This e.mail is private and confidential between Multiplay (UK) Ltd. and > the > > person or entity to whom it is addressed. In the event of misdirection, > the > > recipient is prohibited from using, copying, printing or otherwise > > disseminating it or any information contained in it. > > > > In the event of misdirection, illegible or incomplete transmission > please > > telephone +44 845 868 1337 > > or return the E.mail to [EMAIL PROTECTED] > > > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlds > > > > > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlds > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] RE: DoDS cpu and SMP time-line
Sounds more like a Garry's Mod issue than a Source DS one. On 4/17/07, RMaioroff <[EMAIL PROTECTED]> wrote: Steve, do you / have you run any Garry's Mod servers in sandbox mode? We have machines that are 4 physical Xeons (i.e. 8 cores), machines that are dual AMD opterons, etc... and the same old story with maxxing out the CPU. I assume you run GMod 10 servers, and would love to hear your secret to getting stable, consistent behavior with more than 16 players in sandbox mode. We've run 32 players before, and things are fine until large contraptions are created and Gmod requires huge amounts of CPU. -Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Hartland Sent: Tuesday, April 17, 2007 1:10 PM To: hlds@list.valvesoftware.com Subject: Re: [hlds] RE: DoDS cpu and SMP time-line Not sure what you class as top-of-the-line machines but you should be able to run more than 16 players total on a good Intel Core 2 / AMD 64 box. Steve - Original Message - From: "RMaioroff" <[EMAIL PROTECTED]> To: Sent: Tuesday, April 17, 2007 5:30 PM Subject: RE: [hlds] RE: DoDS cpu and SMP time-line > We're in the same boat- Too much load and not enough CPU. We host about 10 > Garry's mod public servers, and are unable to reasonably run anything more > than 16 players (sandbox). It's very disheartening to think that we pay $500 > /mo. for top-of-the-line machines, and STILL see cpu loads consistently > hitting 90-100%. > > Valve, we NEED server side support and optimization!! How sad to have to > explain to provisioning that no, we don't want the free sub-upgrade to the > Xeons, but instead flop us back to the Pentium D 950. :-( > > Come on Valve. Please revisit the issue of server side SMP. If we can't take > advantage of our big machines to finally run your game binaries with > adequate CPU, then I for one will be forced to give up the source hosting, > which would be a real disappointment. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] RE: DoDS cpu and SMP time-line
Your saying you have true 8 way machines and you cant get more than 16 players total. There simply must be something wrong there as src is for all intensive purposes single threaded so if you can run 1 * 16 player you can run 8 assuming you have enough ram and you don't start hitting context switch / kernel contention issues. Obviously if your talking Hyperthreading forget that as its useless and you could only run 4 that being the real number of cores. Opterons are a step above that a 2.8Ghz Opteron will eat any P4 based Xeon you can find for breakfast and 3Ghz Core 2 does the same to Opteron. I'm not speaking from any experience running Garry's mod but from a general stand point you should be able to get at least 64 players, 16 players per core, out of good spec 4 core machine if not more. If your currently running 3.6Ghz P4 based and that's peaking at 16 you should be good for 20 may be more on current top end kit. If your looking for the fastest individual core performance then look at either Intel Xeon 5160 ( Dual Core ) or the Intel QX6800 ( Quad Core ) both ~3Ghz per core, don't even consider the old P4 architecture stuff as it wont even come close in performance. Note: Due to the Xeon's use of FBDIMM's its often slower than the desktop version which is DDR2 based. Steve - Original Message - From: "RMaioroff" <[EMAIL PROTECTED]> Steve, do you / have you run any Garry's Mod servers in sandbox mode? We have machines that are 4 physical Xeons (i.e. 8 cores), machines that are dual AMD opterons, etc... and the same old story with maxxing out the CPU. I assume you run GMod 10 servers, and would love to hear your secret to getting stable, consistent behavior with more than 16 players in sandbox mode. We've run 32 players before, and things are fine until large contraptions are created and Gmod requires huge amounts of CPU. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
RE: [hlds] RE: DoDS cpu and SMP time-line
Steve, do you / have you run any Garry's Mod servers in sandbox mode? We have machines that are 4 physical Xeons (i.e. 8 cores), machines that are dual AMD opterons, etc... and the same old story with maxxing out the CPU. I assume you run GMod 10 servers, and would love to hear your secret to getting stable, consistent behavior with more than 16 players in sandbox mode. We've run 32 players before, and things are fine until large contraptions are created and Gmod requires huge amounts of CPU. -Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Hartland Sent: Tuesday, April 17, 2007 1:10 PM To: hlds@list.valvesoftware.com Subject: Re: [hlds] RE: DoDS cpu and SMP time-line Not sure what you class as top-of-the-line machines but you should be able to run more than 16 players total on a good Intel Core 2 / AMD 64 box. Steve - Original Message - From: "RMaioroff" <[EMAIL PROTECTED]> To: Sent: Tuesday, April 17, 2007 5:30 PM Subject: RE: [hlds] RE: DoDS cpu and SMP time-line > We're in the same boat- Too much load and not enough CPU. We host about 10 > Garry's mod public servers, and are unable to reasonably run anything more > than 16 players (sandbox). It's very disheartening to think that we pay $500 > /mo. for top-of-the-line machines, and STILL see cpu loads consistently > hitting 90-100%. > > Valve, we NEED server side support and optimization!! How sad to have to > explain to provisioning that no, we don't want the free sub-upgrade to the > Xeons, but instead flop us back to the Pentium D 950. :-( > > Come on Valve. Please revisit the issue of server side SMP. If we can't take > advantage of our big machines to finally run your game binaries with > adequate CPU, then I for one will be forced to give up the source hosting, > which would be a real disappointment. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] RE: DoDS cpu and SMP time-line
One SMP related change that would be very simple and would have a dramatic improvement on the Server performance would be to provide a CVAR that would put the BOT threads and the SRCTV and perhaps the in-game Spectator threads on some other CPU if available. The BOT threads especially can take significant processing time (of course for CSS only). I assume most high-end CSS servers don't run BOTs though so this may not help them. For upcoming releases like Left4Dead however, this might provide a significant performance impact. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] RE: DoDS cpu and SMP time-line
Not sure what you class as top-of-the-line machines but you should be able to run more than 16 players total on a good Intel Core 2 / AMD 64 box. Steve - Original Message - From: "RMaioroff" <[EMAIL PROTECTED]> To: Sent: Tuesday, April 17, 2007 5:30 PM Subject: RE: [hlds] RE: DoDS cpu and SMP time-line We're in the same boat- Too much load and not enough CPU. We host about 10 Garry's mod public servers, and are unable to reasonably run anything more than 16 players (sandbox). It's very disheartening to think that we pay $500 /mo. for top-of-the-line machines, and STILL see cpu loads consistently hitting 90-100%. Valve, we NEED server side support and optimization!! How sad to have to explain to provisioning that no, we don't want the free sub-upgrade to the Xeons, but instead flop us back to the Pentium D 950. :-( Come on Valve. Please revisit the issue of server side SMP. If we can't take advantage of our big machines to finally run your game binaries with adequate CPU, then I for one will be forced to give up the source hosting, which would be a real disappointment. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
RE: [hlds] RE: DoDS cpu and SMP time-line
We're in the same boat- Too much load and not enough CPU. We host about 10 Garry's mod public servers, and are unable to reasonably run anything more than 16 players (sandbox). It's very disheartening to think that we pay $500 /mo. for top-of-the-line machines, and STILL see cpu loads consistently hitting 90-100%. Valve, we NEED server side support and optimization!! How sad to have to explain to provisioning that no, we don't want the free sub-upgrade to the Xeons, but instead flop us back to the Pentium D 950. :-( Come on Valve. Please revisit the issue of server side SMP. If we can't take advantage of our big machines to finally run your game binaries with adequate CPU, then I for one will be forced to give up the source hosting, which would be a real disappointment. Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Sorenson Sent: Monday, April 16, 2007 10:49 PM To: hlds@list.valvesoftware.com Subject: [hlds] RE: DoDS cpu and SMP time-line At 08:25 PM 4/15/2007 -0700, Alfred fesses up: >Right now all the SMP work revolves around client side optimisations, it >is unclear what benefits can be found on the server. At present we're stuck at 2.6Ghz a core, so to my way of thinking if the game requires a 3Ghz or 3.5Ghz CPU to sustain performance then the options are to 1) put SMP support in the engine so it can get an effective 2*2.6GHz to work with, 2) drop the number of players and tick rate to compensate, or 3) forget about purchasing quad-core boxes and dedicate a Pentium D at 3.8Ghz with the 1024MHz FSB and eat the costs of the extra hardware. I doubt we'll see this in CS:S any time soon, but in DoD:S the mappers seem to want to put everything from Normandy to the Maginot Line in one map, and you know better than most how larger maps and the greater number of entities to calculate around increase load. And users scale in a logarithmic manner. Granted, Valve's bread and butter is CS:S, so I wouldn't expect DoD:S alone to prompt this. Granted also, DoD:S has sort of caused its own problem in this regard and it's not Valve's obligation to fix it. This is still going to become a problem that current hardware cannot address, if not with CS:S then perhaps with TF2 when the mappers get crazy or when we try to run 32-player servers of Deathmatch four months from now. To me, my choices are coming down to money. If SMP support is four months from now I can slide a bit, maybe move my DoD:S server to a box that only handles that game and maybe a web service, and I can leave my CS:S servers on dual-core or quad-core machines and consolidate them a bit. If SMP support is a year away on the server side, and a 2.6Ghz core isn't cutting it, either I need to buy faster single-core processors and dedicated boxes and adjust my budget, or I need to tell my folks that a 32-player box at 100 tick isn't feasable for that game on today's hardware. Which reminds me, we're fast approaching the time where there needs to be a decent benchmark tool for servers. Something that can simulate 32 users or 24 users and just put a load on the box so we can tell if we're hitting the limits of CPU, memory, disk, network, etc... before promising the customer a Great Gaming Experience. I'm afraid that "Sorry, the custom map you loaded is at fault" or "try it without any mods" isn't going to be an adequate defense in the near future. Such a tool might be justified in development time mainly by documenting limitations and thus setting priorities in development of the server code. - Dan * Dan Sorenson DoD #1066 A.H.M.C. #35 [EMAIL PROTECTED] * * Vikings? There ain't no vikings here. Just us honest farmers. * * The town was burning, the villagers were dead. They didn't need * * those sheep anyway. That's our story and we're sticking to it. * ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] RE: DoDS cpu and SMP time-line
At 02:41 PM 4/17/2007 +0400, Roman wrote: >I can't see why you might need to choose between singlecore and >multicore processors. Even low-end dual 5110 machine now costs a bit >more than decent dual P4-3.4 and performs MUCH better. If the limiting factor is clock cycles for the HLDS engine, throwing more cores at it won't help. The only other option is to find a single core it can run on with more cycles to work with. A dedicated box is honestly a waste of money, but in time-critical applications often times its the only way. Naturally, one would have to have some real-world benchmarks to compare a 3.8Ghz single-core against the 5110's twin 1.6Ghz cores on a single process. I'm not betting the server farm on this yet, I'm just trying to see what my options are going to be two to six months from now. - Dan * Dan Sorenson DoD #1066 A.H.M.C. #35 [EMAIL PROTECTED] * * Vikings? There ain't no vikings here. Just us honest farmers. * * The town was burning, the villagers were dead. They didn't need * * those sheep anyway. That's our story and we're sticking to it. * ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] RE: DoDS cpu and SMP time-line
I can't see why you might need to choose between singlecore and multicore processors. Even low-end dual 5110 machine now costs a bit more than decent dual P4-3.4 and performs MUCH better. On Mon, 16 Apr 2007 22:48:55, Dan Sorenson <[EMAIL PROTECTED]> wrote: At 08:25 PM 4/15/2007 -0700, Alfred fesses up: >Right now all the SMP work revolves around client side optimisations, it >is unclear what benefits can be found on the server. At present we're stuck at 2.6Ghz a core, so to my way of thinking if the game requires a 3Ghz or 3.5Ghz CPU to sustain performance then the options are to 1) put SMP support in the engine so it can get an effective 2*2.6GHz to work with, 2) drop the number of players and tick rate to compensate, or 3) forget about purchasing quad-core boxes and dedicate a Pentium D at 3.8Ghz with the 1024MHz FSB and eat the costs of the extra hardware. I doubt we'll see this in CS:S any time soon, but in DoD:S the mappers seem to want to put everything from Normandy to the Maginot Line in one map, and you know better than most how larger maps and the greater number of entities to calculate around increase load. And users scale in a logarithmic manner. Granted, Valve's bread and butter is CS:S, so I wouldn't expect DoD:S alone to prompt this. Granted also, DoD:S has sort of caused its own problem in this regard and it's not Valve's obligation to fix it. This is still going to become a problem that current hardware cannot address, if not with CS:S then perhaps with TF2 when the mappers get crazy or when we try to run 32-player servers of Deathmatch four months from now. To me, my choices are coming down to money. If SMP support is four months from now I can slide a bit, maybe move my DoD:S server to a box that only handles that game and maybe a web service, and I can leave my CS:S servers on dual-core or quad-core machines and consolidate them a bit. If SMP support is a year away on the server side, and a 2.6Ghz core isn't cutting it, either I need to buy faster single-core processors and dedicated boxes and adjust my budget, or I need to tell my folks that a 32-player box at 100 tick isn't feasable for that game on today's hardware. Which reminds me, we're fast approaching the time where there needs to be a decent benchmark tool for servers. Something that can simulate 32 users or 24 users and just put a load on the box so we can tell if we're hitting the limits of CPU, memory, disk, network, etc... before promising the customer a Great Gaming Experience. I'm afraid that "Sorry, the custom map you loaded is at fault" or "try it without any mods" isn't going to be an adequate defense in the near future. Such a tool might be justified in development time mainly by documenting limitations and thus setting priorities in development of the server code. - Dan * Dan Sorenson DoD #1066 A.H.M.C. #35 [EMAIL PROTECTED] * * Vikings? There ain't no vikings here. Just us honest farmers. * * The town was burning, the villagers were dead. They didn't need * * those sheep anyway. That's our story and we're sticking to it. * ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] RE: DoDS cpu and SMP time-line
-- [ Picked text/plain from multipart/alternative ] Actually I take what I said back. At the rate SRCDS is gobbling up CPU resources, our only bloody hope of successfully running even 1 decent SRCDS process is for SRCDS to support multi-threading and 64bit and as many CPU cores as you can throw at the damn thing. On Mon, 16 Apr 2007 22:48:55, Dan Sorenson <[EMAIL PROTECTED]> wrote: > > At 08:25 PM 4/15/2007 -0700, Alfred fesses up: > > >Right now all the SMP work revolves around client side optimisations, it > >is unclear what benefits can be found on the server. > > At present we're stuck at 2.6Ghz a core, so to my way of thinking > if the game requires a 3Ghz or 3.5Ghz CPU to sustain performance then the > options are to 1) put SMP support in the engine so it can get an effective > 2*2.6GHz to work with, 2) drop the number of players and tick rate to > compensate, or 3) forget about purchasing quad-core boxes and dedicate a > Pentium D at 3.8Ghz with the 1024MHz FSB and eat the costs of the extra > hardware. > > I doubt we'll see this in CS:S any time soon, but in DoD:S the > mappers seem to want to put everything from Normandy to the Maginot Line in > one map, and you know better than most how larger maps and the greater > number of entities to calculate around increase load. And users scale in a > logarithmic manner. > > Granted, Valve's bread and butter is CS:S, so I wouldn't expect > DoD:S alone to prompt this. Granted also, DoD:S has sort of caused its own > problem in this regard and it's not Valve's obligation to fix it. This is > still going to become a problem that current hardware cannot address, if not > with CS:S then perhaps with TF2 when the mappers get crazy or when we try to > run 32-player servers of Deathmatch four months from now. > > To me, my choices are coming down to money. If SMP support is > four months from now I can slide a bit, maybe move my DoD:S server to a box > that only handles that game and maybe a web service, and I can leave my CS:S > servers on dual-core or quad-core machines and consolidate them a bit. If > SMP support is a year away on the server side, and a 2.6Ghz core isn't > cutting it, either I need to buy faster single-core processors and dedicated > boxes and adjust my budget, or I need to tell my folks that a 32-player box > at 100 tick isn't feasable for that game on today's hardware. > > Which reminds me, we're fast approaching the time where there > needs to be a decent benchmark tool for servers. Something that can > simulate 32 users or 24 users and just put a load on the box so we can tell > if we're hitting the limits of CPU, memory, disk, network, etc... before > promising the customer a Great Gaming Experience. I'm afraid that "Sorry, > the custom map you loaded is at fault" or "try it without any mods" isn't > going to be an adequate defense in the near future. Such a tool might be > justified in development time mainly by documenting limitations and thus > setting priorities in development of the server code. > > - Dan > > * Dan Sorenson DoD #1066 A.H.M.C. #35 [EMAIL PROTECTED] * > * Vikings? There ain't no vikings here. Just us honest farmers. * > * The town was burning, the villagers were dead. They didn't need * > * those sheep anyway. That's our story and we're sticking to it. * > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
