h a l f b a k e r yMay contain nuts.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Gigabit ethernet is fast enough that network resources of all kinds (including data-intensive apps) appear as local resources. I suggest taking this technology and applying it to the internal architecture of PC's. Inside every beige box, each component (processor, hard drives, peripherals, etc) has
its own IP address. The computer communicates internally using ethernet instead of traditional bus architectures. Advantages:
1. components can be wired together in any order, just like ethernet nodes
2. no need to have a system clock, and interrupts, since timing would be internal to each "node" component
3. upgrading any individual component would be easy
4. the distinction between "computer A" and "computer B" would become blurred, if they were connected in multiple ways (idea here is that a supercomputer/cluster would be a natural growth of ethernet bus)
Active Networking
http://www.halfbake...Active_20Networking
Tangentially related halfbakeme [hippo, Jul 18 2001, last modified Oct 05 2004]
all about buses
http://www.busnut.com/home.html
i don't know if this will help in this discussion, but... [mihali, Jul 18 2001, last modified Oct 05 2004]
A disaggregated component
http://www.halfbake...l_20filing_20system
With a network-style protocol [sadie, Sep 12 2002, last modified Oct 05 2004]
[link]
|
| |
My first inclination is to
point out that Ethernet is
already a bus, however I'll put
pedantry aside and point out
instead that a packet switched
internal network would be
slower than anything in use
now. Not to mention that every
device would have to have a
built-in network card and
connector. |
|
| |
I do however appreciate the
imagery this idea conjures up. |
|
| |
The problem is that for almost every device in the system the gigabit bus will either be too slow, to expensive, or both. |
|
| |
A data rate of 1Gb/sec corresponds to 125MB/sec. If this rate equalled the achievable throughput, such a bus might be suitable for hard drives. Unfortunately, it's usually difficult to achieve anything near maximum throughput with ethernet networks. Still, use of ethernet-based hard drives would not be unreasonable if they didn't cost too much. Unfortunately, adding 1Gb/sec ethernet support would almost certainly add significantly to the cost of a hard drive, for relatively little benefit. |
|
| |
For video display devices, a 125Kb/sec maximum rate might be serviceable, but it would be slower than cards already on the market. I can imagine that for some situations an ethernet-based display could have some advantages, but having the display on a high-speed parallel bus is for most purposes both faster and cheaper. |
|
| |
For memory, anything other than a parallel bus is out of the question. On an ethernet-style bus, every cache miss would require sending and receiving many bytes of addressing/routing stuff in addition to the actual data required. The overhead would just be absurd. |
|
| |
Stuff like keyboards, mice, etc. could probably be connected via 1Gb ethernet, but doing so would be absurd. The interface hardware alone would cost more than the rest of the keyboard or mouse. |
|
| |
Good responses - you all seem to be getting the gist of the idea, even though there are problems. |
|
| |
I like Rods Tiger's suggestions.
What about using radio? Each device can have its own broadcast frequency, and can listen to many others. This would enable multiple parallelasynchronous communication. |
|
| |
I don't know that people understand how the synchronization requirement of contemporary PC busses is a limitation. Also, at risk of sounding 90's managerial, breaking out of the box could be a real evolutionary step. Instead of just P2P, wherein the computer is a communication portal between 2 people, imagine if 2 computers could connect and auto-cluster, forming a trust-based interchange across all abstraction layers.
Ah, dreaming.
Thank you all. |
|
| |
[Œb]: You're getting close to building a simulated computer with a certain bus architecture inside another computer which has an arbitrary bus architecture. See "Active Networking" link and all the TIB links from there. |
|
| |
This is actually quite viable, provided you're prepared to limit the scope a little. There are really two levels of connection inside the computer - the fast one for memory, CPU, graphics etc and the slower one for cards, discs and so on. Ideas like hypertransport will take over the faster link from the current messy bus architecture. Perhaps the lower link could become a network of this form? |
|
| |
As stated, ethernet is not the right solution, but something could be done that is. |
|
| |
Hang on a mo. This could really work (with a slight modification). Imagine splitting your computer in two (both with processors an memory - there's the modification). |
|
| |
One could act as a input/display unit with a mouse, keyboard and monitor. |
|
| |
The other could be a sort of 'databrick', holding your data your data and programs. |
|
| |
The input/display box would have a small OS in firmware. The OS would simply be a standards compliant browser. |
|
| |
The databrick would have two network ports (upstream/network and downstream/display) and would act as a web server supplying applications to the display unit. |
|
| |
Games players would probably have to add an additional protocol which pushed keyboard/mouse/koystick actions one way and realtime screen images the other. |
|
| |
The advantage? With all the protoccols described here (apart from the gameplayer one) being standard, you could put your databrick in your bag, carry it around an use it anywhere. You wouldn't even need a standard input/display unit - any computer with a web browser would do. With a little bit of scrabbling at work you could insert it between your works PC and the network and get at all your files, emails etc. You could even add a battery and PDA interface and get at (possibly a limited amount of) your data on the move. |
|
| |
...or is this a different idea? |
|
| |
[Rods Tiger] I like the optical idea, but what about my neon light and el cable in the case? Now what do I do? ;) On the serious side though, wouldn't that much light be giving off a bunch of IR and thus, IR receivers on the computer/near the computer might receive a lot of interference, no? |
|
| |
It's a different idea [st3f], but a compatible one. If you allow that the CPU(s), memory and graphics card all form an 'inner sanctum', with fast internal links that appears as one node on the internal network, then there's no reason you couldn't have several inner sancta. |
|
| |
In fact, this idea opens up all sorts of possibilities. Especially if you start using disaggregated components. |
|
| |
See "Storage Area Network" and "Network Attached Storage". |
|
| |
The price, flexibility, bandwidth, and range (maximum distance) of physical network layers are all interrelated. Crank up the flexibility, keep the price the same, you lose bandwidth. Crank up the flexibility, keep the bandwidth the same, it costs more. TANSTAAFL, and that's not even considering the legacy compatibility issues that make PC hardware the nightmare that it is. |
|
| |
That's why we have PCI and AGP and Ethernet and USB and Bluetooth and WiFi and Fibre Channel and FDDI and HIPPI and all the other things that populate that multidimensional space. Pick your bus, you probably can find a component; if you look hard enough maybe you can even find an Ethernet mouse. Pick something obscure enough and you'll pay the price, of course. |
|
| |