[Info-vax] Distributed Applications, Hashgraph, Automation

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of Arne
> Vajhøj via Info-vax
> Sent: February 20, 2018 8:58 PM
> To: info-vax at rbnsn.com
> Cc: Arne Vajhøj <arne at vajhoej.dk>
> Subject: Re: [Info-vax] Distributed Applications, Hashgraph, Automation
> 
> On 2/20/2018 2:57 PM, IanD wrote:
> > On Thursday, February 15, 2018 at 6:53:40 AM UTC+11, Arne Vajhøj
> wrote:
> >> On 2/14/2018 1:52 PM, IanD wrote:
> >>> This is indeed interesting news
> >>>
> >>> I know it was posted a while ago but I just saw it
> >>>
> >>> https://www.swirlds.com/vms-software-selects-swirlds-hashgraph-
> as-platform-to-build-secure-distributed-applications/
> >>
> >>> I wonder if Hashgraph has the ability to ultimately replace cluster
> >>> traffic on OpenVMS? It's supposed to scale to I think 200K
> >>> transactions per second, according to the glossy brouchers at least
> >> I think it is a business application thing not an OS thing.
> >>
> >> [application clusters are in many ways doing the same as OS clusters,
> >> but ...]
> >>
> >> After all it is a J thing.
> >>
> >> :-)
> >
> > Yes, it is an application thing
> >
> > But the throughout and number of nodes possible was the interesting
> point to me
> >
> > I thought if it could be adapted (and I have no idea if it can be,
> > I've only watched some video's etc and read the glossy brochures)
> > then it might be a mechanism to allow scaling of VMS clusters beyond
> > the 96 to a few thousand, which I believe Hashgraph can scale to
> 
> It may very well be able to.
> 
> Most non-sharded persisting clusters with more than 1000 nodes are
> Java
> based.
> 
> But the integration from native to Java would be a hassle.
> 
> Arne

Keep in mind that these very large node clusters are typically based on small independent server cpu counts (less than 12) and not that big of memory all connected by ethernet networking. The big challenge is how to keep all of these large numbers of servers busy. It is very high application / data sharding complexity 

Also - by far the biggest source of overall solution latency today is network LAN latency. 

That is why most next gen designs are being designed with fewer server node counts with larger core counts, increased large amounts of shared memory and Infiniband/RoCEv2 technologies as cluster communication interfaces.

Just ask Google - they are introducing Power9 based server solutions into their service offerings.

Btw - Lack of scalability (as compared to natively compiled apps) is why super computers (again, very large numbers of independent servers with small core counts) do not typically use Java.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com