Slashdot Mirror

An interesting quote is this:

• While it's debatable whether buying a preconfigured compute farm is cheaper than stringing together a few PCs and running Linux, Tallman said the latter scenario "would work well in university and government research centers where there is a lot of free labor, but not in a company that needs to get products out the door and can't spend time developing core competencies in compute farms."

From the EE Times article:

"The key technology enabling such improvement involves switching from the sine waves used for the discrete cosine transform (DCT) of JPEG to wavelets. "

So yes it will.

Nate Custer

Batteries, we don't need no stinkin' batteries.

Just check out these fremen type, power your mobile phone not vapor-ware "Maxwell Smart would be proud" shoes.

Sigh if only that whole Y2K scare hadn't already been over. . .

I suspect the real competition is with Sony's Cr eativeStation which appears (according to the limited information released so far .. any updates?) to be both MIPS based (a variant of their Sony PlayStation) as well as Linux development. If someone ever tweaks key libraries to use the vector-based co-processors, things will really rip.

Sigh, why don't they sell the chassis, then let us buy the CPU's separately so we can upgrade at our leisure.

LL

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

This appears to be the original, geekier version of the story before TechWeb's editors got to it. I'm not sure I like the idea of inserting personalized advertising objects into video streams.

We already have 200 channels with MPEG-2; how many do they want to give us with MPEG-4?

Actually, I see more to this than the article mentions. I think Intel released the Celeron IIs to keep AMD on its toes until Intel can come out with its Willamette and the upcoming low-end Timna processor due at the end of the year.

When doing thermal analysis, it's useful to make an analogy to electrical circuits. You convert heat flow into current, temperature into voltage, and thermal resistance into electrical resistance.

That said, a normal Peltier module can generate about a 50 degree C drop with no thermal load (this is equivelent to the open circuit voltage of a battery), and move about 5 watts of heat with no heat difference (just like shorting a battery out and measuring the current).

However, I read in EE Times (I think it was) about a new breakthrough in Peltier technology: by doping the module with a little Cesium, they got the open circuit temperature drop to 200 degrees C. Still won't move any more heat, but it'll move it over a larger temperature difference.

Now, I wonder what will happen when those babies become available....

On the Real-Time Linux mailing list, this entire load of piffle was discussed in February, when EETimes ran an article. I'm sure you can find archives somewhere around http://www.rtlinux.org/.

Poor Mr. Wilshire was misquoted in the original article, and if you search for his emails in the archives, you will see the thread. Well, since I can't be bothered finding the URL, I'll post his message to the list verbatim.

I have not asked permission to post this, so I hope that Mr. Wilshire will accept my apologies.

Date: Tue, 15 Feb 2000 11:05:25 -0800
From: Phil Wilshire
To: Nicholas Mc Guire , "rtl@rtlinux.cs.nmt.edu"
Subject: [rtl] Re: article on the Workshop

Nicholas Mc Guire wrote:
>
> Hi All !
>
>http://www.eetimes.com/story/OEG19991220S0029
>
> VIENNA, Austria - Developers of embedded-Linux systems
> ...
> also decided to back Cygnus Solutions' EL/IX as a common applications
> programming interface (API) for embedded Linux.
>
> Nearly 100 developers and programmers attended the grass-roots Real
> Time Linux Workshop here last week, and all but one voted to proceed
> with the use of EL/IX as their API.
>
> ...the other non-sense sniped...
>
> I conclude that there where two workshops in vienna
> on that peter and me organized and obviously a second one
> that we did not know of...
> It is simply stupid to belive that puting fals information
> out on the net will help push EL/IX as a standard API .
> I guess a view people out there did not understand the
> ideas of open source and even less the intent and spirit of the
> realtime linux workshop in Vienna.
>
> since the article claims to be based on information from
> phil whilshire maby he could comment on it .
>
> D'ehre
> Der Herr Hofrat

Willingly I will comment. There was some consderable misunderstanding in the way this article was presented.
I was NOT allowed to see the results of a brief telephone interview and much that was printed was a shock to me.
I do think that the statements about adopting EL/IX unchanged were inferred from another source.
My statement was that we would work together with CYGNUS to help develop EL/IX into something we all could use.

This is a warning to all of us not to accept telephone interviews and publication without prior approval of the result.

I have been waiting for this backlash in the community and hope that my true motives in all this are clear. If one of us make a mistake we are, in general, merciless.


