W2K Assigning a task to 1 CPU on a dual machine

[Fushigi]

How do you assign a task to only use a single CPU in a dual machine?

We have a server app that runs as a service. It makes ODBC calls to an SQL server. Under Unix, there are known issues with the product & ODBC on SMP systems. A 'fix' is to have the process only use one CPU. Is this possible under W2K?

- Fushigi

 

[Mercutio]

If you right click on your running process in the "processes" view in task manager, you can choose to "set affinity", which will let you permanently assign which CPU(s) handles a particular program.

2000 will also let you distribute interrupts to multiple CPUs, which can also help or hinder performance, BTW.

 

[Fushigi]

We found the processes trick in Task Mgr but that's only temporary. We were looking for a permanent change.

I actually found one. Imagecfg.exe from the W2k Resource Kit patches executables for processor affinity. We don't like the thought of that, though.

Any idea if the /ONECPU BOOT.INI option works in 2000? The references I found for it date to NT 4.

Thanks,
Fushigi

 

[Pradeep]

If the app you require is running all the time, perhaps you would be better off removing one of the CPUs?

 

[Fushigi]

We're troubleshooting a problem that could be induced by some threading model issues on SMP systems. Any solution to make the app run on 1 CPU is temporary until the vendor fixes the app. Hopefully within the next few days.

I should restate my 'permanent' statement from my last post. The Task Manager affinity setting goes away when you reboot. Or at least it did with this app. We're looking for something that will persist from boot to boot but is easily, and preferably remotely, adjustable.

There are also other services on the machine so I'd rather not physically eliminate one of the servers. I'm not certain what the overall CPU utilization under max load is, but I'd rather not take the chance on having it bog down. We absolutely must maintain a fast response time and this is, unfortunately, a production server.

I'm also not sure if it voids our warranty.

 

[Cliptin]

With FireDaemon you could theoreticly build a service that binds to only one CPU.

FireDaemon is a utility that allows you to install and run virtually any application as a Windows NT/2K/XP service. FireDaemon features easy configuration, a low memory/CPU overhead, subprocess prioritisation and CPU binding and scheduling plus monitoring and logging to the NT/2K/XP event log.

You could disable the currently running service and use the FireDaemon service until the software was fixed. Hopefully you have a test environment as well as the production server.

Then again how often do you reboot the server?

 

[Fushigi]

With FireDaemon you could theoreticly build a service that binds to only one CPU.

...

You could disable the currently running service and use the FireDaemon service until the software was fixed. Hopefully you have a test environment as well as the production server.

Then again how often do you reboot the server?

I'll check into FireDaemon; thanks.

We reboot several times a day .. whenever the app goes south. When it goes bad, it doesn't release the TCP socket it uses for communications (shame on Windows for not cleaning up after an errant app). Thus, restarting the service fails as it can't allocate the socket. I don't see anything in Windows that frees a socket, so we reboot to free it up & get the service running again. On average we go about 2.5 hours before the service dies.

Word late yesterday is that the developers are doing a line-by-line code review to find the problem. It turns out we're not the only customer affected. Which is good in a way as there is strength in numbers.

- Fushigi

 

[blakerwry]

