I met Sally (briefly) at JPL, after her 1984 Challenger mission. My impression was of someone who was confident, supremely able, and didn't worry a lot how she dressed. I got this impression since she showed up at the lab wearing shorts, and seemed instantly at home, like she'd been working there for years. Her later partnership with Tam was a surprise, since she gave no hint of that during her astronaut years. But yes, getting a ride on the big machine in the early 80's was a very political game, as much about appearances as it was about ability. And ability she had in spades. During the October 84 Challenger mission, all kinds of shit went wrong. An RF antenna cable on the radar overloaded and started arcing, causing the SNR to radically drop. The monitoring equipment at Johnson acted up, showing loss of TDRS downlink data when it was actually fine. I also seem to recall that Sally had to take apart parts of the shuttle with a wrench to get access to the data recorder, because of some malfunction or other. So overall, the mission was a disaster. But Sally took it all in stride. Best wishes, Sally. Some of us remember you.
I am constantly frustrated with Yet Another Plan for Humans In Space. When will the politicians finally recognize the folly and waste in trying to put Humans into an environment completely unsuited for them? Do we see bizarre unrealistic plans to colonize Antartica? or the bottom of the sea? Then why this fetish about putting humans in outer space? Because of the constant re-runs of Star Trek and Stargate on the Syfy channel? Who believes that crap? It's patently obvious that the future belongs to the machines.. and only the machines.. Machines designed and constructed to excel in their target environment. I speak not from random passion, but from actual experience. I'm a 10 year veteran of JPL. We built machines there that *worked*, that explored the outer planets, and returned vast amounts of serious data. We should not be wasting another dime on putting humans any higher than 50,000 feet. Everything above that should be done by machines, and the best AI we can muster. Money should be poured into radiation resistant computing, AI, and self repairing electronics with massive redundancy. We need to establish AI operated bases on the moon and near earth asteroids, in order to start using the matter for construction of space based observation and computing platforms. No question, the future of the human civilization is *in* space.... with the machines we create. Not with monkeys in space.
Here is a decent recipe for a fast secure home server: Start with an ASUS Maximus III LGA1156 motherboard (with 10 Sata connectors), an Intel I5-660 CPU (32 nm, with support for AES instructions). Add 2 Gb of DDR3 memory, and at least 6 WD Green 2TB drives. Install either a 4GB USB key or a SSD drive for root storage, and then install Lucid Lynx 10.04 Server AMD-64. The latest kernel in Lucid now supports per-CPU threads for both RAID6 and dmcrypt, vastly accelerating both functions. It's now possible with this CPU to easily exceed 100 Mbytes/sec over the Gb Ethernet (using NFS) when running the following software stack: RAID6, with Luks (dmcrypt) using AES-XTS mode, and finally EXT4 (or XFS if you prefer). I've noticed significant bandwidth improvement using Lucid Lynx, even with relatively low performance AMD Athlon dual core cpus. I'm now bonding dual (or triple) ethernet interfaces, because I can saturate a single Gb Ethernet port. This solution still lacks checksums on files, but when BTRFS is released for general use, it ought to be excellent.
I noticed in early July that my Kubuntu 8.10 machine started showing corruption in the EXT3 filesystems, and it seemed to happen everytime I used Firefox (which had Flash installed). I finally got so sick of restoring from backups that I rebuilt a totally new Kubuntu 9.04 image, without Firefox. I now run Firefox in VirtualBox, using a sandboxed image of Kubuntu 9.04. This has stopped the filesystem corruption in the host OS, but I continue to see EXT3 corruption in the sandboxed Firefox with Flash. It's beginning to look very sensible to use 3 virtual machines for browsing the web now. Green Sandbox for just my banks. Yellow Sandbox for email and Paypal, and Red Sandbox for everything else (including Slashdot). Even with Noscript, the Red Sandbox gets dirty still, and needs rolling back to the initial snapshot. I haven't run rootkit detection or virus scanning yet, but I'm beginning to believe that integrated intrusion detection will be the next Great Thing (tm) for virtual machines. Charlie Stross thought about this years ago in Accelerando. It's worth a read.
I had to read all the comments before I decided to contribute my solution to the problem. I use a portable Sata2 hard drive, with a Vantec enclosure that supports Sata2 and USB. I use a 250Gbyte 2.5" hard drive encased in the Vantec aluminum shell, which slides into a docking station in a 3.5" drive bay. I have one of these at home, and one at the office. I carry the disk around with me, and boot Kubuntu Intrepid from an 80Gb partition on the drive. But there's some magic in the way the drive is setup. The 250Gbytes is split into 3 partitions of 80GB, with a 10GB swap at the end (which is almost never used). Each partition is actually configured as an element of a Raid 1 (mirror) drive, with 3 copies. Having a 3 way RAID 1 lets me sync the portable drive to the desktop drive and simultaneously create an extra copy on a 3rd device if I need it. The desktops I plug this drive into also as a Sata2 hard drive, and once I successfully boot from the portable drive, I then add a partition from the fixed 3.5" drive in the desktop, and then they sync up at around 50 Mbytes/sec. This creates my backup in case of loss, corruption, or crash. As for privacy, I do full disk encryption on top of the RAID layer with dm-crypt, so I don't really worry about any of the disks being stolen.
The same Kubuntu image boots beautifully on my laptop (using USB to connect it), and I also have a RAID1 mirror partition on the laptop for backup. This way, I have multiple copies of my operating system (with home directory) in different locations, and everytime I resync the RAID 1 devices, I freshen the backup (usually daily). I had one disk corruption problem that needed an OS rebuild, so I switched from XFS to EXT3 and haven't had any further problems. And what about Windows? No problem... A copy of VirtualBox gives me an XP Home version of Windows right inside Kubuntu, where it lives very happily. Remember, Windows works much better as an application than it does as an OS. One thing to note on the replication speed. I setup the RAID 1 devices with internal bitmaps, which keep track of modified raid chunks, and this causes replication between similiar images to proceed at a *much* higher speed than a simple copy. I can synchronize an 80GB RAID 1 partition in about 15 minutes when using a SATA connection. So at the cost of buying a 2.5" hard drive and a pair of Vantec docking stations, I can carry around my OS and home directory with security, redundancy, and convenience.
Disclaimer #1: I work for Xilinx. Disclaimer #2: I used to teach VHDL, back in the late 90's. I too, voted on the IEEE effort for standardization on the synthesizable subset for VHDL, and boy what a waste of time that was. But I digress. Here are some cool reasons why VHDL is better than Verilog. 1. Recursion. You can write recursive hardware components that instantiate smaller versions of themselves. Recursion is cool, but tools hate it. The Xilinx tools complain about it, but will still produce the right hardware. Recursion can be used for Multipliers, adder trees, priority encoders, muxes, and just about anything where divide and conquer actually works. 2. Attributes. VHDL attributes translate straight to EDIF properties, and let you do cool stuff like physical design in an FPGA, EDIF properties in the netlist let you do anything from selecting the power-on state of a flop, to setting the logic function of a lookup table (LUT), or setting the initial value of a RAM. Even better, you can pass LOC (Location) or RLOC (relative location) properties, allowing you to physically place the location of a component in the target device. You can even specify directed routing constraints that lock down the signal path to a specific defined route. Verilog will sort of let you do this, but only in a pragma (code comment). Hence creating relatively placed soft macros controlled by top level generic parameters is possible in VHDL, but not in Verilog. 3. Compile time elaboration of constants. This sounds incredibly obscure, but is actually very powerful. During elaboration, constants are evaluated. Constants can be defined by an arbitrarily complex function call. These functions can perform arbitrary computation, as well as read and write files. A standard trick is to read a hex file from the design directory containing data to load into a RAM or a ROM. I use compile time function calls to do precomputation on stuff where I don't know the generic parameters in advance. An example of this would be a state machine to detect a serial unique word, with the states branches computed at compile time by function calls that calculate the state branches based on a unique word specified in a generic parameter. Or how about CRC's? You see people writing C programs to generate Verilog designs to calculate a CRC, but in VHDL, you can compute the parity matrices directly at compile time given a static CRC as a generic parameter. Once the parity matrix is generated, it's easy to generate the hardware to calculate it. It's a bit trickier to do error correction with a CRC, but also possible. These calculations are hideously difficult in Verilog. 4. Type REAL. VHDL has a floating data type REAL, and even a IEEE library REALMATH to use it with (Sine, Cosine, Tangent, etc). You can do very nice geometry calculations during elaboration with this library. Or, for the EE's, you can do stuff like generate coefficents for a raised root cosine filter in VHDL. Now REAL types can't be synthesized directly, since they have no direct hardware representation.. but REAL can be converted to INTEGERs, and integers can be turned in to real hardware with a precision of up to 32 bits. That's plenty in most cases in an FPGA.
Now having said all that... System Verilog has a LOT going for it, and when the tools catch up to the Language Reference Manual, then it could be an extremely powerful design language. This presentation from DATE 2004 shows why. http://www.systemverilog.org/techpapers/date04_systemverilog.pdf
There's probably a physical reason why your DSL is having difficulty in the evenings: NEXT and FEXT. Near End Crosstalk, and Far End Cross Talk. In the peak hours (i.e. after work in the evening), *everybody* is online, surfing and downloading and what have you. DSL uses multi-tone modulation, and resembles Gaussian pink noise in its distribution and spectrum. This bleeds across to the other pairs in the cable bundle going to the central office, raising the noise floor for everybody, at both ends of the link. When the noise floor goes up, all DSL modems fall back to using fewer tones, and simpler constellations in the modulation, in order to get the bit error rate to a reasonable level. In extreme cases, data throughput can fall to very low levels, as you report. Moving to a location closer to the CO will definitely help. Cable service providers have less of an issue with crosstalk, since there's only a single coax cable involved, but they can have other issues with cross-channel noise caused by clipping and non-linearities in the cable amplifiers. This can be pretty ugly for the analog cable channels still carried as a legacy service. Mine look like crap because of all the digital services crammed into the cable bandwidth. I think the ultimate answer is FIOS, which scales to huge numbers of users, with the only conflict being access to the shared bandwidth of the switches and upstream links.
I've been working on this for years, literally. I'm still not satisfied, but at least it's gotten to the point where the urgency to improve it has gone down a bit. Here is my recipe:
1. M2N-E Asus Motherboard + 1 Gbyte DDR2 + AMD X2 5000+ CPU with unlocked clock multiplier. No Graphics card. 2. Antec Nine Hundred case with 450 watt energy efficient PS. 6 Seagate Sata2 500 GB disk drives. 3. APC backup unit with 1000+VA, like the XS1200. APC is the preferred brand, since driver install is easy.
Assemble hardware, and temporarily install a DVD-ROM, keyboard, and graphics card for installation of Ubuntu server. I've used 6.10, 7.04, and 7.10 successfully. Boot your favorite version of alternate install CD of Ubuntu AMD64 server and install it, after partitioning all the disks with small partitions of 1024 cylinders as partition 1, and the rest of the disk as partition 2. Then create RAID1 arrays on partition 1 (partition type FD) of disks A & B, and another RAID1 array on disks C & D. Partition 1 of disk E is a swap partition, and partition 1 of disk F is spare. After creation of the RAID1 array on A & B as/dev/md0, then use this for the root mount point./dev/md1 on C & D can be used in the future for upgrading to newer releases without having to trash the original on/dev/md0. I don't bother with a LAMP installation, since I want pure file services. I do add DHCP, TFTP, SSH, NFS, and Samba services either during the installation, or after. After a successful install and reboot, then modify the grub menu to set up a serial console. http://www.howtoforge.com/setting_up_a_serial_console
Yank out the DVD, graphics card and keyboard, hook up a serial cable, and verify that it reboots with output directed to the serial port. The whole point of making the server headless is to remove all temptation to run an X-Server on the machine. This way lies madness and disk corruption. Preservation of the data takes precedence over convenience. You can do everything you need via SSH, or in a pinch, with the serial port. After beheading the machine, I usually continue configuration via SSH from another box on the network. Next, create a RAID6 array on the 6 disks using the 2nd partitions, which will give you a little under 2TB of usable storage. RAID6 may seem a bit of overkill, but RAID5 arrays usually have their moment of truth during a rebuild after a drive failure, and this is when unreadable sectors usually rise up and bite you very hard. With Raid6, you still have a margin of error after a disk failure, and we all know it's not a matter of if, but when.
Now install loop-AES. This always requires a build from source code, and instructions can be found on the ubuntu forums . Loop-AES is more complex to install than LUKS, or other linux disk encryption schemes, but the performance and security are the best available. This is why the OS should be in 64 bit mode, since this gives a little faster speed to the AES256 encryption. Creation of a suitable encryption key is covered elsewhere, but I strongly recommend 65 keys, a good random salt value, and a high iteration count on "losetup". I use an iteration count of 2,000,000, which takes about 2 minutes for the CPU to perform. The keyfile & salt value should be stored on an separate USB key, stored in an encrypted filesystem with a different salt value, a high iteration count, and a 20 character strong password. This combination is military grade, and places the weak link of the security chain squarely in your head. In other words, your password and the USB key become the only possible method for recovering your data, so making copies of the USB key is strongly recommended. I keep a copy at the bank, in a deposit box, as well as
For those with a cryonics contract, the cryonics provider is more than happy to take delivery of a hard disk or 2 along with your cooling corpse. It will help quite a lot in reconstruction of your synaptic pathways if a lot of side data is available to cross-correlate and verify information extracted from destructive nanoscanning of the vitrified brain. In other words... GUARD YOUR DATA. Unless you want to be dead, buried, and forgotten, like billions of people before you. How boring. I myself carry a digital camera and voice recorder 24/7, and am accumulating about 40 Gbytes/year of personal data. I don't plan on forgetting who I was, or used to be. Encryption, of course, is required to keep my identity from being distributed widely, so a balance has to be made between security and safety. I had a rather nasty accident with an AES256 key earlier this year and lost 2 months of my life, along with some neat photo's and recordings. Oh well, live and learn.
I'll tackle this answer, since I'm fairly qualified to answer. FPGA's very typically run at clock rates of 100 to 300 MHz. You might see 100 MHz rates done by beginners or sloppy ASIC coders, and 300 MHz by experienced designers who spend extra timing making sure there are enough pipeline registers. The *highest* speeds I've seen are around 650 MHz, and these only occur in extremely specialized circuits designed at a very low level by guys with Godlike powers of intuition and creativity (& patience!). Next year, you can multiply these figures by 30 or 40 percent. These speeds are far lower than your typical Athlon or Pentium, but with enough parallization and pipelining, you can actually far outperform them. But, as you've no doubt read, it's HARD. Tools are getting better, but it will be a while before you can get Borland tools for FPGA design.
Sure, laugh now guys, while you can.
on
Going Cyberpunk
·
· Score: 4, Insightful
It's easy enough to poke fun at the crude brain implant IC's developed so far... It will be a whole lot less funny when the state of the art advances to the point where they start to become actually useable. Right now, high tech corporations boost the effective IQ of their employees by buying them the best computers and software available. We all benefit from this and enjoy the perks of having a nice fast machine and the latest software. What do you think will happen if implant IC's can be shown to boost effective IQ by 30 or 40 points? Or rather, if it boosts design productivity by 50% or more? They guys who have implants will be in tremendous demand, while those who lack them will be consigned to writing technical documents, or customer support. It could get downright nasty, trying to compete with guys who can literally outthink you by a wide margin by virtue of their hardware link. It's bad enough that we are starting to see tech jobs moving to India and other 3rd world sweatshops, but brain implants will bring the digital divide to a whole new level. All this carping aside, I sincerely want an implant. Voice recognition sucks, and fingers and mouse are rarely fast enough to do everything I'd like. Once they've been shown to be medically safe, I'll probably take the plunge. Maybe in 10 years, but I hope in 5.
And to answer the unspoken question: Can FPGA's be used in your brain? I say this: Get Real. Current FPGA technology has no possible application. Maybe in 5 or 10 years, when we have conquered the leakage problem, and have developed fuel cells that run on glucose. But I don't see it, since an ASIC dedicated to brain interface functions will be a far superior solution. FPGA's may evolve into a future computing fabric, so they may have useful applications in external hardware, but it will be a very distant descendent of FPGA's that are finally used for in-body implants.
"Against Stupidity, the gods themselves strive in vain."
I've been avidly following all the editorials, stories, commentaries, and blogs since Columbia was destroyed last week, and I have yet to see any writer to put their finger on the basic problem with manned spaceflight.
I'll put it in words for you: Humans don't belong in outer space. Lest I be accused of some sort of retro Luddite philosophy, let me clarify the foundation of that statement. Humans evolved on the African plains millions of years ago, and have admirable survival traits for all sorts of circumstances that can be found on this planet. But we don't live (normally) in Antarctica, nor do we live in the ocean. It's the wrong environment. Trying to export an earthlike environment to the rest of the solar system is not only stupid, it's doomed to failure.
So what's the answer? Let's think of it in terms of ecological niches, shall we? What sort of animal can you design to survive and flourish in the Oort cloud? First of all, normal body temperature should be only a few degrees above ambient (4.7K). Secondly, you need the ability to gather energy from the environment (solar radiation, fusion, etc...). Finally, and most importantly, you need the ability to survive the constant bombardment of hard radiation, high energy elementary particles, micrometeorites, and other random junk. This implies redundancy and regeneration on a nanoscale that is as yet unknown to our technology.
So what should we do? We should expand our unmanned space program dramatically (in particular, we *must* map all the potential "dinosaur-killer" near-earth asteroids), kill the manned space program, and concentrate on developing nanoscale technologies that will permit machine based AI's to survive the natural space environment. If you want to visit outer space, you'll have to upload yourself to a machine that's already there!
To recap, there is no point in trying to populate the galaxy with humans. It's the wrong ecological niche! On the other hand, there's nothing wrong in uploading human intelligences into machines that will explore the galaxy. Now that is a project that sounds interesting! But I can't help but wonder, has it been done already?
I have the answer...
Analysis of all the data collected will require strong AI.... Gordon Bell's vision of storing all his experiences and personal data online is just step 1.
Step 2 will be the creation of software to analyze the raw data and create the associations and symbolic searchable representation.
Step 3 will be the creation of an AI model of your mind, able to access your data and predict how you think. At about this point, a hardware link to your brain would be extremely useful so that you can directly access your personal data.
Step 4 is the gradual creation of a hybrid AI composed partly of your brain and partly of the silicon running on your data.
In step 5, you move all your computation to the silicon, and use the wetware just for amusement.
What have you accomplished? A Moravec Transformation! Dont forget to send a Thank You note to Ray Kurzweil.
This discussion on JHDL is good, since it highlights the huge difference between writing code for a serial processor and parallel hardware. JHDL seems to be a Java based methodology for creating structural circuits which also happen to be simulatable using the Java environment. Bravo! But there are serious complications for people who want to get the most performance out of the FPGA silicon. FPGA design has evolved from the early days where a schematic was your only choice, but frankly, we still have a LONG way to go before we get as far as the convenience and power of the latest software IDE's for Wintel development. It's coming, I tell you! (having seen the inside stuff on future tools)
I have a few words to say about the various methods.
Schematics: OK for 1000 gate designs, but it scales very poorly to million gate devices.
Verilog: Easy to learn, simulates fast, can be scaled to very large designs, but it lacks OOP features, as well as hooks for attributes to easily implement EDIF properties that are so important for low level FPGA floorplanning. Some tools have pragmas that will let you floorplan, but it's pretty crude, since pragmas don't have any language hooks for doing loops or anything. You pretty much have to extend Verilog with a macro processor like VPP before it becomes practical for million gate high level ASIC design.
VHDL: Complex language, takes a while to learn, has some good OOP features, as well as the all important attribute which permits structural design equivalent to schematic level implementation. VHDL is slow to simulate and VHDL also suffers from crappy parsers, since most synthesis vendors don't support the full language (Mentor comes closest). I can synthesize sin(x) and cos(x) with only a single tool (Leonardo) at this point, since it is the only tool which really supports floating point calculation during elaboration. Even then, I have to convert the float (type Real) into integers to realize actual hardware. Because of the poor language support, many designers are looking for System-C, Handel-C, or JHDL to give them the higher level synthesis support. Most new internal IP development at Xilinx these days is being done with VHDL, since Verilog is such a bitch to parameterize and floorplan. Believe it or don't, but a lot of IP cores in our Coregen tool are done in Java. (The Java code creates a structural netlist, with optional floorplanning.) This seems to be more difficult that VHDL, so it's losing popularity lately. SystemC, Handel-C, JHDL can sort of be lumped together as high level simulatable structural methods that all share one feature. They don't have the hooks for low level FPGA design (like attributes), so fancy stuff is pretty tough.
Bottom Line: All design methods will be tossed in the meat grinder of the marketplace and the best will survive. Come back in 5 years to see what happened.
Slashdot Mirror
I met Sally (briefly) at JPL, after her 1984 Challenger mission. My impression was of someone who was confident, supremely able, and didn't worry a lot how she dressed. I got this impression since she showed up at the lab wearing shorts, and seemed instantly at home, like she'd been working there for years. Her later partnership with Tam was a surprise, since she gave no hint of that during her astronaut years. But yes, getting a ride on the big machine in the early 80's was a very political game, as much about appearances as it was about ability. And ability she had in spades. During the October 84 Challenger mission, all kinds of shit went wrong. An RF antenna cable on the radar overloaded and started arcing, causing the SNR to radically drop. The monitoring equipment at Johnson acted up, showing loss of TDRS downlink data when it was actually fine. I also seem to recall that Sally had to take apart parts of the shuttle with a wrench to get access to the data recorder, because of some malfunction or other. So overall, the mission was a disaster. But Sally took it all in stride. Best wishes, Sally. Some of us remember you.
I am constantly frustrated with Yet Another Plan for Humans In Space. When will the politicians finally recognize the folly and waste in trying to put Humans into an environment completely unsuited for them? Do we see bizarre unrealistic plans to colonize Antartica? or the bottom of the sea? Then why this fetish about putting humans in outer space? Because of the constant re-runs of Star Trek and Stargate on the Syfy channel? Who believes that crap? It's patently obvious that the future belongs to the machines.. and only the machines.. Machines designed and constructed to excel in their target environment. I speak not from random passion, but from actual experience. I'm a 10 year veteran of JPL. We built machines there that *worked*, that explored the outer planets, and returned vast amounts of serious data. We should not be wasting another dime on putting humans any higher than 50,000 feet. Everything above that should be done by machines, and the best AI we can muster. Money should be poured into radiation resistant computing, AI, and self repairing electronics with massive redundancy. We need to establish AI operated bases on the moon and near earth asteroids, in order to start using the matter for construction of space based observation and computing platforms. No question, the future of the human civilization is *in* space.... with the machines we create. Not with monkeys in space.
Here is a decent recipe for a fast secure home server: Start with an ASUS Maximus III LGA1156 motherboard (with 10 Sata connectors), an Intel I5-660 CPU (32 nm, with support for AES instructions). Add 2 Gb of DDR3 memory, and at least 6 WD Green 2TB drives. Install either a 4GB USB key or a SSD drive for root storage, and then install Lucid Lynx 10.04 Server AMD-64. The latest kernel in Lucid now supports per-CPU threads for both RAID6 and dmcrypt, vastly accelerating both functions. It's now possible with this CPU to easily exceed 100 Mbytes/sec over the Gb Ethernet (using NFS) when running the following software stack: RAID6, with Luks (dmcrypt) using AES-XTS mode, and finally EXT4 (or XFS if you prefer). I've noticed significant bandwidth improvement using Lucid Lynx, even with relatively low performance AMD Athlon dual core cpus. I'm now bonding dual (or triple) ethernet interfaces, because I can saturate a single Gb Ethernet port. This solution still lacks checksums on files, but when BTRFS is released for general use, it ought to be excellent.
I noticed in early July that my Kubuntu 8.10 machine started showing corruption in the EXT3 filesystems, and it seemed to happen everytime I used Firefox (which had Flash installed). I finally got so sick of restoring from backups that I rebuilt a totally new Kubuntu 9.04 image, without Firefox. I now run Firefox in VirtualBox, using a sandboxed image of Kubuntu 9.04. This has stopped the filesystem corruption in the host OS, but I continue to see EXT3 corruption in the sandboxed Firefox with Flash. It's beginning to look very sensible to use 3 virtual machines for browsing the web now. Green Sandbox for just my banks. Yellow Sandbox for email and Paypal, and Red Sandbox for everything else (including Slashdot). Even with Noscript, the Red Sandbox gets dirty still, and needs rolling back to the initial snapshot. I haven't run rootkit detection or virus scanning yet, but I'm beginning to believe that integrated intrusion detection will be the next Great Thing (tm) for virtual machines. Charlie Stross thought about this years ago in Accelerando. It's worth a read.
I'm happy.
Now having said all that... System Verilog has a LOT going for it, and when the tools catch up to the Language Reference Manual, then it could be an extremely powerful design language. This presentation from DATE 2004 shows why. http://www.systemverilog.org/techpapers/date04_systemverilog.pdf
There's probably a physical reason why your DSL is having difficulty in the evenings: NEXT and FEXT. Near End Crosstalk, and Far End Cross Talk. In the peak hours (i.e. after work in the evening), *everybody* is online, surfing and downloading and what have you. DSL uses multi-tone modulation, and resembles Gaussian pink noise in its distribution and spectrum. This bleeds across to the other pairs in the cable bundle going to the central office, raising the noise floor for everybody, at both ends of the link. When the noise floor goes up, all DSL modems fall back to using fewer tones, and simpler constellations in the modulation, in order to get the bit error rate to a reasonable level. In extreme cases, data throughput can fall to very low levels, as you report. Moving to a location closer to the CO will definitely help. Cable service providers have less of an issue with crosstalk, since there's only a single coax cable involved, but they can have other issues with cross-channel noise caused by clipping and non-linearities in the cable amplifiers. This can be pretty ugly for the analog cable channels still carried as a legacy service. Mine look like crap because of all the digital services crammed into the cable bandwidth. I think the ultimate answer is FIOS, which scales to huge numbers of users, with the only conflict being access to the shared bandwidth of the switches and upstream links.
1. M2N-E Asus Motherboard + 1 Gbyte DDR2 + AMD X2 5000+ CPU with unlocked clock multiplier. No Graphics card.
2. Antec Nine Hundred case with 450 watt energy efficient PS. 6 Seagate Sata2 500 GB disk drives.
3. APC backup unit with 1000+VA, like the XS1200. APC is the preferred brand, since driver install is easy.
Assemble hardware, and temporarily install a DVD-ROM, keyboard, and graphics card for installation of Ubuntu server. I've used 6.10, 7.04, and 7.10 successfully. Boot your favorite version of alternate install CD of Ubuntu AMD64 server and install it, after partitioning all the disks with small partitions of 1024 cylinders as partition 1, and the rest of the disk as partition 2. Then create RAID1 arrays on partition 1 (partition type FD) of disks A & B, and another RAID1 array on disks C & D. Partition 1 of disk E is a swap partition, and partition 1 of disk F is spare. After creation of the RAID1 array on A & B as /dev/md0, then use this for the root mount point. /dev/md1 on C & D can be used in the future for upgrading to newer releases without having to trash the original on /dev/md0. I don't bother with a LAMP installation, since I want pure file services. I do add DHCP, TFTP, SSH, NFS, and Samba services either during the installation, or after. After a successful install and reboot, then modify the grub menu to set up a serial console. http://www.howtoforge.com/setting_up_a_serial_console
Yank out the DVD, graphics card and keyboard, hook up a serial cable, and verify that it reboots with output directed to the serial port. The whole point of making the server headless is to remove all temptation to run an X-Server on the machine. This way lies madness and disk corruption. Preservation of the data takes precedence over convenience. You can do everything you need via SSH, or in a pinch, with the serial port. After beheading the machine, I usually continue configuration via SSH from another box on the network. Next, create a RAID6 array on the 6 disks using the 2nd partitions, which will give you a little under 2TB of usable storage. RAID6 may seem a bit of overkill, but RAID5 arrays usually have their moment of truth during a rebuild after a drive failure, and this is when unreadable sectors usually rise up and bite you very hard. With Raid6, you still have a margin of error after a disk failure, and we all know it's not a matter of if, but when.
Now install loop-AES. This always requires a build from source code, and instructions can be found on the ubuntu forums . Loop-AES is more complex to install than LUKS, or other linux disk encryption schemes, but the performance and security are the best available. This is why the OS should be in 64 bit mode, since this gives a little faster speed to the AES256 encryption. Creation of a suitable encryption key is covered elsewhere, but I strongly recommend 65 keys, a good random salt value, and a high iteration count on "losetup". I use an iteration count of 2,000,000, which takes about 2 minutes for the CPU to perform. The keyfile & salt value should be stored on an separate USB key, stored in an encrypted filesystem with a different salt value, a high iteration count, and a 20 character strong password. This combination is military grade, and places the weak link of the security chain squarely in your head. In other words, your password and the USB key become the only possible method for recovering your data, so making copies of the USB key is strongly recommended. I keep a copy at the bank, in a deposit box, as well as
For those with a cryonics contract, the cryonics provider is more than happy to take delivery of a hard disk or 2 along with your cooling corpse. It will help quite a lot in reconstruction of your synaptic pathways if a lot of side data is available to cross-correlate and verify information extracted from destructive nanoscanning of the vitrified brain. In other words... GUARD YOUR DATA. Unless you want to be dead, buried, and forgotten, like billions of people before you. How boring. I myself carry a digital camera and voice recorder 24/7, and am accumulating about 40 Gbytes/year of personal data. I don't plan on forgetting who I was, or used to be. Encryption, of course, is required to keep my identity from being distributed widely, so a balance has to be made between security and safety. I had a rather nasty accident with an AES256 key earlier this year and lost 2 months of my life, along with some neat photo's and recordings. Oh well, live and learn.
I'll tackle this answer, since I'm fairly qualified to answer. FPGA's very typically run at clock rates of 100 to 300 MHz. You might see 100 MHz rates done by beginners or sloppy ASIC coders, and 300 MHz by experienced designers who spend extra timing making sure there are enough pipeline registers. The *highest* speeds I've seen are around 650 MHz, and these only occur in extremely specialized circuits designed at a very low level by guys with Godlike powers of intuition and creativity (& patience!). Next year, you can multiply these figures by 30 or 40 percent. These speeds are far lower than your typical Athlon or Pentium, but with enough parallization and pipelining, you can actually far outperform them. But, as you've no doubt read, it's HARD. Tools are getting better, but it will be a while before you can get Borland tools for FPGA design.
And to answer the unspoken question: Can FPGA's be used in your brain? I say this: Get Real. Current FPGA technology has no possible application. Maybe in 5 or 10 years, when we have conquered the leakage problem, and have developed fuel cells that run on glucose. But I don't see it, since an ASIC dedicated to brain interface functions will be a far superior solution. FPGA's may evolve into a future computing fabric, so they may have useful applications in external hardware, but it will be a very distant descendent of FPGA's that are finally used for in-body implants.
I've been avidly following all the editorials, stories, commentaries, and blogs since Columbia was destroyed last week, and I have yet to see any writer to put their finger on the basic problem with manned spaceflight.
I'll put it in words for you: Humans don't belong in outer space. Lest I be accused of some sort of retro Luddite philosophy, let me clarify the foundation of that statement. Humans evolved on the African plains millions of years ago, and have admirable survival traits for all sorts of circumstances that can be found on this planet. But we don't live (normally) in Antarctica, nor do we live in the ocean. It's the wrong environment. Trying to export an earthlike environment to the rest of the solar system is not only stupid, it's doomed to failure.
So what's the answer? Let's think of it in terms of ecological niches, shall we? What sort of animal can you design to survive and flourish in the Oort cloud? First of all, normal body temperature should be only a few degrees above ambient (4.7K). Secondly, you need the ability to gather energy from the environment (solar radiation, fusion, etc...). Finally, and most importantly, you need the ability to survive the constant bombardment of hard radiation, high energy elementary particles, micrometeorites, and other random junk. This implies redundancy and regeneration on a nanoscale that is as yet unknown to our technology.
So what should we do? We should expand our unmanned space program dramatically (in particular, we *must* map all the potential "dinosaur-killer" near-earth asteroids), kill the manned space program, and concentrate on developing nanoscale technologies that will permit machine based AI's to survive the natural space environment. If you want to visit outer space, you'll have to upload yourself to a machine that's already there!
To recap, there is no point in trying to populate the galaxy with humans. It's the wrong ecological niche! On the other hand, there's nothing wrong in uploading human intelligences into machines that will explore the galaxy. Now that is a project that sounds interesting! But I can't help but wonder, has it been done already?
Step 2 will be the creation of software to analyze the raw data and create the associations and symbolic searchable representation. Step 3 will be the creation of an AI model of your mind, able to access your data and predict how you think. At about this point, a hardware link to your brain would be extremely useful so that you can directly access your personal data. Step 4 is the gradual creation of a hybrid AI composed partly of your brain and partly of the silicon running on your data. In step 5, you move all your computation to the silicon, and use the wetware just for amusement. What have you accomplished? A Moravec Transformation! Dont forget to send a Thank You note to Ray Kurzweil.
I have a few words to say about the various methods.
Schematics: OK for 1000 gate designs, but it scales very poorly to million gate devices.
Verilog: Easy to learn, simulates fast, can be scaled to very large designs, but it lacks OOP features, as well as hooks for attributes to easily implement EDIF properties that are so important for low level FPGA floorplanning. Some tools have pragmas that will let you floorplan, but it's pretty crude, since pragmas don't have any language hooks for doing loops or anything. You pretty much have to extend Verilog with a macro processor like VPP before it becomes practical for million gate high level ASIC design.
VHDL: Complex language, takes a while to learn, has some good OOP features, as well as the all important attribute which permits structural design equivalent to schematic level implementation. VHDL is slow to simulate and VHDL also suffers from crappy parsers, since most synthesis vendors don't support the full language (Mentor comes closest). I can synthesize sin(x) and cos(x) with only a single tool (Leonardo) at this point, since it is the only tool which really supports floating point calculation during elaboration. Even then, I have to convert the float (type Real) into integers to realize actual hardware. Because of the poor language support, many designers are looking for System-C, Handel-C, or JHDL to give them the higher level synthesis support. Most new internal IP development at Xilinx these days is being done with VHDL, since Verilog is such a bitch to parameterize and floorplan. Believe it or don't, but a lot of IP cores in our Coregen tool are done in Java. (The Java code creates a structural netlist, with optional floorplanning.) This seems to be more difficult that VHDL, so it's losing popularity lately. SystemC, Handel-C, JHDL can sort of be lumped together as high level simulatable structural methods that all share one feature. They don't have the hooks for low level FPGA design (like attributes), so fancy stuff is pretty tough.
Bottom Line: All design methods will be tossed in the meat grinder of the marketplace and the best will survive. Come back in 5 years to see what happened.