Disable hyper-threading from the DCL prompt

[RGB]

Hi all,

We have several x2800 i2's running VMS v8.4 and I seem to recall a command, issued from the DCL prompt, which disables hyper-threading at the CPU's. I know there is another way to do so from EFI but I thought it was also possible to do so from DCL. (Knowing that it will not take effect until the next reboot.)

Can someone please refresh my feeble mind as to the command?

Thanks in advance.

Rich

[RGB]

Never mind all, I figured it out:

hthread :== $sys$test:hthreads.exe

hthread off

Regards,
Rich

[Michael Moroney]

RGB <11b...@gmail.com> writes:

>Hi all,

>We have several x2800 i2's running VMS v8.4 and I seem to recall a command,=
> issued from the DCL prompt, which disables hyper-threading at the CPU's. =
>I know there is another way to do so from EFI but I thought it was also pos=
>sible to do so from DCL. (Knowing that it will not take effect until the n=

>ext reboot.)

>Can someone please refresh my feeble mind as to the command?

>Thanks in advance.

$ hthreads :== $SYS$COMMON:[SYSTEST]hthreads
$ hthreads help

You should try both ways to see if threads help or hurt. CPU-intensive
jobs that run in parallel tend to be helped by threads. Systems where
there is a lot of contention for spinlocks (heavy I/O, locks in clusters
etc) can be hurt by them.

[Stephen Hoffman]

Beyond that htread.exe tool, the SET CPU /NOCOTHREAD command is also
available per
<https://view.officeapps.live.com/op/view.aspx?src=http%3A%2F%2Fde.openvms.org%2FTUD2008%2FHyperthread_Support_in_OpenVMS_V8.ppt>,
though it does not appear that this DCL command was documented in the
help libraries — more fodder for VSI to ponder.

The command is honored on an OpenVMS V8.4 test server, without errors.
Whether it works as intended, I did not check — the test server does
not support hyperthreads.

--
Pure Personal Opinion | HoffmanLabs LLC

[Michael Moroney]

Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:

>Beyond that htread.exe tool, the SET CPU /NOCOTHREAD command is also
>available per
><https://view.officeapps.live.com/op/view.aspx?src=http%3A%2F%2Fde.openvms.org%2FTUD2008%2FHyperthread_Support_in_OpenVMS_V8.ppt>,
>though it does not appear that this DCL command was documented in the
>help libraries — more fodder for VSI to ponder.

Interesting. I did not know about that.

>The command is honored on an OpenVMS V8.4 test server, without errors.
>Whether it works as intended, I did not check — the test server does
>not support hyperthreads.

I just tried it, it appears to be equivalent to a $ STOP/CPU on the
cothread CPU. Whether there's a difference, I don't know, but SHOW
CPU shows the cothread as stopped.

Selective STOP/CPU (or SET CPU /NOCOTHREAD) commands on processors
assigned to Fastpath for a device may help, since a performance
hit can happen if one thread owns a spinlock and its cothread is spinning
waiting for that spinlock. That's why the bigger hammer of turning off
(all) threads often helps.

[John Reagan]

From one of the authors of SET CPU /NOCOTHREAD

"what it does is to return one of the hyper threads to the loader; the loader then puts it into a semi-infinite loop where it does a (can't remember the pal call, but essentially a give up control to the other hyper thread). It is not quite as good (in the sense of giving back all the cycles of the core to a single cpu) as turning hyper threads off entirely with HTHREADS or with the efi command CPUCONFIG. However these later two require you to reboot once for HTHREADS and twice (well, two resets) for CPUCONFIG."

I'll make sure the help gets updated.

[Hein RMS van den Heuvel]

Several years back I did several HT experiments.

At that time I could not detect any performance difference between HYperthreading not having been enabled and having it enabled but with all co-threads de-activated (STOP /CPU).

As such I recommend to always boot with HT enabled to be able to activate without reboot when you feel like it.

Your mileage will vary, but from my experience for an underloaded systems ( < 50% cpu) HT does not help, but does not hurt either.
For overloaded systems ( > 90% cpu, frequent COM queue > 5 ) I find that HT allows one to stretch the performance enveloppe some. It gives the system a bit of elasticity if you like. It softens the 'knee' and you can expect more aggregate throughput, with some response time degradation of course.

fwiw,
Hein

[John Reagan]

If any of you folks are going to get i4's (I would suggest everybody here buy at least 2 each please), the HT in the Poulson is supposedly better than prior chips. Programs that might not have benefited from HT in the past, should try it again with an i4 machine

[JF Mezei]

Question:

Will the move to x86 require VMS add support for fancy CPU features that
can be turned on/off like hyperthreading ?

Operating systens liek OS-X seem to have plenty of automated features
for energy saving, core managemnt, shutting down cores when not needed
etc. Wondering if VMS will HAVE to support any of those, or "SHOULD"
surpport any of those or whether those are more marketing PR gimmicks
that are not actually needed in real data centres ?

[clairg...@gmail.com]