you might be able to realease the socket by disabling/enabling your NIC (i assume you are using static IP's so you cant just release/renew your IP)

 

[Fushigi]

you might be able to realease the socket by disabling/enabling your NIC (i assume you are using static IP's so you cant just release/renew your IP)

You're correct on the static IP.

Actually, the vendor found the bug (along with another bug we didn't have!) late Thursday and is architecting a solution. We should have a hot fix in a few days.

- Fushigi

 

[Handruin]

I thought this might help for booting with only 1 CPU...scroll down for the section in red:

Startup Process


Selecting the Operating System
NTLDR displays the bootstrap loader screen, where you can select an operating system to start. This screen is based upon the information in the Boot.ini file. The screen display is similar to the following:


Please select the operating system to start:



Windows 2000 Advanced Server




Use ­ and ¯ to move the highlight to your choice.


Press ENTER to choose.




Seconds until highlighted choice will be started automatically: 29




For troubleshooting and advanced startup options for Windows 2000, press F8.



If you do not select an entry before the counter reaches zero, NTLDR loads the operating system specified by the default parameter in the Boot.ini file. Windows 2000 Setup sets the default entry to the most recently installed copy of Microsoft® Windows NT® version 4.0 or earlier. You can edit the Boot.ini file if you want to change the default to either an earlier version of Windows 2000 or to another operating system.

Windows 2000 Setup places the Boot.ini file in the active partition. NTLDR uses information in the Boot.ini file to display the bootstrap loader screen from which you select the operating system.

The following is an example of a Boot.ini file:


[boot loader]


timeout=30


default=multi(0)disk(0)rdisk(0)partition(1)\WINNT


[operating systems]


multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows 2000 Server" /fastdetect



The Boot.ini file has two sections, [boot loader] and [operating systems]. You can use the parameters in the [boot loader] section to customize startup, as described in Table 15.2.

Table 15.2 Bootstrap Loader Parameters

Parameter Description
Time-out The time that the user has to select an operating system from the bootstrap loader screen before NTLDR loads the default operating system.
If the time-out value is 0, NTLDR immediately starts the default operating system without displaying the bootstrap loader screen.
If you set this value to –1, NTLDR waits indefinitely for you to make a selection. You must edit the Boot.ini file directly because –1 is an illegal value for the System option in Control Panel.

Default The ARC pathname to the default operating system.


Each entry in the [operating systems] section includes the ARC pathname to the boot partition for the operating system, the string to display on the bootstrap loader screen, and optional parameters. The bootstrap loader screen presented earlier in this chapter is an example of the use of this section of the Boot.ini file.

You can use the Boot.ini file to start multiple versions of the Windows 2000 operating system, as well as one other operating system, including Microsoft® MS-DOS®, Microsoft® Windows® 95, and Microsoft® Windows® 98.

Boot.ini Switches
The switches listed in Table 15.3, which can be added to the end of the [operating system] section of the Boot.ini file, are not case sensitive. For more information about the /MAXMEM and /SOS switches, see "Problem Occurs After the Bootstrap Loader Starts" later in this chapter. The switch you want to add must be placed on a separate line of the Boot.ini file.

Table 15.3 Boot.ini Switches

Switch Description
/BASEVIDEO The computer starts up using the standard VGA video driver. If you have installed a new video driver and it is not working correctly, you can select the Windows 2000 entry with this switch to start the computer and change to a different driver.
/BAUDRATE=nnnn Specifies the baud rate to be used for debugging. The default baud rate is 9600 if a modem is attached, and 19200 for a null-modem cable. Including this switch in the Boot.ini file causes the /DEBUG switch to activate.
/CRASHDEBUG The debugger is loaded when you start Windows 2000, but remains inactive unless a kernel error occurs. This switch is useful if you are experiencing random kernel errors.
/DEBUG The debugger is loaded when you start Windows NT, and can be activated at any time by a host debugger connected to the computer. Use this switch when you are debugging problems that are regularly reproducible.
/DEBUGPORT= comx Specifies the communications port to use for debugging, where x is the communications port that you want to use. Including this switch in the Boot.ini file causes the /DEBUG switch to activate.
/MAXMEM:n Specifies the maximum amount of RAM that Windows 2000 can use. Use this switch if you suspect that a memory chip is bad.
/NODEBUG No debugging information is being used.
NUMPROC=x Allows you to force a multiprocessor computer to start up with < n processors.
/FASTDETECT =[COMx | COMx,y,z...] Turns off serial and bus mouse detection in NTDETECT. Use this switch if you have a component other than a mouse attached to a serial port during the startup process. If you use /FASTDETECT without specifying a communications port, serial mouse detection is disabled on all communications ports.
/SOS Displays the device driver names as they are being loaded. Use this switch when startup fails (while loading drivers), to determine which driver is triggering the failure.
/PAE Specify the /PAE switch with the corresponding entry in Boot.ini to allow a computer that supports physical address extension (PAE) mode to start normally. In safe mode, the computer starts using normal kernels even if the /PAE switch is specified.


Editing Boot.ini
When you install Windows 2000, the read-only, system, and hidden attributes of the Boot.ini file are set. Regardless of the value of these attributes, you can edit the timeout and default parameters in the Boot.ini file using the System option in Control Panel.

To edit the Boot.ini file with a text editor, you need to make the file visible and turn off the read-only attribute. You can change file attributes using My Computer or at the command prompt.

To change file attributes using My Computer

On the Tools menu, click Folder Options.
On the View tab, double-click Hidden files and folders.
Select either Do not show hidden files and folders or Show hidden files and folders.
Click OK.


Important

If you change the path to the Windows 2000 boot partition, make sure to edit both the default path and operating system path entries. If you change one but not the other, a new choice is designated as the default selection and added to the bootstrap loader screen.

© 1985-2000 Microsoft Corporation. All rights reserved.

 

[Fushigi]

What we never saw regarding the /NUMPROC & the /ONECPU parms are what is the effect, if any, on the HAL if setting /NUMPROC=1? The HAL is different for a uni-processor machine vs. multi-processor. All of the examples everywhere were saying setting it from 4 to 3; not one ever mentioned setting it to 1 and if that would have an effect on the HAL. Oc course, most are just copies of MS' documentation, which also fails to mention if there are any HAL affects.

- Fushigi

 

[Pradeep]

I believe you can run the ACPI Multiprocessor PC HAL with one or more CPU's. It's when you try and switch from Standard to ACPI HAL that Windows will shit itself.

 

[Will Rickards WT]

Windows will shit itself.

That makes me think of a correlation between windows and my medical problem - irritable bowel syndrome. Maybe windows has irritable code syndrome. If windows regulary takes its fiber (reboots? defrags? just plain attention?) and sticks to not too fatty foods (buggy software?) it is regular and has great MTBF. If on the other hand this procedure is not followed, you have almost daily diarrhea.