[Info-vax] Gen-Z, a new memory interconnect on the horizon.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf
> Of Baldrick via Info-vax
> Sent: 31-Oct-16 8:55 AM
> To: info-vax at rbnsn.com
> Cc: Baldrick <trickynic at gmail.com>
> Subject: Re: [Info-vax] Gen-Z, a new memory interconnect on
> the horizon.
> 
> ...
> 
> One of my clients use reflective memory. They obtained the
> drivers from the manufacturer VMIC (HP did facilitate this) and
> ported from Alpha to Integrity. I'm not completely conversant
> with its operation but it allows multiple platforms to share
> memory in application space between a number of platforms. So
> the VMS system sees memory from UNIX and M$ windows but
> no reason why VMS cannot see VMS of course. I'm not sure of
> the topology but its exceptionally high speed as its doing real
time
> processing on a number of systems (including VMS) to deliver
the
> application.
> 
> https://en.wikipedia.org/wiki/Reflective_memory
>

OpenVMS has a solid history of dealing with shared memory
technologies - even back to the VAX days. A 11/782 and 11/784
were either 2 or 4 VAX 11780's interconnected with MA780 shared
memory. I fondly remember installing a couple of these back in
the day. They were a cabling nightmare, but worked very well. The
OpenVMS Galaxy (Alpha only) technology was (is) way ahead of the
competition. Galaxy provided the means to "dynamically" share
CPU's via drag-n-drop and/or business rules between different OS
instances and at the same time, provided very high speed
communications for TCPIP, cluster traffic via shared memory.

Even though it's a bit older technology, reflective memory is
just one example of how current compute models will be changing
significantly in the future

The models today and really since the late 80's, are basically
many smaller systems distributed over Ethernet based networks.
This is often referred to as the "wild west" of the 80's, 90's
and in many cases, even today. There were good reasons for doing
this i.e. lack of local memory, compute and interconnect
technologies and Ethernet was cheap, but effective way to address
overall solution latency and data compute requirements. 

So what has changed?

1. VM sprawl has now become a much bigger issue than X86 sprawl.
The biggest costs (by far) are not associated with physical HW,
but rather licensing, managing and securing the OS instance
itself. Its why so many are looking at container technologies
like Docker.

2. While a distributed world is much better at local
communications with end users and the Customer, IT management
costs and security concerns are much higher in a highly
distributed world than a centralized one.

3. The biggie technical change - how to move massive amounts of
data closer to the CPU where it can be crunched and reduce the
overall "solution latency". This is sometimes called "function
shipping" i.e. the separating of logical and physical tiers with
each tier having its own dedicated server(s) communicating over
LAN networks as a means to better address compute requirements.
However, while CPU, Memory and Storage  technologies have
increased exponentially, network LAN latency has not kept up
(TCPIP stack, buffer, NIC, firewall, router hops, load balancers
etc.) in a multi-tier compute model all contribute to LAN network
latency which, in turn, significantly impacts overall solution
latency. 

In relative terms, while todays cpu-cache, cpu to memory, cpu to
local flash disk can be measured in relative terms of secs,
minutes, days, local LAN network latency updates (writes) can be
measured in months. Now - think about those hundreds, thousands
of small systems all doing updates (including HA replication)
over a highly distributed local network. Think about the impact
this has on limiting the speed of moving data closer to the CPU's
where it needs to be.

Fast forward to today and the next 2-3+ years.

GB level drives are the new floppy drives. This is not hyperbole.
A self-encrypting PC laptop/desktop 10TB 3.5" HDD with 256Mb
cache and limited 5 year warranty is now available for USD $500
(google "Seagate 10TB").

Data that is required to be crunched to address competitive
business requirements has grown exponentially. Much cheaper,
non-Volatile memory e.g. 3D XPoint (pronounced "crosspoint") in
range of TB's is expected to be available from Intel/Micron later
in 2017. Other vendors are expected to have memory products
available with similar features.

Emerging high speed local interconnects, much larger/faster
storage and much larger non-volatile memory technology has
prompted a new way of strategic thinking as a way to reduce
overall solution latency and data compute requirements. 

As an example of a model that could be good for OpenVMS - with
TB's of local non-volatile memory (VSI OpenVMS on HPE Blades
supports up to 1.5TB today), and 32/64 cpu's in a small blade
server, why not keep the App and server layers logically
separated, but physically deploy them on the same system/cluster?
Every reference between the App and DB server instances would be
a local cache/memory reference or at worst, a local IO to flash
storage. With common system disks (yes and planning - remember
TB's of local non-volatile memory, so OpenVMS resides in memory),
you would also make it easier to add systems to the cluster
(select new root, customize and boot new blade).

Yes, you need to do your homework and more up front security,
capacity planning and testing, but these are proactive best
practices that OpenVMS customers have been doing for decades.
Heck, mainframes have been doing this forever and they have a
pretty good record for capacity and security planning.

Background references:
http://bit.ly/2ergVrq 

Original (likely will wrap):
https://www.nextplatform.com/2016/10/17/opening-server-bus-cohere
nt-acceleration/

http://bit.ly/2f5aRpF 

Original (likely will wrap):
https://www.nextplatform.com/2016/10/12/raising-standard-storage-
memory-fabrics/ 

Times are a changing ...

Regards,

Kerry Main
Kerry dot main at starkgaming dot com