Re: What would you like in DF 1.8?

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

Michel Talon,,,01 60 15 58 14 wrote:

> Steve O'Hara-Smith wrote:
>
>
>
> > Well since all of that can be obtained elsewhere I would be very
> > happy to see it stacked behind the clustering behaviour that Matt has
> > already outlined as the primary goal because that *cannot* be obtained
> > elsewhere.

Sure it can.  Just with a different methodology and priority set.

And a higher price-tag.

Cost-no-object, I'd go with well-proven IBM S390, IBM AIX, either with HACMP on 
Power architecture, or Solaris on T1, in that order.

As system architecture consultants for large projects, we have done just that.

In one case, the only choices permitted were '(hardware) vendor supported Unix', 
leaving out *BSD by implication, and Linux by specific prohibition.

But for most projects, cost IS an object, so I am interested in DragonFly.

> I must be dreaming, what are running all those high performance clusters
> which appear in the Top500, and are supposed to be based on Linux?

The top 500 research 'puters have as much bearing on volume computing as Formula 
One race cars do on the trucking industry. Now and then one gets a better 
brake-lining material, bearing design, or lubricant formulation out of it all, 
otherwise mostly publicity and excitement.

> Perhaps something like
> http://openssi.org/cgi-bin/view?page=features.html
>
> I could not swear it, but from memory it is more than 5 years and perhaps
> much more than functional solutions exist for Linux, with all kernel hooks
> and much more than  have been proposed here.

No need to rely on memory. Wikipedia has a reasonably accurate article.

But DragonFly appears to have its sights set a lot higher than *most* prior art, 
not just Linux or legacy 'big iron'.

Admirably, the DragonFly team is carrying both *BSD's legacy 'world' on their 
back, AND the 'C' language limitations and libs baggage.

I would bet that not one person in a hundred here - many developers included - 
recognize just how massive a *burden*, rather than advantage that is compared to 
a clean-slate effort. 'C' and its libs, the whole Unix 'world' can fall into the 
'when the only tool you have is a hammer...' category.

Nor why it means that at each stage DragonFly has proved a far more attractive 
'world' to a server admin that distro-of-the-day.

That 'baggage' has been very  expertly carried.

> Not to mention older
> distributed computing projects like amoeba by Tanenbaum. And by the way,
> who has the money to run such clusters, besides big corporations and 
> big academic labs?

'project's' in particular, and academia in general are learning tools, seldom 
production environments. Examples, not templates.

Thousands of SME, and at least as many departments/divisions/branch offices 
within larger enterprises, finance houses in particular, ran VAX/VMS, HP-MPE, 
Perkin-Elmer, Tandem, or Solaris clusters. Larger firms ran closely-coupled IBM 
Big Iron clustering.

Most of these clusters handled mundane tasks such as telecoms switching, utility 
grid management, *everybody's* billing, inventory, manufacturing, banking, 
brokerage, and POS systems.

WTH - Cable & Wireless used VAX/VMS clusters in the UK to manage private-network 
work-orders and trouble tickets, and Perkin-Elmer clusters in the US to manage 
network switching and billing. Telco networks and power grids are only allowed a 
few seconds *per year* of outage.

All in the 1980's, BTW.

NORAD had clustering and failover in the 60's before ARPAnet even started. Over 
9,000 miles of hardened deep-underground private network. Resilient auto-route 
packet technology was developed so they didn't have to mortgage the entire 
planet to build  *more* of that!

> How much does cost Myrinet and other Infiniband hardware
> necessary to ensure low enough latency so that distributed computing has
> a small chance of being a realistic proposition?

That's all relative, and near-instantaneous b/w is a seldom needed special-case.

Research and 'modeling' establishments aside, in the business world, robust, 
high availability applications and reliable distributed storage have always been 
more important that moving CPU-cycles about. 80% I/O, 20% CPU is still the rule 
of thumb for biz apps.

Same-room clusters have had proprietary high-speed links for ages, and 10-Gig-E, 
Gig-E, and even 100 BT are more than adequate for most day-to-day needs.

> The present and foreseable
> future of affordable computing is multiprocessor machines, with perhaps up
> to 32 virtual processors (Sun machines). Being scalable on such hardware is
> a realistic goal, Solaris does it, Linux does it, both using traditional
> solutions. Maybe Dragonfly can do it with innovative solutions.

*Everybody* does it.

Don't confuse Linux 'projects' & PR with other folks actual deliveries over a 
quarter of a century.

It isn't 'clustering', nor even SMP or SMP/AMP hybrid MP (OS/2) that are 'new'.

What is 'new' is DragonFly's approach - as clean a break as can be had from 
legacy-bound thinking as to how a *BSD-style* kernel & resource set(s) can work 
best to support 'placeless', portable, hot-swappable goods in a near-as-dammit 
seamless manner.

If all goes well, DragonFly may prove to be *way* better than most F/OSS prior 
art - for both local and remote resources.

If not, 'Drag-On, Fly' will still represent a marvelous cleanup and improved 
understanding of code that can be utilized to some extent in the *BSD's in 
general - as with lessons learned from the 'trusted' and 'secure' *BSD efforts.

IOW - DragonFly has already gone far enough that it cannot 'fail' - just succeed 
to a greater or lesser degree.

;-)

Bill Hacker