I want Linux to succeed and I want Real Time Linux to succeed.
i have devoted many man hours in my own time to helping the community in many ways.
I want the Real Time Community to grow stronger and develop the way forward for this technology rather than leave it in the hands of commercial entities.
This includes Cygnus.
If they push EL/IX as the "Open Source" API and it bears no relationship at all to what is really needed then we all loose. We need to work together with everyone, Cygnus included, and produce what we need as an API. We also cannot present to the waiting users out there a confusing variety of API's. The Real Time Linux community is a very strong force we have what it takes to make this happen.

I apologise to the community for any misrepresentation . Those that know me will confirm that I am VERY careful in making any such statements. I will continue to be even more careful in the future.

I hope that we can resolve this with a simple public flogging.

regards
Phil Wilshire
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail majordomo@rtlinux.cs.nmt.edu OR
echo "unsubscribe rtl " | mail majordomo@rtlinux.cs.nmt.edu
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/

There is a much better article here from September, 11 1997. Does the 1999 article say anything new about this chip?
(There's also a blurb on the media demonstration here from the Nov. 17, 1997 Japan Times.)

-ac

• 1997 EE Times: price $960/chip.
• 1997 Japan Times

You can find more information about the chip at http://www.eetimes.com/news/97/9 71news/vision.html. This tells a little more of how the chip actually works. provolt "I joined the giant collective brain and all I got was this lousy post.

I misread the techweb article. If anyone is intersted there is another (slightly more technical) article here

Read the list again: Epson Stylus Color 900G FireWire printer, Epson Expression 1600 and Umax PowerLook 1100 FireWire scanners. There are also FireWire CD-R/RW drives, an ORB drive, analog-to-digital video converters, synthesizers, mixers, VCRs, HDTVs, network storage, DAT, DVD-RAM, DVD changer, video editors, camcorders, and data analyzers. RePlayTV even uses FireWire.

Philips recently demoed a wireless FireWire network, fast enough for real-time audio- and video-streaming at 46-Mbit/sec at distances far exceeding 10 meters (BlueTooth maxes at 1-Mbit/s, HomeRF at 1.6 Mbit/s, and IEEE 802.11 at 11-Mbit/s). Check out Wi-LAN, the self-proclaimed future of high-speed wireless, for more info.

Here's another list of FireWire products.

No, FireWire is not for regular modems. But USB does not work for Cable and DSL modems, either. FireWire could substitute for the Ethernet port in broadband application. USB cannot.

Seagate's spin relies on latency (2 ms) and seek time (1.9 ms) and as usual, they don't tell us how they come up with those figures. Even if those figures are correct, that still doesn't explain how Seagate's new 15-K rpm drives would be better. Imagine now, you have a server, it's transaction-busy, and you need to have lots and lots of io.

The originally referred article at EE Times quotes some IOMeter numbers. They don't specify which profile they were running, but I assume it was the default profile, which is essentially a TPC-like workload (2k blocks, 67% read, 100% random). The only flaw with this profile is that the queue depth is only 1, whereas in a real server it's going to be > 50.

Why does this matter? Drives have a pretty sophisticated cache system. Paired with this is a command reordering algorithm which lets the drive choose which command it will execute next, based on predicted performance. For example, if the drive sees that commands 2 and 4 are sequential, it will do them before command 3.

Would you rely on ONE 15-K rpm hd, or would you rather have 2 or more slower-spinning drives, maybe several, connected to raid-5 array, so to spread out the io load?

RAID-5 is about the worst thing you can do to your storage array performance. RAID-5 pushes THREE TIMES the number of IOs to your drives, plus adds a lot of overhead while your RAID card calculates parity. Really want the best IO performance you can get? Buy as many drives as you can and run them at RAID-0 (or RAID-1 if you want redundancy). If you have WAY too much money, buy the biggest drives available and only plan to use 1/2 of it; drives use the outer cylinders first so the data will only be a head-switch away instead of a seek.

And since we're talking about performance, Ultra160 doesn't buy you anything. It's all hype. Ultra320 may have some benefit, due to some changes in the arbitration sequencing.

A drive that spins 15-K rpm spins twice as fast as a drive that spins at 7400 rpm, that means, a 15-K rpm drives will NEVER last as long as the other one which spins half as fast. and Furrthermore, the recent MTBF from all HD manufacturers are almost always bogus anyway. How I long for the old time where MTBF means just that, Mean Time Between Failures.

What data do you use to support that claim? Because it's just not true. Drive reliability is approaching 1,000,000 hours MTBF. This is independent of spindle speed. Most drives fail because of handling damage. Even though drives will be able to withstand 200G non-op shock before too long, that is still less than the G-load when you drop a drive 1/2" on to a hard surface. It may not fail right away, but the particles you make when the head slaps the platter will eventually accumulate on a head and kill the drive.

MTBF still means Mean Time Before Failure. But this assumes that the drive is treated properly. I work for a box manufacturer, and we make our vendors complete a demonstrated million hour test. That's almost 115 years of continuous runtime (or 1000 drives for 1000 hours, Weibull). Want to know why all of your drives always fail earlier? Look no further than how you treat them.

They don't have to use Hydrogen - see my earlier posts about one using Methanol or go here.



The Tick - "Spoon!"

Actualy the Motorola cell design seems like more of an option.
Here's an article in EE Times about it.

That is if they can get more voltage out of it.


The Tick - "Spoon!"

• news.com
• spaceviews
• EETimes
• FiringSquad
• Ace's Hardware
• The Register

And if that post is worth Score:2 what is this post worth? Anyway, if this WAS a big story like the TPC stuff someone mentioned above that would be a newsworthy item (or a 2.4preXX release for that matter), but this isn't! This is another X-Box hype like trash! Why don't you post stuff about the Glaze3D Hemos if you really want vapourware and not-yet-maybe-never-out trash?

A few more links: The Freedom CPU and Free-IP: ASIC and FPGA cores for the masses. There is also an EETimes article (by the Free-IP site owner) about the benefits of open-source hardware IP.

Yumpee

We've covered it before in here, but the article here gives a hint at their workstations based on the emotion engine.

As far as current PS2 replacing PC, I don't think it could happen considering that the PS2 is so limited in CPU direction. From what I hear, if you tried to run a program like Excel (shiver), it would run slower than if you tried to run it on a 486.

If you think about it, the price of the EE makes it nice and easy to plop into a slot and take advantage of those new GPU API's DirectX uses. I seriously doubt Sony would ever put a PSX emulator on a card and sell it to the general public, but having an add-on won't threaten the PSX at all. But, the huge bus of the EE and reliance on Rambus would probably hinder a few things.

An article on this subject at EE Times mentions Slashdot and the debate over this hearing. The article also has some good links to the DVD CCA's arguments. You can read the article here
--
Gregory J. Barlow
fight bloat. use blackbox.

An article on this subject at EE Times mentions Slashdot and the debate over this hearing. The article also has some good links to the DVD CCA's arguments. You can read the article here
--
Gregory J. Barlow
fight bloat. use blackbox.

Changed to 25 cents after mucho bitching...article here ---> eetimes

Ask the Headhunter has quite a few interesting columns on discolsing salary information. The gist: don't lie but don't tell. Companies do have ways of confirming what they tell you.

My personal favorite is "my NDA prevents me from disclosing that" (the the bottom of the link). :)

