I think that technology is headed in that direction.
You would have your "system-on-a-stick" (SOS) or for a larger system it may be something the size of a PocketPC with a couple of terabytes of memory with integrated processors. The base station would have all the KVM w/Audio connections. The SOS would connect to a docking port that would provide the relatively low bandwidth inputs/outputs for the KVMA device. You could easily include wireless connectivity into either the SOS or the PocketPC device to have internet connectivity without the need for a higher bandwidth connection to the base station.
The Video and Audio would be controlled by the base station so the quality of the video or audio would be dependent on the base stations configuration.
I think this is entirely feasible in the near future.
Phil
-----Original Message----- From: kclug-bounces@kclug.org [mailto:kclug-bounces@kclug.org] On Behalf Of Kelsay, Brian - Kansas City, MO Sent: Wednesday, August 08, 2007 10:24 AM To: KCLUG Subject: RE: What's in a node?- RE: talking about where processorormemorygoes and why.
So do you think we may end up with a type of base station or thin client that gives you a monitor, KB, mouse and the basics, but you have a processor and memory in a pendrive-like case that you carry around?
I can see this leading to some high-bandwidth connector like 1394 (firewire) for portable drive and processor and a commodity or standard docking box. It would allow for easy upgrades and not so much mass of hardware being thrown away. Your dock/thin client/base station device could be like the Mac Mini or that AMD PIC computer in size with at most a single internal optical drive, USB for KB and mouse, basic 3-D video and then whatever high-speed ports (2-3) for plugging your CPU/memory module and pendrive and heck, even an add-on video module.
If something like this comes out, then I can only hope there is a single open design for the ports and dock basics so there is not the trouble like the Firewire standard had with the extra fee per port.
Brian
-----Original Message----- From: Phil Thayer Sent: Wednesday, August 08, 2007 10:10 AM
The technology you are thinking about may be on the drawing board already. Check out the next generation of Intel Chips.
http://news.com.com/Processor%2C+memory+may+marry+in+future+co mputers/21 00-1006_3-6120547.html?tag=nefd.top
I like the idea of an aggregate memory bandwidth of 1 terabyte/sec. Pretty fast.
With this type of chip technology on the horizon, the computer on a memory stick is the next logical step to follow it.
Phil
-----Original Message----- From: kclug-bounces@kclug.org [mailto:kclug-bounces@kclug.org] On Behalf Of Charles Steinkuehler Sent: Tuesday, August 07, 2007 6:15 PM To: Oren Beck Cc: KCLUG Subject: Re: What's in a node?- RE: talking about where processor or memorygoes and why.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Oren Beck wrote:
Well- why not have some ubergeeken amongst us whack together some prototypes?
I'll bring the mask layouts, if you bring the fab equipment
capable of
running a fairly recent DRAM process.
Oh...and I'll probably use just about *ANYTHING* other than the 808x family, which I've always viewed as an abomination (the better mousetrap doesn't always win). The 6502, 6809, and several other lesser well known parts (harvard architecture DSP like cores,
stack-based machines
like the Harris RTX series and Atmel MARC4, or even PIC's for god's sake) are IMHO all better suited for such a machine. :)
If you're not really serious about pushing the state of the art, you can roll an array of CPU flavor(s) of your choice and a
respectable amount
of memory in modern FPGAs. You can squeeze in a pretty decent number of processors (depending on the core, of course...you get more 6502's than 32-bit MIPS cores!), where this really suffers vs. a custom solution is the memory. The biggest FPGA's are currently toping out around 1 MByte of internal block memory.
...but then who's ever going to need more than 640KB, anyway?!? :)
Charles Steinkuehler charles@steinkuehler.net
Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug