[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
Re: [hlds] DoDS cpu and SMP time-line
This problem was introduced in March 2006 and still around. There are three options - keep using old binaries, change process affinity AFTER hlds.exe was started or switch to Linux version. I'm considering the latter at moment due to other issues including strange chokes which seem to be Windows-only problem. On 16/04/07, Matthias Wieloch <[EMAIL PROTECTED]> wrote: This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] I have a question to a similar problem. I'm running 3 hlds (old half-life engine) with counter-strike mod on a single machine. But if I update each server to the most recent version 1 CPU (out of 4) gets full load, the rest nothing. The only workaround I have is to copy some older dlls into the directories. The dlls mainly belong to the steam part. Will there be an update to that problem in some time? Regards Matthias -- ___ 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] DoDS cpu and SMP time-line
Well, actually 64-bit binaries may not give a significant performance boost. Firstly some operations will not benefit from more bits - 2 by 2 multiplication will take almost the same time for both 32-bit and 64-bit integers. Another important issue is 64-bit compiler, which may be not well optimized yet so single unoptimized piece of code in a time-critical section can even reduce overall performance. We've already seen that before while migrating from 16 to 32 - more bits will not magically solve your performance problems despite all marketing slogans. The same is true for SMP support - synchronisation between threads may hurt performance even further. The bottom line is - give Valve more time to work on both :) Regards, Roman On 16/04/07, Whisper <[EMAIL PROTECTED]> wrote: -- [ Picked text/plain from multipart/alternative ] The other thing to note is most GSP's provide multiple server processes on single CPU. It seem to me that it would cause more problems that it would solve for SRCDS users to have multi CPU support than it would solve. What would be more useful would be 64bit SRCDS binaries for both Windows & Linux. We can still allocate a single SRCDS process per core, but at least take advantage of the 64bit processing power available to us. On 4/16/07, Alfred Reynolds <[EMAIL PROTECTED]> wrote: > > Right now all the SMP work revolves around client side optimisations, it > is unclear what benefits can be found on the server. As we further > evolve our SMP support I am sure we will find some gains, more CPU's in > a machine is always better. > > - Alfred > > Dan Sorenson wrote: > > I suppose this is directed at Alfred: > > > > Over the past several months I've noticed the CPU requirements > for > > DoDS have been increasing, particularly with the larger custom maps > > (I suspect this is mostly a function of map size and optimization). > > > > So, will the upcoming SMP support be server-side, or merely > > client-side? If server-side, is there a rough time-frame? I get the > > feeling my future hardware selections are going to depend a lot upon > > that answer. > > > > - 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 > -- ___ 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
