MPDELAY parameter: Difference between revisions
(Created page with "{{Template:SCHDOFL parameter subtitle}} ==Summary== <dl> <dt>Default value <dd>0 <dt>Parameter type <dd>System <dt>Where set <dd>On User 0's parameter line or reset by system...") |
No edit summary |
||
| Line 1: | Line 1: | ||
{{Template: | {{Template:MPDELAY parameter subtitle}} | ||
==Summary== | ==Summary== | ||
<dl> | <dl> | ||
Revision as of 05:09, 2 August 2016
Delay before activating subtassk
Summary
- Default value
- 0
- Parameter type
- System
- Where set
- On User 0's parameter line or reset by system manager.
- Related products
- All
- Introduced
- Model 204 V7.7
Description
This parameter specifies the number of milliseconds to delay starting additional MP subtasks when an extra one should be started based on SCHDOFL.
The default value of 0 means that if the number of units of work queued to MP subtasks exceeds some limit as indicated by the SCHDOFL parameter, an MP subtask is immediately started. The benefit of setting MPDELAY to a non-zero value is that it prevents a large number of MP subtasks being started when a burst of units arrive (a common occurrence when dealing critical file resource conflicts) only to have most of them quickly deactivate because too many were started for the amount of work to be done. Activating and deactivating MP subtasks can have non-trivial CPU costs.
MPDELAY has no effect if either of these is true:
- MP/204 is not in effect in an Online (NMPSUBS is 0).
- The number of active subtasks (AMPSUBS) is set to 0 or 1. (If AMPSUBS is 1, an MP subtask is activated as soon as there is any offloadable work, and it then runs until there is no more offloadable work for it to process.)
If MPDELAY is set, it might make sense to reduce SCHDOFL to 1 or maybe even 0 as both parameters attempt to solve the same problem (too much MP subtask activation/deactivation) and using both can reduce throughput or response times.