This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] BindCPU works quite well. http://www.softtreetech.com/24x7/extras/BindCPU.exe
All you do is start it like this bindcpu.exe 2 cod2.exe blahb lahbkdkdfjdjk more command gobble dee gook. For MOST people's scripting purposes, you'll want to use bindcpuw.exe (just change the URL) the w.exe wait()s for the process to exit before returning control to the calling process (cmd.exe). The regular version immediately returns control to the calling process. There's another program called xcpu.exe (someone search for it) that enables you to specify the processor number plus it lets you set the priority level. At one time I used bindcpu.exe and later used xcpu.exe for quite some time. They work just fine in a full production enviroment. I have moved on to some much more sophisticated stuff that completely automates everything about every game server you could imagine. Ultimately they are using the same calls in those programs as I use in my software. Alfred Reynolds wrote: > This is due to a fix stopping timing related errors (one thread is now > bound to CPU0 and windows appears to interpret that as the whole program > should be...). We are going to remove the programatic binding to CPU0 > and work around the windows timing problem in another (hackier) way. I > don't have an ETA for that update, in the meantime you can use taskman > to force the whole process to another CPU (does anyone have a command > line tool to do this?). > > - Alfred > > Gary wrote: > >> I'm seeing this on all of my servers after I updated from version 24 >> to 29.. they don't seem to move off of cpu0 unless I deselect it. >> >> At 10:03 PM 4/4/2006, David Harrison wrote: >> >>> Bit of a weird problem - we have four CS (1.6) servers running on one >>> machine (dual Opteron, dual core). For some reason all the servers >>> are 'bound' to one CPU - even though if I look at the properties in >>> task manager and check the affinity, they have all the processors >>> checked. >>> >>> Has anyone seen this behaviour before? >>> >>> Thanks, >>> -- david >>> >>> >>> _______________________________________________ >>> 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
