MPDELAYZ parameter - Revision history

JDamon: Typo corrections

2019-01-30T06:40:04Z

Typo corrections

← Older revision		Revision as of 06:40, 30 January 2019
Line 24:		Line 24:
	<li><var>MPDELAYZ</var> has no effect if either of these is true:		<li><var>MPDELAYZ</var> has no effect if either of these is true:
	<ul>		<ul>
	<li>~~MP/204 is~~ not in effect in an Online (<var>NMPSUBZ</var> is 0).</li>		<li>zIIP SRBs are not in effect in an Online (<var>NMPSUBZ</var> is 0).</li>
	<li>The number of active ~~szIIP ubtasks~~ (<var>AMPSUBZ</var>) is set to 0 or 1. (If <var>AMPSUBZ</var> is 1, a zIIP subtask is activated as soon as there is any zIIP runnable work, and it then runs until there is no more zIIP capable work for it to process.)</li>		<li>The number of active zIIP subtasks (<var>AMPSUBZ</var>) is set to 0 or 1. (If <var>AMPSUBZ</var> is 1, a zIIP subtask is activated as soon as there is any zIIP runnable work, and it then runs until there is no more zIIP capable work for it to process.)</li>
	</ul></li>		</ul></li>

JAL: misc formatting

2016-08-02T21:04:05Z

misc formatting

← Older revision		Revision as of 21:04, 2 August 2016
Line 19:		Line 19:
	<p>		<p>
	The default <var>MPDELAYZ</var> value of 0 means that if the number of units of work queued to zIIP subtasks exceeds the limit indicated by the <var>SCHDOFLZ</var> parameter, a zIIP subtask is immediately started. The benefit of setting <var>MPDELAYZ</var> to a non-zero value is seen when a burst of work units arrive: it prevents the immediate starting of a large number of zIIP subtasks only to have most of them quickly deactivate because too many were started for the amount of work to be done. Such demand bursts are a common occurrence when dealing with critical file resource conflicts, and activating and deactivating zIIP subtasks can have non-trivial CPU costs.</p>		The default <var>MPDELAYZ</var> value of 0 means that if the number of units of work queued to zIIP subtasks exceeds the limit indicated by the <var>SCHDOFLZ</var> parameter, a zIIP subtask is immediately started. The benefit of setting <var>MPDELAYZ</var> to a non-zero value is seen when a burst of work units arrive: it prevents the immediate starting of a large number of zIIP subtasks only to have most of them quickly deactivate because too many were started for the amount of work to be done. Such demand bursts are a common occurrence when dealing with critical file resource conflicts, and activating and deactivating zIIP subtasks can have non-trivial CPU costs.</p>
	<p>
	<var>MPDELAYZ</var> has no effect if either of these is true: ~~</p>~~		==Usage notes==
			<ul>
			<li><var>MPDELAYZ</var> has no effect if either of these is true:
	<ul>		<ul>
	<li>MP/204 is not in effect in an Online (<var>NMPSUBZ</var> is 0).</li>		<li>MP/204 is not in effect in an Online (<var>NMPSUBZ</var> is 0).</li>
	<li>The number of active szIIP ubtasks (<var>AMPSUBZ</var>) is set to 0 or 1. (If <var>AMPSUBZ</var> is 1, a zIIP subtask is activated as soon as there is any zIIP runnable work, and it then runs until there is no more zIIP capable work for it to process.)</li>		<li>The number of active szIIP ubtasks (<var>AMPSUBZ</var>) is set to 0 or 1. (If <var>AMPSUBZ</var> is 1, a zIIP subtask is activated as soon as there is any zIIP runnable work, and it then runs until there is no more zIIP capable work for it to process.)</li>
	</ul>		</ul></li>
	<p>
	If <var>MPDELAYZ</var> is set, consider reducing <var>SCHDOFLZ</var> to 1 or 0, since both parameters attempt to solve the same problem (too much zIIP subtask activation/deactivation). Using both parameters can reduce throughput or response times.</p>		<li>If <var>MPDELAYZ</var> is set, consider reducing <var>SCHDOFLZ</var> to 1 or 0, since both parameters attempt to solve the same problem (too much zIIP subtask activation/deactivation). Using both parameters can reduce throughput or response times.</li>

			<li>An additional benefit of using <var>MPDELAYZ</var> is that delaying the starting of zIIP subtasks delays an MP subtask's taking of work from the zIIP offload queue — MP subtasks do not process zIIP work unless all <var>AMPSUBZ</var> zIIP subtasks are active.
			</li></ul>

			==See also==
	<p>		<p>
	The <var>[[MPDELAY parameter\|MPDELAY]]</var> parameter provides the same functionality as <var>MPDELAYZ</var> for MP (non-zIIP/SRB) subtasks.		The <var>[[MPDELAY parameter\|MPDELAY]]</var> parameter provides the same functionality as <var>MPDELAYZ</var> for MP (non-zIIP/SRB) subtasks.
	~~</p>~~
	~~<p>~~
	An additional benefit of using <var>MPDELAYZ</var> is that by delaying starting zIIP subtasks, it will delay when a MP subtask might take work from the zIIP offload queue – MP subtasks will not process zIIP work unless all <var>AMPSUBZ</var> zIIP subtasks are active.
	</p>		</p>

	[[Category:System parameters]]		[[Category:System parameters]]
	[[Category:Parameters]]		[[Category:Parameters]]