Interesting... according to
another recent article, a lot of brain functions which were thought to run in parallel run serially; parallelism is simulated much like in a multitasking single-CPU computer: by swapping tasks rapidly.

I believe someone else found a brain area responsible for task switching; a sort of neurological scheduler. This is apparently damaged or underutilised in people with ADHD or a tendency to hyperfocus.

http://www.eetimes.com/story/OEG19990 827S0032

Basically, it looks like several companies banded together to produce 1394 transmissions at 2.4 gigahertz. Let's see USB 2.0 do that.

Firewire isn't going anywhere, this is more lame "news" from an increasingly biased source (Infoworld).

How about this for future LCD screens?

...allowing NEC to achieve 211-pixel-per-inch resolution in a 9.4-inch-diagonal LCD panel with 1,600 x 1,200-pixel UGA resolution.

...and 266-ppi panels should be out by the end of the year.

When it comes to transmitters, there are some who are already ahead.

Sweden's Ericsson together with IBM, Intel, Nokia and Toshiba have created an open standard technology for wireless communication called Bluetooth. The Bluetooth tranciever technology will be very cheap and low in power and is said to work even on planes. Bluetooth will have a range of up to 10 metres, 360-degree connectivity, point-to-point and point-to-multipoint connections, a gross data rate of 1 mbps, supporting Symmetrical and Asymmetrical Data rates up to 721 kbps, and support of both voice and data channels for simultaneous operation. The best thing is that it uses the open band of radio frequency which is available all over the world!