VMS provides the low-level interfaces to some features like these on Itanium and I assume we will on x86. It is then a matter for system management applications to use them.

[Stephen Hoffman]

On 2015-03-06 21:28:50 +0000, JF Mezei said:

> Question:
>
> Will the move to x86 require VMS add support for fancy CPU features
> that can be turned on/off like hyperthreading ?

Baseline power management and hyperthreading support are already
available on OpenVMS I64. This as JF already knows.

> Operating systens liek OS-X seem to have plenty of automated features
> for energy saving, core managemnt, shutting down cores when not needed
> etc. Wondering if VMS will HAVE to support any of those, or "SHOULD"
> surpport any of those or whether those are more marketing PR gimmicks
> that are not actually needed in real data centres ?

Duh. But then JF already knows this is a "duh", of course.

Data centers are often interested in lowering their power and cooling
requirements, which means that mechanisms for reducing power and for
powering down some or most of a server can be of interest. OS X and
iOS do have integrated, automated mechanisms for saving power, though
these are for general efficiency and battery life — in practical terms,
longer battery life isn't usually a central goal that most data centers
are interested in, but sipping power and lowering cooling loads
definitely is.
<http://en.wikipedia.org/wiki/Green_computing#Data_center_power> The OS
X and iOS mechanisms use various approaches, such as seeking to
coalesce interrupts across multiple applications to allow the cores to
stay powered down longer, fast suspend and restarts, as well as other
techniques that seek to keep the system and the processors and the
peripherals in lower-powered states or even powered down.

What is coalescing interrupts? If you have a dozen active processes
and each with, for instance, scheduled interrupts at one-second
intervals, then having all of those interrupts hit in quick succession
across one or more cores can mean that the processor cores can power
down for longer, as differentiated from having those same dozen
one-second interrupts scattered throughout each second across
potentially random cores, and leaving the entire processor and its
various cores and the memory caches that can be present or can be
flushed in each core in a state analogous to flailing.

Certainly for cases requiring absolute server and application
responsiveness, programmers and system administrators don't want to see
peripherals in low-powered states that need to be quickly accessed, but
for environments where the associated latency of powering up devices is
less central, then the power savings can be interesting. Some folks
might not want to see some or all of their disks spun down for
instance, but others will want the power and cooling savings that can
be realized from powering down parts of a rotating-rust array, and
other folks might well be well along migrating to solid-state storage
and which is both more efficient and usually powers up much faster than
rotating rust.

<http://www.energystar.gov/ia/partners/prod_development/downloads/DataCenters_GreenGrid02042010.pdf>,
starting around page 14.
<http://www.energystar.gov/ia/partners/prod_development/downloads/EPA_Report_Exec_Summary_Final.pdf>

<https://www.energystar.gov/ia/products/power_mgt/downloads/Kaiser_Permanente_case_study.pdf>

<http://www.energystar.gov/ia/products/downloads/ES_server_case_study.pdf>
<http://www.energystar.gov/ia/products/power_mgt/ES_Data_Center_Utility_Guide.pdf>

etc.

The application and the server operating system software is a core part
of this discussion, as it is the software that increasingly controls
the energy-reducing features of many of the current-generation
computers, and some or all of the future-generation computers.

Wrapping this back to OpenVMS specifically, the Itanium and Alpha boxes
are — for the amount of local use that they can get at many sites —
much less efficient than x86-64 servers, due to the technologies used
in the older designs, and due to the sheer size and expandability of
the boxes involved. A two-core i2- or i4-class Itanium is a huge box.
Some folks need that, but some don't and can seek to consolidate
(not-OpenVMS) environments using VMs or Docker containers or similar
mechanisms. Consolidation is a given, and going to smaller boxes, and
the boxes are only getting smaller and/or denser[1]. The associated
costs of power and cooling are only going to increase, too. Put
another way, it's a completely different world for OpenVMS now, and
power and cooling are always going to be a factor.

______
[1] A Mac Pro would be a decent-sized Alpha, in terms of the numbers of
cores (up to 12 cores) and the maximum memory (up to 64 GB) supported,
and I'd tend to expect the Mac Pro to be somewhere between faster and
much faster than most Alpha boxes, and faster than at least the
early-generation Itanium boxes, too

[Michael Moroney]

JF Mezei <jfmezei...@vaxination.ca> writes:

>Question:

>Will the move to x86 require VMS add support for fancy CPU features that
>can be turned on/off like hyperthreading ?

VMS already supports hyperthreading on Itanics. That's what started this
whole thread.

>Operating systens liek OS-X seem to have plenty of automated features
>for energy saving, core managemnt, shutting down cores when not needed
>etc. Wondering if VMS will HAVE to support any of those, or "SHOULD"
>surpport any of those or whether those are more marketing PR gimmicks
>that are not actually needed in real data centres ?

Look up sys$power_control on itanics. I've already tested it on I4s.
There are some features of high end Alphas, such as powering off
individual CPUs, that don't seem to be available on Itanium at this time.
Hopefully these don't slip through the cracks when moving to x86.