Your instinct is correct. I believe the discussion you are looking for is supercomputing clusters (e.g., Beowolf, etc...) versus shared memory (e.g., SGI/Cray, Sun, etc...) systems. I have a similiar (albeit longer) post and question set above. Check it out if you like.
Most of the IS/IT trade publications and media usually do not fully comprehend the differences between massively multiprocessor systems with shared memory and those clusters of systems and processors with their own local memory, or supercomputing clusters. This is quite evident in a recent article regarding the TPC-D performance between clusterd Compaq Wintel/MSSQL systems and a single, shared memory Sun/Oracle system where the Compaq cluster outperformed the Sun solution in 2 of the 10 standard benchmarks. Basic laws of statistics negate those results because the design of the two systems were not of the same class -- e.g., to be fair, Microsoft-Compaq should have compared performance to an equivalent cluster of lower-costing Sun systems (let alone a Lintel cluster!).
As you and I already know (and I hope everyone reading this now knows), there are several applications where lower costing clusters cannot always do the job of more costly shared memory systems as efficiently (e.g., low-latency, real-time applications such as real-time simluations, come to mind). That is why the Compaq Wintel cluster scored drastically far below the shared Sun system in many of the other 8 benchmarks in the aforementioned study.
As such, I am interested in the considerations the NOAA has had to make in evaluating shared memory versus clustered systems. Specifically:
What are some of the NOAA/NWS programs and software that will not be applicable for execution on this new cluster?
What [estimated] percentage do these programs make up of the total applications the NOAA uses, both quantity and in time of execution?
What [assuming] shared memory systems and solutions does the NOAA use for these applications?
Of course, the lower the number in the first two questions, the more advantageous the existence of a supercomputing cluster is to an organization. For example, in the aerospace industry, the quantity of cluster-efficient applications may be small, but the total execution time of a "run" of these select applications can greatly outweigh all others. Again, speaking from my aerospace background, such applications like Monte Carlo, CFD, 6DOF (six degrees of freedom) runs and simulations are extremely time consuming. Monte Carlo is an ideal application for clustering since each "run" result is complete independent from another (almost linear performance improvement when distributed in a cluster). CFD is very close to linear (~90% efficient) and 6DOF, I would guess, could be as high as 60 or 70%, if it is written to take advantage of distributed computing systems.
The main reason why these engineering applications are so efficient on clusters is the nature of how they use data. They need little to start crunching, and return little. But during the run, they create and use massive ammount of data, which is all "temporary." This is in stark constrast to databases (such as those targetted by the aforementioned TPC-D benchmarks), where data, not computational results, is the focus of the application. By using supercomputing clusters for computational-driven engineering apps, we can save both money on systems and the time of our engineers waiting on results.
As such, I am interested in the overall increase in efficiency you are seeing after the introduction of supercomputing clusters. Specifically:
By executing appropriate applications on supercomputer clusters, what price/performance efficiency do you see over execution on equivalent shared memory systems? [e.g., for CFD, we found equivalently performing supercomputing Linux clusters cost 5-10% of the cost of shared memory systems from Sun and SGI.]
In addition to these computational-intensive applications, do you have any data-intensive applications (if any) that are more price/performance efficient (not necessarily faster overall) on clusters than shared memory systems? [I personally have not been able to justify clusters for such uses, yet]
[ I now work in the semiconductory design industry, and we are looking at acquiring some Linux supercomputing clusters speed up the runs of EDA (electronic design automation) tools like those for IC layout and the like. ]
I appreciate your time and wish your organization and yourself the best wishing in our Linux and OSS endeavors.
Okay. Am I the only one who thinks this is nuts or what?
Now I understand there are laws that are for expediting procedures to protect humans and freedoms. But to enact a law, or extend them, to not only protect, but expedite the prosecution of those who may or may not have violated someone's PROPERY rights, such as profit, IP, etc... at the expense of due process and other, individual freedoms... THIS IS NUTS!
... don't agree with. This is VERY TYPICAL of the US media and journalists out there. You ignore the 95% "good" and pick on the 5% "bad". Again, I see this time and time again.
If anything, the FSF/GNU foundation could be considered a little "radical". But every movement has it's "radical" from the norm, AND THAT IS A VERY GOOD THING! Because 95% of their ideas are "on-the-mark", which is better than most other organizations.
I would argue this is the EXACT SAME THING THE MAINSTREAM MEDIA DOES with regard to the ACLU and NRA. Both are "radical" organizations, picked "apart" by the US media for that 5% that doesn't make sense. But it's that 95% we don't see in the US media that protects our 1st and 2nd Amendments, the #1 and #2 laws of the land that most states required before they would sign the US Constitution.
Take any group, narrow your argument to pick on those "radical" sections that most people don't agree with and you can make just about any case against them. Well done Mr. Meyer, you are no different than the one-dimensional, single-sided, mainstream media that keeps my TV off when the news is on.
First off, you are comparing two entirely different markets. ARM is NOT designed to run in an end-user, general-purpose desktop.
Secondly, StrongARM did go the same as Alpha... to Intel in the cross-license and fab buy-out! Every thing about the main, single reason Intel made the deal points sole at... yes, StrongARM (of course, the nice side-effect was the dropping of the lawsuit -- and Digital wanted to dump its fabs anyway). The damn thing was eating everything up, MIPS, Hitachi, etc... and Intel's own i960 really needed a good replacement.
The smartest thing Intel has done in a long time (at least technically;-) was to buy StrongArm from Digital. Man is StrongArm just gaining market and mindshare or what?!?!?!
But ARM itself (non-StrongARM) is far from dead. It's used in numerous products you use, just like MIPS.
Asynchronous logic with all the benefits -- Although not the most efficient async (Furber's "packetized boolean" is damn good at low-power), it does inherit the low-power, low-EMF generation, high EMI-tolerant characteristics (over clocked boolean). Most people do not realize that can be upto a magnitude of power savings (yes, 1/10th of clocked boolean), let alone the EMF/EMI benefits (e.g., in devices like cell phones or, more critically, pacemakers). [ One really "neat" feature of NCL is the inverter gate, THERE IS NONE! Invert in NCL is simply done by swapping the rails! ]
Nearly 100% delay insensitive -- NCL logic is delay insensitive, and will self-synchronize with any input or output, even if it is coming from a boolean input or going to a boolean output. This is the main problem with most asynchronize technologies! Likewise, it is easy to connect NCL combination logic together for a complete circuit... or an entire chip...
Completely solves the increasing problem of DESIGN RESUSE! -- Following onto #2, because we can always reuse and reuse NCL combinational designs because they are self-synchronizing, we can use the over and over again as the feature sizes shrink, and complexity grows. Every wonder why Intel, AMD, IBM, Motorola and others have to "go back to the drawing board" everytime the feature size shrinks 1-2 times? Because the logic no longer sychronizes between localized modules! NCL is the ONLY WAY to get to custom, repeatable SoC (system on a chip)!
Lastly, NCL can be designed with existing tools -- This is a big plus and not found with really any other major, competing asynchronous method. NCL sounds all "fine and dandy", but who cares if we have to chuck our existing designs and learn it all over again -- well you do NOT. Various, slightly modified, tools (e.g., Synopsys Design Compiler) can take boolean or boolean-oriented designs and crank out complete NCL designs. Although not completely optimized, that's where our optimizer comes in and finishes the job. But you CAN use existing tools to start making working NCL circuits now.
The only negatives to NCL are:
Dual-rail implementation requires extra chip real-estate -- This can translates into the die being upto 50% larger in the worst case. Fortunately, NCL still ends up requiring less power (even with the increase in transitors or wiring -- much less in fact, like 1/4th!) due to its asynchronous characteristics. This is the only area where alternative, single-rail asynchronous holds a slight advantage (again, NOT worth all the disadvantages).
"Orphans" -- Not really an "negative" argument overall as "orphan checking" and redesign due to them is miniscule compared to the wasteful redesign and design failures that are occurring today with clocked boolean logic in timing verification. Even comparing NCL against over asynchronous logic designs, it's no contest, orphans will not cause you to do major redesigns, because orphans are a localized issue, not a whole chip timing issue. We're talking more than one order of magnitude in time to post-design verify (assume the clocked version doesn't have to be chucked and fully redesigned;-).
Remember, I said that when computers were invented, besides the "operator" and "operand," you had to account for the "control", which was previously the mathematician him/herself with boolean logic on paper.
The first computers WERE async (e.g., Eniac, etc...). But by the speed of components in 60s, the race conditions were great enough that prompt a "formal" control line. This became the clock, which was simple and did the job. By the time ICs rolled around (early '70s with Intel's first memory package), the clock was the "thang" to use.
But starting with speeds of 100MHz+ and the number of transitors in the millions, clocks were limited by the speed of light (combined in the delays of the semiconductor material itself, silicon). As such, clocks are now localized to certain portions of the IC, but yet, have to be "synchronized" somehow.
Karl Fant, the man behind NCL, devised this embedding of control in logic at Honeywell over two decades. Theseus Logic was founded in 1996 to take NCL commercial (Honeywell had no interest in doing so). Our main argument is that WE FINALLY ADDRESSED "CONTROL" in the way computers should be designed. Remember, boolean logic and algebra was designed for mathematicians, NOT computers. And most of the industry is starting to side with us that dual-rail/acknowledgement is the way to go.
First off, I'm not an expert here (again, I don't get to get too deep because I second as the sysadmin -- a "pee-on as needed" engineer if you will;-). I hope to get deeper into NCL design as the sysadmin duties die down (they were quite heavy when I got here because they had been operating without a sysadmin for ~3 years as they grew).
Secondly, I assume you understand the purpose of the "acknoledgement", which is essentially the "hey, I'm with the previous result, I'm ready for the next set of inputs"? The acknoledgement along with the normal properties of CMOS prevent any "race condition" from occurring (I assume that is your fear?). Again, the physical design is pretty much "100% delay INsensitive". Again, I'm not exactly following you here, but remember, we're not using traditional NAND, etc... gates in CMOS, but NCL gates (e.g., 3 of 5) and they are designed specifically for NCL and the acknowledgement flow.
Third, the only problem 2NCL (the NCL math used in CMOS -- 4NCL is ideal, but NOT practical in physical design) has to do with is what we call "orphans." They are unforseen results that may either cause a condition where data can be "hung" from moving on, or (more likely), the input triggers a gate to open when it shouldn't (e.g., forgetting to take the acknoledgement into account). AFAIK (I've never messed with finding them myself) "orphans" are a "pure logic" problem and we can identify most of them through a post-design "orphan checker."
Again, I do *NOT* speak for Theseus Logic and there are much better individuals here who can clear up any questions. Feel free to fire off some questions to the address(es) on the web site.
I'd figure eCos would be ported before Linux. Amulet is not exactly something that you would use in a traditional thin-client/server system, but more, ultra-low-power/embedded systems.
eCos is the Linux complement in small-footprint, real-time space. Blows Windows CE out of the water, and Cygnus/RedHat are working hard to make EL/IX an API for cross-Linux/eCos development. An excellent model IMHO. Linux is great, but it can't run in the smallest of footprints.
In the article, he used an example of a "dual-rail" logic (as opposed to "single-rail" found in most boolean-designs) call Null Convention Logic (NCL) from Theseus Logic. Theseus' NCL approach not only goes a long way to not only solving the power and noise problems (like most asynchronous), but also the greater problem of design reuse (a problem with both async and, especially, synchronous) -- the later is something Furber was quoted on in a past EE Times article (cannot seem to find it on-line anymore?).
Timing verification is becoming increasingly difficult in IC design, adding rediculous ammounts of extra effort and, in some cases, complete design failures (e.g., AMD, IBM and Intel have all had timing-related design failures). Clocks may soon disappear in favor of async designs, especially those like Theseus Logic's nearly-100% delay INsensitive NCL technology. NCL's delay INsensitive nature comes from the fact that it is NOT boolean logic based, but a new method that breaks the traditional foundation of what boolean logic was design for, mathematicians, not computers.
In addition to an "operand" and an "operator," as with traditional, human-based math, computers require a third "control" line. In synch/boolean, this is the clock. With the limitations of the speed of light, it is IMPOSSIBLE for 10M+ transistor ICs on one section of the chip to be timed synchronous with another. As such, most modern ICs have localized clocks, which further adds to design complexity.
NCL removes the clock as the control (as with most async) *BUT* it places the control back in the data flow lines themselves! NCL is a 3-state logic of "true" and "false", plus the control which is derived from NCL math to be "null" (no data). This representation is 2NCL in NCL math (see Theseus' site for more details on NCL including 4NCL and 3NCL, the later being used with most off-the-shelf tools and optimizers). In 2NCL, the lines (again, "dual-rail") puts the false value (0) on one line and true (1) on the other line *IF* voltage is present, otherwise, no voltage (or low) results in the state of "null" (again, no data). Acknoledgements are used to maintain a delay INsensitive combinational logic circuit, including the fact that NCL can be place alonside synch/boolean and maintain 100% data flow and integrity (again, totally delay INsensitive). So instead of data having to "wait" on a clock to move forward, data moves forward when it arrives! This further increases performance!
Although Theseus' NCL technology is NOT boolean based, it works with off-the-shelf synch/boolean IC design tools (unlike attempts like Cogency's), it is still CMOS-based, and it not too difficult for an engineer to learn coming from the synch/boolean world.
[Bias: I am an employee of Theseus Logic and know Mr. Furber, the Amulet lead. I am NOT an engineering lead, just a regular engineer (who seconds as the sysadmin;-).]
I was hoping to find a resource that will point out the best Samba book for various users. There are so many books and users should be steered towards the best book for them. There never is a "single" best book for everyone -- e.g., Samba Unleashed isn't a newbie book, nor is any other book in the Unleashed series. I then injected my bias so everyone knows it, in the clear. My "how it stacks up" bit was, more or less, a joke -- although I haven't seen anything in any media outlet on Samba Unleashed (but I've never heard of a contributing author getting royalties, so don't think I'm going to benefit anyway;-).
Anyhoo, my additional point was that I was also looking for a good Apache book. Just like Samba, there are so many out now, I don't know which one would be best for me.
I'd kinda like to see a whole series of comments on the various books of any topic where more than 3 books exist. Samba and Apache are two of the biggies when it comes to OSS, with the most books on them right now.
First off, I assume your SMB question is on NT's SMB services (not Samba's)?
If so, I'm afraid this is where your limitation lies. NT makes all kinds of design and assumption decisions that "simplify" its capabilities. Even if 9x/NT is a client of a UNIX/Samba server, Samba itself cannot make up for the limitations of the client (especially in the cases of 9x). Case in point: I personally love how people complain that Samba doesn't give them a permissions dialog box in Win9x so they can modify ACLs on the Samba server when they don't get one when they connect to a native NT server either (because the client doesn't support it stupid!)!!!
And as you said, NFS seems to handle your problem perfectly. Again, blame Microsoft and their far-from-spec SMB implemenation, a protocol that was NEVER designed for its current role.
What a rude post! If you want it, why don't you write it?!?!?! Contribute and they shall come.
Otherwise, be content with the massive, painstaking development that Samba is. I'd like to see a better example of reverse engineering a quite closed protocol that is 180 degrees from its open documentation.
Although I like the Slashdot book reviews, with so many Samba books on the market (no less than 4 new ones this year alone!), a good survey of all the major books in one place would be nice. Same goes for Apache. Anyone got a good sample of the Samba (or Apache) collection(s)???
BIAS WARNING: I was a contributing author on Samba Unleashed and would like to see how we "stack up" against the "competition".;-> The review at Amazon stated the buyer chose it over the highly acclaimed O'Reilly book. 1200 pages strong.
[and to answer someone else's question, I actually think we did NOT include the GPL. Not only because we didn't include the software itself, but because I don't think Samba is actually GPL licensed (please correct me I am wrong). ]
Matrox has learned two valuable lessons for the years.
Never overhype your products or pre-release specs you cannot achieve.
Give developers the info they want, even with a NDA, and they'll be happy.
Regarding #1, Matrox has learned. I am surprise how everyone talks about 3Dfx and nVidia when the G400Max holds its own against all but the latest nVidia GeForce (but scales better on newer processors from what I've seen). And the 2D and 3D image quality is #1... I'm sorry, but true (just look at a G400 at 1920x1440 screen and you'll agree too)! And Matrox actually supports ALL of the 32-bit color goodies where nVidia's supposive 32-bit color "superiority" lacks functions that are only in their 16-bit color mode. And Matrox tries hard to get speculation out of the public, and consistently denies any forthcoming product rumors until the chips are sampling and can be seen for what they are.
Regarding #2, the Linux/OSS Matrox developments, from an flexible frame-buffer driver to a well-respected GLX/DRI effort with top-developers is just a testament to the community Matrox has created by finally opening up. While they still require a NDA for something, anything and everything is availble to developers. And I'd say developers would rather see it all and have no help, then have some help with a lot of restrictions.
The Unversity of Central Florida. We've been doing the ACM for about 15 years now. Regularly win our regionals or place in the top 3. We are also considered a top 25 school for Electrical and Computer Engineering according to the College Board (the SAT/GRE "guys").
And there we are, #15 this year (out of >>2,000 teams) -- right next to MIT, Carnegie Mellon and Virginia Tech. Plus, a brief history of UCF's world rankings...
1997: #16 (out of 1,100 teams)
1996: One of the 43 world contestants (out of >1,001 teams)
1995: #19 (out of >900 teams)
1994: One of the 35 world contestants (out of 628 teams)
1992: #7 (out of >600 teams)
1991: #16 (out of >500 teams)
And plenty of world rankings in the '80s (world rankings prior to 1991 not available on-line).
But people in Florida spit on us and, until recently, we used to get 1/10th of the funds of UF or FSU. We have more programs and students than Florida State (let alone 10x the graduate programs) and are barely behind Florida! Add in the fact that we have the 2nd largest research park in the US and it makes me wonder.
It wasn't until our Football team moved up to I-A (in 1996) and started playing big schools (and nearly beating them) that we finally got some money proportional to our size. Very sad that sports seems to drive everything.
Although I found the non-x86 FPU and flat FPU details interesting, there is a lot more to all this.
I think the site is unaware that GCC has been capable of 64-bit compilation for a long time and that 64-bit Linux is already here with the Alpha (several years mature, thanks to an industry who is using it). The basic IA-64 port and compiler is already completed (with optimizations slowly but surely being added). 64-bit Linux has a solid foothold in IA-64's release.
But does that count AMD out? No. I do not see it too difficult for AMD to _extend_ the 32-bit GCC compiler to support its 64-bit extensions. It won't be a full-up project like the IA-64 port and compiler which has radical differences. Remember, Sledgehammer is all about compatibility, and that is in AMD's favor. It will be easy to extend Linux to support some of the 64-bit functions of Sledgehammer, first starting with the kernel, then the apps later on (as 32-bit x86 dies).
But the true irony of all this is that it is in Microsoft's favor too! Almost a catch-22 if you dislike the Wintel duopoly. If IA-64 succeeds, Linux has that much more of a chance of wiping NT off the planet in the server and workstation relm. If Sledgehammer succeeds, Windows has a much better chance of going 64-bit with the little effort traditionally found in their Windows products.
It's going to be interesting to see how this all unfolds. But on thing is for sure, just like the Alpha, Linux will allow IA-64 to sell regardless of any Windows support.
This is pure marketing hype. CE has been a source-release, or at least modular with a good ammount of source since inception. Any small footprint OS comes with source.
Why?
Because you only compile in what you need. QNX, VxWorks, CE and others. This is nothing new at all, almost redundant. Microsoft is just trying to get some hype.
Again, nothing has changed.
-- Bryan "TheBS" Smith
Are their not legal issues to OpenSSH/SSL???
on
FreeBSD 4.0 Released
·
· Score: 1
AFAIK, you cannot use either in the US due to use of the DES algorithm that is under a patent until the end of this year. Is FreeBSD allowed to release it now because of their partnership/ownership with/by BSDi???
Also, I was under the impression the stock OpenSSH/SSL still included bit sizes greater than the new limits on encryption export set by the Clinton administration (56/512 or 64/512 are they?). I could be mistaken though (no expert here;-).
While Microsoft says this move is required to correctly certify people on the Windows platform of the future, I cannot stop to see how the attitude is so contradictory to the principles and foundations behind the certification process. I mean, here we have a number of people strongly against this change in Microsoft upgrade policy. Should that not tell us something?
Is not the certification process an means by peers to evalute, test and authenticate their peers on their knowledge in a particular study or area(s)?
I think that is the point that the whole certification process is missing. Whether you are talking about Novell, Microsoft or even RedHat. Too many other variables, whether it is money, advocacy for their own product, etc...
Non-profit organizations are only the true, unbiased source of certification.
Linux is NOT the problem. Specifically, he is complaining that since Linux certified people are so few and far between, they are hard to hold on to. Well, I didn't know Linux professionals were so valuable!;->
Well I'm sorry! Just because the Linux market isn't saturated with such "professionals" like Microsoft/Novell, you think that is the fault of Linux or RedHat?!?!?! Geez!
And thank the media and bigots because the all backlash that has been building up for all the unwanted hype is about to be unleashed on Linux. People are looking for people to blame, whether that is Microsoft, Novell or, now, RedHat. Quit finger pointing and get working!
Revolution doesn't come easy people! Look at the long term, not the short. So many narrow minded people. Sure enough, consulting firms who worry about certifications are the ones bitching the loudest.
Me? No certification. No fancy titles. Just years of NT, Novell and Linux experience and software development and some publications.
-- Bryan "TheBS" Smith
Like Democracy, choice yeilds two majorities ...
on
Gnome 1.1.4 Released
·
· Score: 2
And plenty of minorities. You always have choice. And then you have major standards behind two. E.g.,:
BSD and System-V
VI[M] and Emacs
RedHat and Debian (at least its looking that way, both are mega, pro-GPL and that is a good thing)
Gnome/GTK and KDE/Qt
They are the majority, with plenty of minorities. This may not be the best way, but the best way we know of.
Proprietary software is like socialism, with Microsoft the epitome as communism. One choice, and we punish you if you try to choose otherwise.
Me? I'm a Gnome wennie (then again, I'm a RedHat-baised wennie too;-).
My former employer, Coleman Research Corporation. Dig that huge GIF content pane! My good friend is the system administrator there, but the graphics department were the ones that came up with it.
I distinctly remember Microsoft announcing this a full year ago on a page at Microsoft.COM! And promised that a "beta" sign-up program would be forthcoming.
Sure enough, a couple of days later, the page was no longer available.
Microsoft will never release a Linux port. At least not anytime soon. If they did, half of American companies would jump ship. Office and their EEE (embrace-extend-extinguish) Internet "technologies" are the only things keeping half of all businesses from switching to Linux.
And I am speaking to you as an American of half a dozen generations, working as an engineer at a semiconductor design and technology firm. H-1B VISAs do nothing to so-call "protect" American jobs... in fact, they make it worse for us.
Why? Because H-1B VISAs allow companies to abuse foreigners for employment, make them work 20 years at the same job for half the pay under the threat of a VISA revoke. Thus, American workers suffer as they are either replaced, or have to accept less competitive salaries.
And even with the so-called "no loophole" new VISA laws, 50% of American companies still abuse them.
Now it is rarer at companies where it is hard to find talented people. I work at one of them, Theseus Logic, Linus does at another, Transmeta, Synopsys is probably in the same boat, etc... The people we are trying to find are hard to find, because of the level of education and narrow experience involved.
But there are plenty of companies that have more commodity talents and employment. In such cases, these companies abusing the whole system. There have been quite a number (in the tens of thousands) of Americans laid off at various companies. From Internet startups to IT consultant firms, these companies, who were never supposed to get their hands of H-1B VISA cannidates, are doing just that! Very said given that there are plenty of 35+ year olds with more experience, but are constantly age discriminated against (among other reasons and age groups).
If we would let skilled engineers freely into this country, "real" engineers (not IT professionals, that is different), they would demand the same pay as Americans. They would work the same time at a company (~3-4 years) before moving. They would, essentially, act just like Amercian engineers. But would improve our future outlook since they contribute to the overall greatness of the US (let alone they teach their kids to speak English, which seems to matter so some people;-).
With H-1B VISAs, half of Amercian companies, usually those not directly engineering or R&D related, abuse the system. They hold these immigrants to half the pay, and 20 years of employment. Very sad. Very sad indeed. And now VISA laws will ever protect them from it either.
Slashdot Mirror
Your instinct is correct. I believe the discussion you are looking for is supercomputing clusters (e.g., Beowolf, etc...) versus shared memory (e.g., SGI/Cray, Sun, etc...) systems. I have a similiar (albeit longer) post and question set above. Check it out if you like.
-- Bryan "TheBS" Smith
Most of the IS/IT trade publications and media usually do not fully comprehend the differences between massively multiprocessor systems with shared memory and those clusters of systems and processors with their own local memory, or supercomputing clusters. This is quite evident in a recent article regarding the TPC-D performance between clusterd Compaq Wintel/MSSQL systems and a single, shared memory Sun/Oracle system where the Compaq cluster outperformed the Sun solution in 2 of the 10 standard benchmarks. Basic laws of statistics negate those results because the design of the two systems were not of the same class -- e.g., to be fair, Microsoft-Compaq should have compared performance to an equivalent cluster of lower-costing Sun systems (let alone a Lintel cluster!).
As you and I already know (and I hope everyone reading this now knows), there are several applications where lower costing clusters cannot always do the job of more costly shared memory systems as efficiently (e.g., low-latency, real-time applications such as real-time simluations, come to mind). That is why the Compaq Wintel cluster scored drastically far below the shared Sun system in many of the other 8 benchmarks in the aforementioned study.
As such, I am interested in the considerations the NOAA has had to make in evaluating shared memory versus clustered systems. Specifically:
- What are some of the NOAA/NWS programs and software that will not be applicable for execution on this new cluster?
- What [estimated] percentage do these programs make up of the total applications the NOAA uses, both quantity and in time of execution?
- What [assuming] shared memory systems and solutions does the NOAA use for these applications?
Of course, the lower the number in the first two questions, the more advantageous the existence of a supercomputing cluster is to an organization. For example, in the aerospace industry, the quantity of cluster-efficient applications may be small, but the total execution time of a "run" of these select applications can greatly outweigh all others. Again, speaking from my aerospace background, such applications like Monte Carlo, CFD, 6DOF (six degrees of freedom) runs and simulations are extremely time consuming. Monte Carlo is an ideal application for clustering since each "run" result is complete independent from another (almost linear performance improvement when distributed in a cluster). CFD is very close to linear (~90% efficient) and 6DOF, I would guess, could be as high as 60 or 70%, if it is written to take advantage of distributed computing systems.The main reason why these engineering applications are so efficient on clusters is the nature of how they use data. They need little to start crunching, and return little. But during the run, they create and use massive ammount of data, which is all "temporary." This is in stark constrast to databases (such as those targetted by the aforementioned TPC-D benchmarks), where data, not computational results, is the focus of the application. By using supercomputing clusters for computational-driven engineering apps, we can save both money on systems and the time of our engineers waiting on results.
As such, I am interested in the overall increase in efficiency you are seeing after the introduction of supercomputing clusters. Specifically:
[ I now work in the semiconductory design industry, and we are looking at acquiring some Linux supercomputing clusters speed up the runs of EDA (electronic design automation) tools like those for IC layout and the like. ]
I appreciate your time and wish your organization and yourself the best wishing in our Linux and OSS endeavors.
-- Bryan "TheBS" Smith
Okay. Am I the only one who thinks this is nuts or what?
Now I understand there are laws that are for expediting procedures to protect humans and freedoms. But to enact a law, or extend them, to not only protect, but expedite the prosecution of those who may or may not have violated someone's PROPERY rights, such as profit, IP, etc... at the expense of due process and other, individual freedoms ... THIS IS NUTS!
-- Bryan "TheBS" Smith
... don't agree with. This is VERY TYPICAL of the US media and journalists out there. You ignore the 95% "good" and pick on the 5% "bad". Again, I see this time and time again.
If anything, the FSF/GNU foundation could be considered a little "radical". But every movement has it's "radical" from the norm, AND THAT IS A VERY GOOD THING! Because 95% of their ideas are "on-the-mark", which is better than most other organizations.
I would argue this is the EXACT SAME THING THE MAINSTREAM MEDIA DOES with regard to the ACLU and NRA. Both are "radical" organizations, picked "apart" by the US media for that 5% that doesn't make sense. But it's that 95% we don't see in the US media that protects our 1st and 2nd Amendments, the #1 and #2 laws of the land that most states required before they would sign the US Constitution.
Take any group, narrow your argument to pick on those "radical" sections that most people don't agree with and you can make just about any case against them. Well done Mr. Meyer, you are no different than the one-dimensional, single-sided, mainstream media that keeps my TV off when the news is on.
-- Bryan "TheBS" Smith
First off, you are comparing two entirely different markets. ARM is NOT designed to run in an end-user, general-purpose desktop.
Secondly, StrongARM did go the same as Alpha ... to Intel in the cross-license and fab buy-out! Every thing about the main, single reason Intel made the deal points sole at ... yes, StrongARM (of course, the nice side-effect was the dropping of the lawsuit -- and Digital wanted to dump its fabs anyway). The damn thing was eating everything up, MIPS, Hitachi, etc... and Intel's own i960 really needed a good replacement.
The smartest thing Intel has done in a long time (at least technically ;-) was to buy StrongArm from Digital. Man is StrongArm just gaining market and mindshare or what?!?!?!
But ARM itself (non-StrongARM) is far from dead. It's used in numerous products you use, just like MIPS.
-- Bryan "TheBS" Smith
Here's a quick summary of the benefits of NCL:
[ One really "neat" feature of NCL is the inverter gate, THERE IS NONE! Invert in NCL is simply done by swapping the rails! ]
The only negatives to NCL are:
-- Bryan "TheBS" Smith
Remember, I said that when computers were invented, besides the "operator" and "operand," you had to account for the "control", which was previously the mathematician him/herself with boolean logic on paper.
The first computers WERE async (e.g., Eniac, etc...). But by the speed of components in 60s, the race conditions were great enough that prompt a "formal" control line. This became the clock, which was simple and did the job. By the time ICs rolled around (early '70s with Intel's first memory package), the clock was the "thang" to use.
But starting with speeds of 100MHz+ and the number of transitors in the millions, clocks were limited by the speed of light (combined in the delays of the semiconductor material itself, silicon). As such, clocks are now localized to certain portions of the IC, but yet, have to be "synchronized" somehow.
Karl Fant, the man behind NCL, devised this embedding of control in logic at Honeywell over two decades. Theseus Logic was founded in 1996 to take NCL commercial (Honeywell had no interest in doing so). Our main argument is that WE FINALLY ADDRESSED "CONTROL" in the way computers should be designed. Remember, boolean logic and algebra was designed for mathematicians, NOT computers. And most of the industry is starting to side with us that dual-rail/acknowledgement is the way to go.
-- Bryan "TheBS" Smith
First off, I'm not an expert here (again, I don't get to get too deep because I second as the sysadmin -- a "pee-on as needed" engineer if you will ;-). I hope to get deeper into NCL design as the sysadmin duties die down (they were quite heavy when I got here because they had been operating without a sysadmin for ~3 years as they grew).
Secondly, I assume you understand the purpose of the "acknoledgement", which is essentially the "hey, I'm with the previous result, I'm ready for the next set of inputs"? The acknoledgement along with the normal properties of CMOS prevent any "race condition" from occurring (I assume that is your fear?). Again, the physical design is pretty much "100% delay INsensitive". Again, I'm not exactly following you here, but remember, we're not using traditional NAND, etc... gates in CMOS, but NCL gates (e.g., 3 of 5) and they are designed specifically for NCL and the acknowledgement flow.
Third, the only problem 2NCL (the NCL math used in CMOS -- 4NCL is ideal, but NOT practical in physical design) has to do with is what we call "orphans." They are unforseen results that may either cause a condition where data can be "hung" from moving on, or (more likely), the input triggers a gate to open when it shouldn't (e.g., forgetting to take the acknoledgement into account). AFAIK (I've never messed with finding them myself) "orphans" are a "pure logic" problem and we can identify most of them through a post-design "orphan checker."
Again, I do *NOT* speak for Theseus Logic and there are much better individuals here who can clear up any questions. Feel free to fire off some questions to the address(es) on the web site.
-- Bryan "TheBS" Smith
I'd figure eCos would be ported before Linux. Amulet is not exactly something that you would use in a traditional thin-client/server system, but more, ultra-low-power/embedded systems.
eCos is the Linux complement in small-footprint, real-time space. Blows Windows CE out of the water, and Cygnus/RedHat are working hard to make EL/IX an API for cross-Linux/eCos development. An excellent model IMHO. Linux is great, but it can't run in the smallest of footprints.
-- Bryan "TheBS" Smith
Amulet's lead, Steve Furber (who also designed the original ARM), wrote a recent editorial coverstory called "Kicking out the Clock" in the May 2000 edition of Integrated System Design (ISD) magazine.
In the article, he used an example of a "dual-rail" logic (as opposed to "single-rail" found in most boolean-designs) call Null Convention Logic (NCL) from Theseus Logic. Theseus' NCL approach not only goes a long way to not only solving the power and noise problems (like most asynchronous), but also the greater problem of design reuse (a problem with both async and, especially, synchronous) -- the later is something Furber was quoted on in a past EE Times article (cannot seem to find it on-line anymore?).
Timing verification is becoming increasingly difficult in IC design, adding rediculous ammounts of extra effort and, in some cases, complete design failures (e.g., AMD, IBM and Intel have all had timing-related design failures). Clocks may soon disappear in favor of async designs, especially those like Theseus Logic's nearly-100% delay INsensitive NCL technology. NCL's delay INsensitive nature comes from the fact that it is NOT boolean logic based, but a new method that breaks the traditional foundation of what boolean logic was design for, mathematicians, not computers.
In addition to an "operand" and an "operator," as with traditional, human-based math, computers require a third "control" line. In synch/boolean, this is the clock. With the limitations of the speed of light, it is IMPOSSIBLE for 10M+ transistor ICs on one section of the chip to be timed synchronous with another. As such, most modern ICs have localized clocks, which further adds to design complexity.
NCL removes the clock as the control (as with most async) *BUT* it places the control back in the data flow lines themselves! NCL is a 3-state logic of "true" and "false", plus the control which is derived from NCL math to be "null" (no data). This representation is 2NCL in NCL math (see Theseus' site for more details on NCL including 4NCL and 3NCL, the later being used with most off-the-shelf tools and optimizers). In 2NCL, the lines (again, "dual-rail") puts the false value (0) on one line and true (1) on the other line *IF* voltage is present, otherwise, no voltage (or low) results in the state of "null" (again, no data). Acknoledgements are used to maintain a delay INsensitive combinational logic circuit, including the fact that NCL can be place alonside synch/boolean and maintain 100% data flow and integrity (again, totally delay INsensitive). So instead of data having to "wait" on a clock to move forward, data moves forward when it arrives! This further increases performance!
Although Theseus' NCL technology is NOT boolean based, it works with off-the-shelf synch/boolean IC design tools (unlike attempts like Cogency's), it is still CMOS-based, and it not too difficult for an engineer to learn coming from the synch/boolean world.
[Bias: I am an employee of Theseus Logic and know Mr. Furber, the Amulet lead. I am NOT an engineering lead, just a regular engineer (who seconds as the sysadmin ;-).]
-- Bryan "TheBS" Smith
I think you missed my point.
I was hoping to find a resource that will point out the best Samba book for various users. There are so many books and users should be steered towards the best book for them. There never is a "single" best book for everyone -- e.g., Samba Unleashed isn't a newbie book, nor is any other book in the Unleashed series. I then injected my bias so everyone knows it, in the clear. My "how it stacks up" bit was, more or less, a joke -- although I haven't seen anything in any media outlet on Samba Unleashed (but I've never heard of a contributing author getting royalties, so don't think I'm going to benefit anyway ;-).
Anyhoo, my additional point was that I was also looking for a good Apache book. Just like Samba, there are so many out now, I don't know which one would be best for me.
I'd kinda like to see a whole series of comments on the various books of any topic where more than 3 books exist. Samba and Apache are two of the biggies when it comes to OSS, with the most books on them right now.
-- Bryan "TheBS" Smith
I'm a bit confused here.
First off, I assume your SMB question is on NT's SMB services (not Samba's)?
If so, I'm afraid this is where your limitation lies. NT makes all kinds of design and assumption decisions that "simplify" its capabilities. Even if 9x/NT is a client of a UNIX/Samba server, Samba itself cannot make up for the limitations of the client (especially in the cases of 9x). Case in point: I personally love how people complain that Samba doesn't give them a permissions dialog box in Win9x so they can modify ACLs on the Samba server when they don't get one when they connect to a native NT server either (because the client doesn't support it stupid!)!!!
And as you said, NFS seems to handle your problem perfectly. Again, blame Microsoft and their far-from-spec SMB implemenation, a protocol that was NEVER designed for its current role.
-- Bryan "TheBS" Smith
What a rude post! If you want it, why don't you write it?!?!?! Contribute and they shall come.
Otherwise, be content with the massive, painstaking development that Samba is. I'd like to see a better example of reverse engineering a quite closed protocol that is 180 degrees from its open documentation.
Yell at Microsoft, not the Samba team.
-- Bryan "TheBS" Smith
Although I like the Slashdot book reviews, with so many Samba books on the market (no less than 4 new ones this year alone!), a good survey of all the major books in one place would be nice. Same goes for Apache. Anyone got a good sample of the Samba (or Apache) collection(s)???
BIAS WARNING: I was a contributing author on Samba Unleashed and would like to see how we "stack up" against the "competition". ;-> The review at Amazon stated the buyer chose it over the highly acclaimed O'Reilly book. 1200 pages strong.
[and to answer someone else's question, I actually think we did NOT include the GPL. Not only because we didn't include the software itself, but because I don't think Samba is actually GPL licensed (please correct me I am wrong). ]
-- Bryan "TheBS" Smith
Matrox has learned two valuable lessons for the years.
Regarding #1, Matrox has learned. I am surprise how everyone talks about 3Dfx and nVidia when the G400Max holds its own against all but the latest nVidia GeForce (but scales better on newer processors from what I've seen). And the 2D and 3D image quality is #1 ... I'm sorry, but true (just look at a G400 at 1920x1440 screen and you'll agree too)! And Matrox actually supports ALL of the 32-bit color goodies where nVidia's supposive 32-bit color "superiority" lacks functions that are only in their 16-bit color mode. And Matrox tries hard to get speculation out of the public, and consistently denies any forthcoming product rumors until the chips are sampling and can be seen for what they are.
Regarding #2, the Linux/OSS Matrox developments, from an flexible frame-buffer driver to a well-respected GLX/DRI effort with top-developers is just a testament to the community Matrox has created by finally opening up. While they still require a NDA for something, anything and everything is availble to developers. And I'd say developers would rather see it all and have no help, then have some help with a lot of restrictions.
Just my $0.02 ...
-- Bryan "TheBS" Smith
The Unversity of Central Florida. We've been doing the ACM for about 15 years now. Regularly win our regionals or place in the top 3. We are also considered a top 25 school for Electrical and Computer Engineering according to the College Board (the SAT/GRE "guys").
And there we are, #15 this year (out of >>2,000 teams) -- right next to MIT, Carnegie Mellon and Virginia Tech. Plus, a brief history of UCF's world rankings ...
But people in Florida spit on us and, until recently, we used to get 1/10th of the funds of UF or FSU. We have more programs and students than Florida State (let alone 10x the graduate programs) and are barely behind Florida! Add in the fact that we have the 2nd largest research park in the US and it makes me wonder.
It wasn't until our Football team moved up to I-A (in 1996) and started playing big schools (and nearly beating them) that we finally got some money proportional to our size. Very sad that sports seems to drive everything.
Again, no respect!
-- Bryan "TheBS" Smith
Although I found the non-x86 FPU and flat FPU details interesting, there is a lot more to all this.
I think the site is unaware that GCC has been capable of 64-bit compilation for a long time and that 64-bit Linux is already here with the Alpha (several years mature, thanks to an industry who is using it). The basic IA-64 port and compiler is already completed (with optimizations slowly but surely being added). 64-bit Linux has a solid foothold in IA-64's release.
But does that count AMD out? No. I do not see it too difficult for AMD to _extend_ the 32-bit GCC compiler to support its 64-bit extensions. It won't be a full-up project like the IA-64 port and compiler which has radical differences. Remember, Sledgehammer is all about compatibility, and that is in AMD's favor. It will be easy to extend Linux to support some of the 64-bit functions of Sledgehammer, first starting with the kernel, then the apps later on (as 32-bit x86 dies).
But the true irony of all this is that it is in Microsoft's favor too! Almost a catch-22 if you dislike the Wintel duopoly. If IA-64 succeeds, Linux has that much more of a chance of wiping NT off the planet in the server and workstation relm. If Sledgehammer succeeds, Windows has a much better chance of going 64-bit with the little effort traditionally found in their Windows products.
It's going to be interesting to see how this all unfolds. But on thing is for sure, just like the Alpha, Linux will allow IA-64 to sell regardless of any Windows support.
-- Bryan "TheBS" Smith
This is pure marketing hype. CE has been a source-release, or at least modular with a good ammount of source since inception. Any small footprint OS comes with source.
Why?
Because you only compile in what you need. QNX, VxWorks, CE and others. This is nothing new at all, almost redundant. Microsoft is just trying to get some hype.
Again, nothing has changed.
-- Bryan "TheBS" Smith
AFAIK, you cannot use either in the US due to use of the DES algorithm that is under a patent until the end of this year. Is FreeBSD allowed to release it now because of their partnership/ownership with/by BSDi???
Also, I was under the impression the stock OpenSSH/SSL still included bit sizes greater than the new limits on encryption export set by the Clinton administration (56/512 or 64/512 are they?). I could be mistaken though (no expert here ;-).
Any clarity would be greatly appreciated.
-- Bryan "TheBS" Smith
While Microsoft says this move is required to correctly certify people on the Windows platform of the future, I cannot stop to see how the attitude is so contradictory to the principles and foundations behind the certification process. I mean, here we have a number of people strongly against this change in Microsoft upgrade policy. Should that not tell us something?
Is not the certification process an means by peers to evalute, test and authenticate their peers on their knowledge in a particular study or area(s)?
I think that is the point that the whole certification process is missing. Whether you are talking about Novell, Microsoft or even RedHat. Too many other variables, whether it is money, advocacy for their own product, etc...
Non-profit organizations are only the true, unbiased source of certification.
Just $0.02 ...
-- Bryan "TheBS" Smith
Linux is NOT the problem. Specifically, he is complaining that since Linux certified people are so few and far between, they are hard to hold on to. Well, I didn't know Linux professionals were so valuable! ;->
Well I'm sorry! Just because the Linux market isn't saturated with such "professionals" like Microsoft/Novell, you think that is the fault of Linux or RedHat?!?!?! Geez!
And thank the media and bigots because the all backlash that has been building up for all the unwanted hype is about to be unleashed on Linux. People are looking for people to blame, whether that is Microsoft, Novell or, now, RedHat. Quit finger pointing and get working!
Revolution doesn't come easy people! Look at the long term, not the short. So many narrow minded people. Sure enough, consulting firms who worry about certifications are the ones bitching the loudest.
Me? No certification. No fancy titles. Just years of NT, Novell and Linux experience and software development and some publications.
-- Bryan "TheBS" Smith
And plenty of minorities. You always have choice. And then you have major standards behind two. E.g.,:
They are the majority, with plenty of minorities. This may not be the best way, but the best way we know of.
Proprietary software is like socialism, with Microsoft the epitome as communism. One choice, and we punish you if you try to choose otherwise.
Me? I'm a Gnome wennie (then again, I'm a RedHat-baised wennie too ;-).
-- Bryan "TheBS" Smith
My former employer, Coleman Research Corporation. Dig that huge GIF content pane! My good friend is the system administrator there, but the graphics department were the ones that came up with it.
-- Bryan "TheBS" Smith
I distinctly remember Microsoft announcing this a full year ago on a page at Microsoft.COM! And promised that a "beta" sign-up program would be forthcoming.
Sure enough, a couple of days later, the page was no longer available.
Microsoft will never release a Linux port. At least not anytime soon. If they did, half of American companies would jump ship. Office and their EEE (embrace-extend-extinguish) Internet "technologies" are the only things keeping half of all businesses from switching to Linux.
-- Bryan "TheBS" Smith
And I am speaking to you as an American of half a dozen generations, working as an engineer at a semiconductor design and technology firm. H-1B VISAs do nothing to so-call "protect" American jobs ... in fact, they make it worse for us.
Why? Because H-1B VISAs allow companies to abuse foreigners for employment, make them work 20 years at the same job for half the pay under the threat of a VISA revoke. Thus, American workers suffer as they are either replaced, or have to accept less competitive salaries.
And even with the so-called "no loophole" new VISA laws, 50% of American companies still abuse them.
Now it is rarer at companies where it is hard to find talented people. I work at one of them, Theseus Logic, Linus does at another, Transmeta, Synopsys is probably in the same boat, etc... The people we are trying to find are hard to find, because of the level of education and narrow experience involved.
But there are plenty of companies that have more commodity talents and employment. In such cases, these companies abusing the whole system. There have been quite a number (in the tens of thousands) of Americans laid off at various companies. From Internet startups to IT consultant firms, these companies, who were never supposed to get their hands of H-1B VISA cannidates, are doing just that! Very said given that there are plenty of 35+ year olds with more experience, but are constantly age discriminated against (among other reasons and age groups).
If we would let skilled engineers freely into this country, "real" engineers (not IT professionals, that is different), they would demand the same pay as Americans. They would work the same time at a company (~3-4 years) before moving. They would, essentially, act just like Amercian engineers. But would improve our future outlook since they contribute to the overall greatness of the US (let alone they teach their kids to speak English, which seems to matter so some people ;-).
With H-1B VISAs, half of Amercian companies, usually those not directly engineering or R&D related, abuse the system. They hold these immigrants to half the pay, and 20 years of employment. Very sad. Very sad indeed. And now VISA laws will ever protect them from it either.
My $0.02 ...
-- Bryan "TheBS" Smith