You might not have heard much about yet in America since it seems futile to get American media (including Slashdot...*mumble mumble*) to report on it, but interest in the system is rocketing and it is very hot in Europe. Over 750 companies have joined the Special Interest Group so far.
Already developed is a headset for your cell phone which lets you speak even if the phone is in your bag. (You will defenitely be taken for a loon when you go around on the streets talking to yourself with this one), a harddrive that automatically connect to thin clients anywhere(thereby working as PDAs) and many other things. Other early products is expected to be stereo speakers that you can place anywhere in the room (you still need a power cord of course), digital cameras from Casio, ID numbers to track stolen cars, cheap wireless LANs from 3Com, smart card readers, washing machines that call the repairman when broken, mobile phones that can double as remotes for your TV or to unlock your car, and other products. For computer users an early benefit is that we might finally get rid of the cable "spaghetti" behind the computer and the stereo. It is also said that the Calcaria Linux7K project (or Linux CL-PS7110) is interested in Bluetooth, something that makes Microsoft a bit worried since it seriously threatens Microsoft CE. The name Bluetooth comes from a Viking king who ruled Denmark and southern Sweden.

Read more at The official Bluetooth homepage and the ZDnet UK Bluetooth Special Report.

The EE Times article is here.

First, before everyone jumps in and says "Intel will never get there because the compiler will never get there," please don't forget that some shipping devices are already there.

Quite simply, EPIC allows a compiler to tell the hardware ahead of time where it knows parallelism exists, so that the silicon (which is finite) doesn't have to hunt for it. Compared to the rate at which silicon must make scheduling decisions (at 800MHz, that's 1.25 nanoseconds), compiler time seems infinite.

Granted, compiler time is not infinite, but for performance-critical applications, it is quite large. The Texas Instruments TMS320C6000-family of DSPs, for instance, rely on compilers and assembly optimizers in order to eek out that last bit of performance, and as any DSP engineer will likely tell you, its usually worth it. Cycles saved in one loop are cycles that can be spent elsewhere on value-added features, leading to a more valuable product.

This points to the real fundamental problem as I see it, which is that the current VLIW darling in the industry is in the embedded world. Why should that make a difference, you ask? Because the embedded developer is the one most likely to take advantage of the raw capability that an exposed parallelism architecture can provide.

Merced's biggest problem lying ahead is the fact that workstation-class code does not naturally exhibit large amounts of parallelism. While I was attending MICRO-31, I heard someone remark about how most code looks like a series of 5-10 instruction bursts followed by a jump. ICK!!

Embedded programmers generally seem willing to learn whatever it takes to get their product running in the fewest MIPS (so that they can either use cheaper parts or provide more features), and so are often willing to jump through a few hoops to help out the compiler in order to get the parallelism they desire.

Workstation programmers, on the other hand, are interested in the much bigger picture (since their applications are much larger and tend to have larger life expectancies), and so code tends to be human-friendly and not compiler friendly. (Certain heavily-traveled code paths in the Linux kernel being a noteworthy exception.)

The point is that the Merced compiler will ship with alot of amazing compiler transformations, but very few of them will be effective at translating the hopping, skipping, and jumping nature of your typical general-purpose database-ish looking code into highly parallel performance-oozing EPIC instructions, at least straight out of the gate.

Merced will inherently provide big performance wins to the compute-farm customers (your big engineering shops that currently use networks full of Sun or HP workstations to crunch VHDL, Spice, or whatever simulations around the clock), as these applications end up reducing to huge matrix manipulations and numeric crunching galore -- oozing with parallelism. But Merced will be hard pressed to feed up web pages or database queries much faster than any other architecture, unless it's able to massively crank its clock rate due to losing the shackles of the instruction scheduling hardware.

Anyway, those compiler nuts in the crowd might find the following links useful and informative.

• The Rocket Project -- ILP research at Michigan Tech University
• VLIW Architectures -- a description of VLIW that's part of a larger presentation about VLIW compiler techniques.
• The Trimaran Research Compiler -- HP's research compiler that was supposedly used in development of the architecture that begat Merced.
• EE Times -- article which describes the release of Trimaran and includes a diagram showing the relationship of architectures from Superscalar to VLIW/EPIC to TTA.