I think if there was some incentive to gas stations to provide free compressed air again (along with decent built in tire pressure gauges) perhaps it could incentivize people to check their tires more often. At least up here in the US Northeast, many folks drive around in the winter on low tires. Between the cold temps and charging people for a couple minutes at the air compressor, few folks bother -- even though it would pay for itself in measurably improved gas mileage.
Speaking as a Milford, NH resident, babbage is right. Both the Segway and Mt. Washington have their local appeal. Dean lives a couple of towns northeast of me in Bedford. "* climbed Mt. Washington" signs and bumper stickers are common. New Hampshire Public Radio covered this a few days back. You'll need the Real Player or Windows Media Player to listen to their coverage. Otherwise you can at least read the transcript of their report.
Funny you should mention this. I installed mod_gzip just this past weekend. It was pretty trivial even on Mac OS X (aka Jaguar). I downloaded it from sourceforge and compiled it with apxs. I patched in the well commented template into my httpd.conf. I restarted Apache and it was serving compressed pages (as I think Slashdot does). It was the first time I've built an Apache module. I wish plugging in Emacs extensions was that easy... YMMV
A quick and dirty test to see if your gzip'ing works is at:
Having used lynx and w3m I'd have to give a vote for the links web browser. I'm running it on a lightweight slack based distro (VectorLinux 2.0) on a P133 laptop with 32MB RAM. It can run under the linux console or in the X windows terminals (xterm, rxvt, eterm...). The big keys for me were:
a) it can use the mouse (X or gpm for the console)
b) it colorizes and uses the special line characters when appropriate
c) it does tables and frames much better than lynx (as does w3m)
d) it does cookies (useful for slashdot)
e) it uses a meg or two of RAM.
For browsing news sites, blogs, etc, it does very well. Check out the screen shots at the links homepage if you've not seen it before.
w3m does well, too, but I can't get used to the VI keybindings...;-)
When I first read this, I thought "What do Slashdot readers care about exercise music?" Then I realized that you don't mean this Dynamix company. They are a leader in creating the types of music aerobics instructors use to teach their classes.
Silly me... You meant the other Dynamix.;D
Asynchronous digital logic systems is an idea that has been tossed around for quite some time. I can't name all the difficulties with it but there are a few issues that haven't been brought up (at least when I scanned the postings).
First, most ASICs built these days are built with logic synthesis tools from Synopsys or Cadence. The inputs are typically register transfer level (RTL) code written in either the VHDL or Verilog languages. These logic synthesis tools have been around for quite some time (well over a decade for Synopsys) and have a significant infrastructure built around them. This design paradigm and sets of tools all assume synchronous logic. I can't fathom how you would build/constrain/debug these circuits in an asynchronous style with the existing toolset. And don't say "we'll use something else". It is these types of tools which have made our million gate ASICs possible. If we were still using schematics or other hack tools we would barely have passed the 80286. The current design tools took a long time to develop, hone, and get the bugs out of. The amount of money involved in just the tools is on the order of billions of dollars per year. That's a lot of inertia to move away from.
Second, yes the asynchronous approach can reduce the power consumption of ASICs. However, there are a lot of clocked approaches that do a very good job of reducing power. It all depends on what goals you have when you design the ASIC. Having multiple clocks and clock gating is common in the low power and embedded domains. It hasn't been as much of a factor in desktop systems but is certainly in use in handheld devices. The Crusoe takes these approaches to an extreme level. It's all a matter of what you want to design for and time to market pressures.
Lastly, speed. I think folks forget the feedback path. If you're going to rely on this asynchronous handshake, it requires a given stage to hold its outputs until the next stage acknowledges (asynchronously) that it got the data. This means the given stage can't accept anything new yet. This cascades/ripples back through the pipeline. This feedback takes time (and logic levels) that don't exist in clocked logic. Imagine an automotive assembly line where things could only move forward if each station got permission from his adjacent stations. In clocked logic you've guaranteed that the data is ready to move forward because you've calculated these things out. You've removed a bunch of communication overhead. Yes, there is slack in the synchronous pipeline, but for the most part current designs are pretty well balanced so that each stage uses a large portion of its clock cycle.
That's about all I can think of at the moment. I need to be getting home before I get snowed in!;-) Just a few comments from a digital hardware designer. Hope this provided some food for thought...
Slashdot Mirror
I think if there was some incentive to gas stations to provide free compressed air again (along with decent built in tire pressure gauges) perhaps it could incentivize people to check their tires more often. At least up here in the US Northeast, many folks drive around in the winter on low tires. Between the cold temps and charging people for a couple minutes at the air compressor, few folks bother -- even though it would pay for itself in measurably improved gas mileage.
Speaking as a Milford, NH resident, babbage is right. Both the Segway and Mt. Washington have their local appeal. Dean lives a couple of towns northeast of me in Bedford. "* climbed Mt. Washington" signs and bumper stickers are common. New Hampshire Public Radio covered this a few days back. You'll need the Real Player or Windows Media Player to listen to their coverage. Otherwise you can at least read the transcript of their report.
A quick and dirty test to see if your gzip'ing works is at: You could consider it a "gzip" validator. If the page isn't compressed, it shows you what the savings would be like if it was compressed.
-- Scott
Having used lynx and w3m I'd have to give a vote for the links web browser. I'm running it on a lightweight slack based distro (VectorLinux 2.0) on a P133 laptop with 32MB RAM. It can run under the linux console or in the X windows terminals (xterm, rxvt, eterm...). The big keys for me were:
;-)
a) it can use the mouse (X or gpm for the console)
b) it colorizes and uses the special line characters when appropriate
c) it does tables and frames much better than lynx (as does w3m)
d) it does cookies (useful for slashdot)
e) it uses a meg or two of RAM.
For browsing news sites, blogs, etc, it does very well. Check out the screen shots at the links homepage if you've not seen it before.
w3m does well, too, but I can't get used to the VI keybindings...
When I first read this, I thought "What do Slashdot readers care about exercise music?" Then I realized that you don't mean this Dynamix company. They are a leader in creating the types of music aerobics instructors use to teach their classes. Silly me... You meant the other Dynamix. ;D
First, most ASICs built these days are built with logic synthesis tools from Synopsys or Cadence. The inputs are typically register transfer level (RTL) code written in either the VHDL or Verilog languages. These logic synthesis tools have been around for quite some time (well over a decade for Synopsys) and have a significant infrastructure built around them. This design paradigm and sets of tools all assume synchronous logic. I can't fathom how you would build/constrain/debug these circuits in an asynchronous style with the existing toolset. And don't say "we'll use something else". It is these types of tools which have made our million gate ASICs possible. If we were still using schematics or other hack tools we would barely have passed the 80286. The current design tools took a long time to develop, hone, and get the bugs out of. The amount of money involved in just the tools is on the order of billions of dollars per year. That's a lot of inertia to move away from.
Second, yes the asynchronous approach can reduce the power consumption of ASICs. However, there are a lot of clocked approaches that do a very good job of reducing power. It all depends on what goals you have when you design the ASIC. Having multiple clocks and clock gating is common in the low power and embedded domains. It hasn't been as much of a factor in desktop systems but is certainly in use in handheld devices. The Crusoe takes these approaches to an extreme level. It's all a matter of what you want to design for and time to market pressures.
Lastly, speed. I think folks forget the feedback path. If you're going to rely on this asynchronous handshake, it requires a given stage to hold its outputs until the next stage acknowledges (asynchronously) that it got the data. This means the given stage can't accept anything new yet. This cascades/ripples back through the pipeline. This feedback takes time (and logic levels) that don't exist in clocked logic. Imagine an automotive assembly line where things could only move forward if each station got permission from his adjacent stations. In clocked logic you've guaranteed that the data is ready to move forward because you've calculated these things out. You've removed a bunch of communication overhead. Yes, there is slack in the synchronous pipeline, but for the most part current designs are pretty well balanced so that each stage uses a large portion of its clock cycle.
That's about all I can think of at the moment. I need to be getting home before I get snowed in! ;-) Just a few comments from a digital hardware designer. Hope this provided some food for thought...