JAL: wordsmithing

2016-08-02T19:53:58Z

wordsmithing

← Older revision		Revision as of 19:53, 2 August 2016
Line 18:		Line 18:
	This parameter specifies the number of milliseconds to delay starting additional zIIP/SRB subtasks when an extra one should be started based on <var>[[SCHDOFLZ parameter\|SCHDOFLZ]]</var>.</p>		This parameter specifies the number of milliseconds to delay starting additional zIIP/SRB subtasks when an extra one should be started based on <var>[[SCHDOFLZ parameter\|SCHDOFLZ]]</var>.</p>
	<p>		<p>
	The default value of 0 means that if the number of units of work queued to zIIP subtasks exceeds ~~some~~ limit as indicated by the <var>SCHDOFLZ</var> parameter, a zIIP subtask is immediately started. The benefit of setting <var>MPDELAYZ</var> to a non-zero value is ~~that~~ it prevents a large number of zIIP 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 zIIP subtasks can have non-trivial CPU costs.</p>		The default <var>MPDELAYZ</var> value of 0 means that if the number of units of work queued to zIIP subtasks exceeds the limit indicated by the <var>SCHDOFLZ</var> parameter, a zIIP subtask is immediately started. The benefit of setting <var>MPDELAYZ</var> to a non-zero value is seen when a burst of work units arrive: it prevents the immediate starting of a large number of zIIP subtasks only to have most of them quickly deactivate because too many were started for the amount of work to be done. Such demand bursts are a common occurrence when dealing with critical file resource conflicts, and activating and deactivating zIIP subtasks can have non-trivial CPU costs.</p>
	<p>		<p>
	<var>MPDELAYZ</var> has no effect if either of these is true: </p>		<var>MPDELAYZ</var> has no effect if either of these is true: </p>

JAL: minor wordsmithing

2016-08-02T19:20:15Z

minor wordsmithing

← Older revision		Revision as of 19:20, 2 August 2016
Line 26:		Line 26:
	</ul>		</ul>
	<p>		<p>
	If <var>MPDELAYZ</var> is set, ~~it might make sense to reduce~~ <var>SCHDOFLZ</var> to 1 or ~~maybe even~~ 0 as both parameters attempt to solve the same problem (too much zIIP subtask activation/deactivation) ~~and using~~ both can reduce throughput or response times.</p>		If <var>MPDELAYZ</var> is set, consider reducing <var>SCHDOFLZ</var> to 1 or 0, since both parameters attempt to solve the same problem (too much zIIP subtask activation/deactivation). Using both parameters can reduce throughput or response times.</p>
	<p>		<p>
	The <var>[[MPDELAY parameter\|MPDELAY]]</var> parameter provides the same functionality as <var>MPDELAYZ</var> for MP (non-zIIP/SRB) subtasks.		The <var>[[MPDELAY parameter\|MPDELAY]]</var> parameter provides the same functionality as <var>MPDELAYZ</var> for MP (non-zIIP/SRB) subtasks.

JAL: /* Usage notes */ minor formatting

2016-08-02T18:40:11Z

Usage notes: minor formatting

← Older revision		Revision as of 18:40, 2 August 2016
Line 16:		Line 16:
	==Description==		==Description==
	<p>		<p>
	This parameter specifies the number of milliseconds to delay starting additional zIIP/SRB subtasks when an extra one should be started based on [[SCHDOFLZ parameter\|SCHDOFLZ]].</p>		This parameter specifies the number of milliseconds to delay starting additional zIIP/SRB subtasks when an extra one should be started based on <var>[[SCHDOFLZ parameter\|SCHDOFLZ]]</var>.</p>
	<p>		<p>
	The default value of 0 means that if the number of units of work queued to zIIP subtasks exceeds some limit as indicated by the <var>SCHDOFLZ</var> parameter, a zIIP subtask is immediately started. The benefit of setting MPDELAYZ to a non-zero value is that it prevents a large number of zIIP 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 zIIP subtasks can have non-trivial CPU costs.</p>		The default value of 0 means that if the number of units of work queued to zIIP subtasks exceeds some limit as indicated by the <var>SCHDOFLZ</var> parameter, a zIIP subtask is immediately started. The benefit of setting <var>MPDELAYZ</var> to a non-zero value is that it prevents a large number of zIIP 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 zIIP subtasks can have non-trivial CPU costs.</p>
	<p>		<p>
	<var>MPDELAYZ</var> has no effect if either of these is true: </p>		<var>MPDELAYZ</var> has no effect if either of these is true: </p>
Line 28:		Line 28:
	If <var>MPDELAYZ</var> is set, it might make sense to reduce <var>SCHDOFLZ</var> to 1 or maybe even 0 as both parameters attempt to solve the same problem (too much zIIP subtask activation/deactivation) and using both can reduce throughput or response times.</p>		If <var>MPDELAYZ</var> is set, it might make sense to reduce <var>SCHDOFLZ</var> to 1 or maybe even 0 as both parameters attempt to solve the same problem (too much zIIP subtask activation/deactivation) and using both can reduce throughput or response times.</p>
	<p>		<p>
	The [[MPDELAY parameter]] provides the same functionality as <var>MPDELAYZ</var> for MP (non-zIIP/SRB) subtasks.		The <var>[[MPDELAY parameter\|MPDELAY]]</var> parameter provides the same functionality as <var>MPDELAYZ</var> for MP (non-zIIP/SRB) subtasks.
	</p>		</p>
	<p>		<p>
	An additional benefit of using <var>MPDELAYZ</var> is that by delaying starting zIIP subtasks, it will delay when a MP subtask might take work from the zIIP offload queue – MP subtasks will not process zIIP work unless all <var>AMPSUBZ</var> zIIP subtasks are active.		An additional benefit of using <var>MPDELAYZ</var> is that by delaying starting zIIP subtasks, it will delay when a MP subtask might take work from the zIIP offload queue – MP subtasks will not process zIIP work unless all <var>AMPSUBZ</var> zIIP subtasks are active.
	</p>		</p>

	[[Category:System parameters]]		[[Category:System parameters]]
	[[Category:Parameters]]		[[Category:Parameters]]

Alex: Created page with "{{Template:MPDELAYZ parameter subtitle}} ==Summary==

Default value
0
Parameter type
System
Where set
On User 0's parameter line or reset by system..."

2016-08-02T05:25:59Z

Created page with "{{Template:MPDELAYZ 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..."

New page

{{Template:MPDELAYZ 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 manager.
<dt>Related products
<dd>All
<dt>Introduced
<dd><var class="product">Model 204 V7.7</var>
</dl>

==Description==

This parameter specifies the number of milliseconds to delay starting additional zIIP/SRB subtasks when an extra one should be started based on [[SCHDOFLZ parameter|SCHDOFLZ]].

The default value of 0 means that if the number of units of work queued to zIIP subtasks exceeds some limit as indicated by the <var>SCHDOFLZ</var> parameter, a zIIP subtask is immediately started. The benefit of setting MPDELAYZ to a non-zero value is that it prevents a large number of zIIP 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 zIIP subtasks can have non-trivial CPU costs.

<var>MPDELAYZ</var> has no effect if either of these is true: 
<ul>
<li>MP/204 is not in effect in an Online (<var>NMPSUBZ</var> is 0).</li>
<li>The number of active szIIP ubtasks (<var>AMPSUBZ</var>) is set to 0 or 1. (If <var>AMPSUBZ</var> is 1, a zIIP subtask is activated as soon as there is any zIIP runnable work, and it then runs until there is no more zIIP capable work for it to process.)</li>
</ul>

If <var>MPDELAYZ</var> is set, it might make sense to reduce <var>SCHDOFLZ</var> to 1 or maybe even 0 as both parameters attempt to solve the same problem (too much zIIP subtask activation/deactivation) and using both can reduce throughput or response times.

The [[MPDELAY parameter]] provides the same functionality as <var>MPDELAYZ</var> for MP (non-zIIP/SRB) subtasks.


An additional benefit of using <var>MPDELAYZ</var> is that by delaying starting zIIP subtasks, it will delay when a MP subtask might take work from the zIIP offload queue – MP subtasks will not process zIIP work unless all <var>AMPSUBZ</var> zIIP subtasks are active.

[[Category:System parameters]]
[[Category:Parameters]]