Fiber to the home is coming. From the reading in the Wired article and other places, I have been able to gether that the WIN system is specifically using a 100base-FX type ethernet technology to supply data connectivity to the home. These fiber drops get aggregated via ethernet switches, and eventually ATM switches. Voice and Data services go over the 100Mb fiber based Ethernet, with a separate coax cable laid in for cable TV. I would guess that while that last mile is 100Mb - the Internet connectivity is very over subscribed - so don't bet that it will improve web surfing much beyond what a good DSL or cable modem provides.
Fiber to the home really doesn't cost much more than doing new copper lines to a home. The cost of the cable when you buy it in multi-mile spools is about the same for fiber or copper. With fiber you do not have to put amplifiers or other electronics in the field - just at the side of the house and in the central office. This saves the provider money. The big cost of deploying any telecom infrastructure is the people leaning on the shovels burying the cable, and paying the city for the right-of-way to bury this cable. (or paying to put in aerial cable right-of-way).
SO - for those service providers who are putting in new infrastructure anyway - it makes a lot of sense to put in fiber. The cost is the same, and we know the bandwidth limitations of the copper. The bandwidth limitations of fiber are 1000 times higer.
Disclaimer - I work for a company that delivers Fiber-to-the-Home systems providing, Voice, Video, and Data over the same fiber. We are currently shipping systems to customers.
The big question to ask - are you looking for just a tool to manage versions of code or documents, or are you looking for a tool that helps with manageing builds, bug tracking, reproduceability of a version, etc.
CVS is great IMHO for file version management - if used by someone with a few brain cells to rub together. Dumb users can muck things up all too easily. (especially when stuck on Windoze platforms and needing to use shared file system reposititory instead of a proper server - )
Clearcase is my favorite for a Configuration Management tool. It costs lots of $. It also requires that someone become an expert in it to help those people who don't change their config files that often. Managing it also takes a little more work - but then the tool is probably doing more than CVS anyways. Lots of people complain about the management overhead of Clearcase. The problem is either an imcompetent clearcase manager (been there) or they expect to get a lot more functionality with zero additional management (done that).
First off go to LightReading.com to get some general information on this technology arena.
Corvis's switch is an all-optical switch. No eletrical regeneration involved. What it is switching is wavelengths of light. NOT packets. So, you can take a wavelength of light from one fiber and send it out another. This allows you to set up 2.5Gbps (OC-48) circuits quickly.
What technology are they using - don't won't say. Almost all other people in this arena are basically splitting the dense-wave-division-multiplexed (DWDM) circuits into their individual wavelengths. Then routing them through micro-mirrors. The micro-mirrors allow you to connect any two fibers together optically. Then, the outputs from this are re-combined, optically amplified and transmitted.
This isn't for sure what Corvis is doing - but I would bet money that this is basically what they are doing.
One problem with this is that you can't have two circuits on a fiber using the same wavelength of light. So, you would need something that shifts the wavelength of light being used. Nobody that I know of has a commercial product to do this.
Cisco doesn't buy or own component manufacturers. Therefore - this would not be someone Cisco would buy.
As it looks, this is a hot chip and if 1/2 of the claims on the "data sheet" come true it will be a nice tool. However, that "data sheet" isn't much yet. A real data sheet for this chip should push 800 pages.
A while ago I also looked for something like this. My biggest problem was that I normally use a POP client to retrieve my email. However, when I am on the road, about all I can guarentee is that I can get at a web browser. Many windoze kioske type machines don't have a telnet client installed;-(
So - does anyone know if any of these packages use the local spool and allow for quick browsing of messages there so that when I get home and start up my pop client it can just get the email normally?
Re-wiring households with fiber is NOT too expensive. There are several companies out there that are deploying fiber-to-the-home equipment right now.
The cost of the actual fiber in the ground is about the same as copper lines. Actually the cost of the cable is almost nothing compared to the cost of installing it. Because trenching new cable into neighborhoods is the biggest cost, don't expect to see this in your mid-life neighborhoods any time soon. Do expect to see it in new subdivisions, and older neighborhoods that are moving from telephone poles to below-ground installations. Since they are already running the DitchWitch in those neighborhoods, they might as well put in fiber, because then they don't have to come and do an upgrade in 10 years, AND they can sell the subscribers a lot more services right now.
As far as the equipment goes - the most expensive part is those lasers and optical receivers. As we all know - the electronics that hook up to them keep getting cheaper and cheaper.
The bandwidth that a Fiber-to-the-home network gives you is incredible. I believe that this will be a disruptive technology in that the big jump in access bandwidth (100x over most cable-modem or DSL technology) will transform the net.
Disclaimer - my company makes Fiber-to-the-home equipment and the options I have are worth crap if this is all false.
My worst project experience was with a contract company just down the street. I wouldn't want to think what it would be if they were half-way around the globe.
The biggest problem we ran into was that everything had to be spelled out in the utmost detail. The spec was several hundred pages, and even then they twisted things around and did things in complex ways, seemingly just because the spec didn't say that they couldn't. Of course every change or clarification to the spec had to be approved by managers and accountants on both ends, and resulted in charges more than the original contract.
If you can come up with a design document that has EVERY detail spelled out, and nothing in the system is unknown and nothing will change, then you might have a chance. Otherwise - you are in for one heck of a ride. Of course any software developer that has much experience will tell you that every system has changing requirements as it is being developed. So, you are pretty much screwed.
From the message this sounds like a web server to support personal web pages at a university. Based on that, you can bet that a large percentage (most?) of the people will not use the space at all. Some small number will use the maximum of their quota (whatever that number is) and a bunch will put up just 1-2MB of stuff.
My swag would be that *maybe* 1/10th of the 2TB of theoretical maximum would be used. 200GB of storage is doable on a good server, with simple backup strategies, etc.
As for the Web server - I would bet that a single well-tuned machine (of the PC make) could do a reasonable job, assuming that no user has really nasty CGI scripts running. Yeah - it would slow down at peak times, but hey - it's a freebie for the students. You might saturate the uplink before the server.
It will take some system admin time on an ongoing basis to monitor performance and slap those students that run nasty CGI scripts that chew up lots of CPU time. That requires a carefully written user policy that basically states you can do stuff, but you can't hog the CPU. Then it also requires a system admin that can be a BOFH to clue in the lusers that need to be helped out. The need for maintenace is probably a greater cost than the actual hardware.
Fiber is not *that* expensive. Single mode fiber in large quanities is about $0.025 / foot / fiber (US $) if you have 36 or more fibers per cable. If you get down to having 6 fibers per cable then it is about $0.067/foot/fiber or $0.40/foot for the cable of six fibers.
That is all for single mode fiber - i.e. the expensive stuff, but in large phone company size spools. It is also unterminated. Unfortunately, putting the connectors on the end of the fibers is often more expensive than the fiber itself.
For another datapoint - a quick look at the warehouse.com catalog I have laying on my desk. Bulk multimode cable - cost is about $0.33/foot/2 fiber cable. This isn't much different from what they have for plenum Cat 5E cable.
All that being said - I don't know of anyone who has serious amount of fiber in their house. The cable isn't that much more expensive, but the equipment you hook it up to is. Besides - what in a normal home would drive 100Mb ethernet hard, much less require higher speeds.
Technically, your DSL modem is a modem. With DSL, the IP packets are converted to ATM cells, and then the DSL modem modulates the 1's and 0's into frequencies that are outside of the normal voice bandwidth.
Yup - I was the one that mentioned constrained memory and CPU. I agree that on new designs that memory and CPU are not nearly as constrained as they used to be because they have gotten cheap. Heck - memory for a Linux desktop is not nearly as constrained as it was back in the 0.99pxx days.;-) If you get deep embedded, then you might be limited to RAM embedded on the micro (256 bytes maybe). Also it isn't uncommon to be working on updates to that 15 year old design with the 10Mhz CPU and fixed memory size.
A long compile/test/fix cycle is also not uncommon. That is probably the one thing that I hammer on the most to try and reduce. Unix machiens that easily allow distributed builds are your friend. An ethernet port that is only on the lab boards is also another friend for speedy download. Burning PROMs is a pain in the *ss - but sometimes a necessary evil.
While I am currently pushing for using Linux on some of our next generation of products where I work, Linux as an embedded OS is not the answer to all problems. We have systems in developement that use both 8 bit and 16 bit CPUs with very limited memory footprints (10's of Kbytes). In once case there is no embedded OS - just a big loop and the entire executable is less than 20k in size.
In the embedded world - VxWorks is currently the most popular OS. Behind that is pSOS. Both are now owned by Wind River. Both also cost big bucks to get into. ($2k+) Although I seem to remember a big educational discount being offered - look here for more info: http://www.windriver.com/grad/
Learning on the cheap - embedded Linux is probably as good as anything because of the price.
Below are the biggest differences I see in programing "style" between a normal application on a normal OS and an embedded application.
1) You do not normally have access to a gui, or sometimes even a normal console. There may be a serial port, but it may be consumed communicating a specialized command line language.
2) Memory and CPU power are tight. Typically more of both of those add cost to the final product, and also add power consumption - both of which are limited in an embedded system. Making do with less is normal. Because of this, lots of dynamic allocation of memory is usally a no-no. Fragmented memory can't be easily cleaned up with a reboot.
3) Most embedded OS's do NOT do memory protection or virutal memory. The RAM you have is all that you have. If you aren't careful - you write on another task/thread/process address space and mess everything up.
4) It is usually a closed system. This means that you don't have some of the worries of having to run hostile applications. After all - you don't load new applications into your anti-lock brake controller do you? This unfortunately means that some designers take shortcuts that lead to future problems.
5) Real time aspects. Many (most?) embedded applications have some real time constraints. Some applications are more hard real time than others. i.e. a pacemaker had better deliver the pulse at EXACTLY the right moment +/- micro-seconds where a router might have milliseconds to make a decision on some things, and maybe seconds to handle routing updates. Fortuanately many embedded applications have a few hard real time constraints and then a lot of management code that is less constrained in it's real time requirements.
6) Crashing is not an option in most cases. If you've ever worked with someone coming from the Windoze world of programming into embedded world they have a hard time understanding that when you reboot you take down telephone service (and 911) and this is a "bad thing". Anything that can be possibly done on the fly without affecting the operation of the system is done that way. This includes software upgrades.
7) You debug on a system that is different than where you do your editing, compiling, etc. There is a little different mindset when every time you change and compile you also have to download to a target system. Also means that you get to read a different assembly language sometimes.
8) You interface with devices. This might be a motor, a switch, an LED. The motor won't turn on the instant you hit the bit to turn it on. The switch will need to be debounced. You can't see the LED flash when you pulse it for only a few clock cycles. All these things present unique challenges. These real devices can be fun and dangerous. Ask my friend you recently let the reset line on his board touch a 100V line on the power supply..... smoke;-)
If you are looking to do a real embedded project - look at some of the robot contests out there. There are some relatively inexpensive evaluation boards that can be used to control remote control cars, or other robotic thingys. Going this route will almost undoubtably mean that you end up with a 8 or 16 bit CPU and a bunch of "real world" things to interface with. It will get a pure software geek to get their hands dirty with the hardware.
As you said - speed isn't as much of an issue as latency.
A nit to pick though is that ATM is *not* based on a 125uSec frame. ATM by itself does not have a frame rate. An ATM cell with a (common) payload of 40 bytes of voice traffic will have a packetization delay of 5 mSec. That's 1 byte per 125uSec as in 8000 bytes/sec or 64000 bits/sec. Yes, there are 48 bytes of payload per ATM cell - but the AAL layer can take one or more bytes, and then you also have some systems that just don't fully fill the cells (like voice-over-ATM) to reduce latency. To get bigger packets you have more delay.
You also have delay from the fact that once you have a packet you need to send it over the line. A 60 byte packet over a 56k modem line takes about 8.5 mSec to transmit. You add up a few more of these serialization delays and you have a BUNCH of latency. Not tolerable for a normal phone call.
A 9mm shouldn't have much problem bringing down a deer. You say no - then why did the 8mm I used last year worked just fine killing 2 deer each at about 150 yards. That was with open sights, and I don't want to admit how many shots I missed with. This year with the scope I was at much higher accuracy.
The size of the lead coming out of the barrel doesn't mean as much as the weight of the lead, and the speed it travels at. Remember physics (which is always y2k compliant) and E = m * v * v Engergy = Mass * Velocity squared. The amount of energy that is transfered to the animal (or man) is more telling of it's stopping power. If you catch a rib or the sholder of the animal, much (most) of the engergy goes into that animal and is usually translated into tearing up of the inards. So, a fast moving bullet is a good thing.
The size of the round does affect the amount of air resistance and therefore how quickly the bullet loses energy, so it is nice to have smaller caliber rounds for long range (200+ yards) shooting. Heck - a shotgun with slugs isn't that bad to 75 or 100 yards.
If you are going to talk about how and why corn is planted - please get your facts straight.
Yes - very few farmers use what they grow as seed for the next year. BUT it is not the storage costs. After you get corn dried down to about 20% moisture, you don't need expensive propane driers, etc. Just a cool (but not freezing) dry location.
Farmers don't replant what they grow because you don't get as strong of plants that way. Go back to basic genetics. To get a "super" plant you take two inbred lines, and then cross them to get a hybrid. This hybrid has "hybrid vigor" which makes it MUCH stronger and higher yielding than either of its parents.
Seed corn companies produce various varieties of inbred lines by growing corn that polinates itself for many generations. Then they plant the two inbreds in the same field. The one inbred is designated the female and so has it's male parts (the tassle) removed. The other inbred is designated the male and left alone. Wind (and sometimes helicopter generated wind) spread the pollen from the male plants tassle to the female plants ears of corn. This gives you the genetic cross or hybrid.
If the farmer was to replant his own corn, he would be planting an inbred line again and each generation would result in lower and lower yields. Obviously this doesn't make sense. However to get a good genetic hybrid takes a lot of high-school kids walking through fields removing tassles and specialized knowledge on which inbreds to cross etc. This specialized skill and knowlege and economies of scale are why companies like Pioneer specialize in producing the seed for farmers.
Monsanto has high prices for some of their agricultural chemicals because of the patents they have on them. But, these chemicals work well and farmers are pay the price for them because they allow them to get higher yields. People can (and a few do) farm without them, but their yeild is reduced so much that they loose more money than they would have paid for the chemicals. It is the free market - with a little patent protection.
While another interesting tidbit is that Motorola expects to continuing making G4s even with the introduction of the G5 and G6-embedded chips perhaps?
Motorola has been very good to embedded designers in making chips for a very long time. 10+ years.
Heck - where I work still uses a bunch of HC11's.
This is one reason that the 68k line of processors has been so popular in embedded systems. Not to mention the nifty stuff that Motorola tends to glue together with the CPU all into one chip. This is the reason you will probably still be using PowerPC products 10 years from now - even if you don't realize what that CPU is under the cover of your TV.
But - the Old MI/X stuff is X11-R5.x not X11-R6. This makes it pretty much worthless for many things that are compiled against and use X11-R6 features.
I *love* cygwin - it keeps me somewhat sane when I have to use windoze machines. I haven't tried playing with it, but some people are working on a port of xfree86 to cygwin. It is still very much a work in progress, so this is only for people not afraid to get their hands dirty in code. You can get to the mailing list archive for porting xfree86 to cygwin at:
The volume is pretty low and from the messages there, you can find the pointers to the tar ball, etc. Once this works, it will be an excellent alternative to the expensive x-servers for Windoze machines.
OpenMail may be fine if the corporate powers that be demand that you use X.400 crud.
My experience at my former empolyer (Alcatel - Richardson, USA) was that the OpenMail server was constantly being rebooted and down for a day or more at a time. Those rebels in R&D had Sun workstations running sendmail on their desktop. Not once in several years do I remember email for the R&D people being down.
It was great fun to laugh at those outside of R&D that had to depend on OpenMail.
Anyone who has used a line-of-sight optical system for doing a T1 or something similar knows that this won't work worth crap in a lot of typical outdoor situations.
I see a couple of good applications.
1) Get the bandwidth up today while you get the trencher out to bury your fiber.
2) Replace the bandwidth today after somebody else cut through your cable trenching in their fiber;-)
3) Use it indoors. Large convention centers could use a couple of these puppies to move lots of data around where fiber runs might not be pratical. Also think of Boeing's assembly plant. VERY large building with pretty decent sight lines without weather problems.
In general though - this is only going to be useful to a far smaller number of people than would use a traditional fibered system.
No - not OC-768. What they have is 10Gbps which is OC-192.
But - what they actualy have is 4 OC-48 links. Each OC-48 link is 2.5Gbps (really 2.488 - but close enough) and they use 4 different wavelengths of light.
Slashdot Mirror
Fiber to the home is coming. From the reading in the Wired article and other places, I have been able to gether that the WIN system is specifically using a 100base-FX type ethernet technology to supply data connectivity to the home. These fiber drops get aggregated via ethernet switches, and eventually ATM switches. Voice and Data services go over the 100Mb fiber based Ethernet, with a separate coax cable laid in for cable TV. I would guess that while that last mile is 100Mb - the Internet connectivity is very over subscribed - so don't bet that it will improve web surfing much beyond what a good DSL or cable modem provides.
Fiber to the home really doesn't cost much more than doing new copper lines to a home. The cost of the cable when you buy it in multi-mile spools is about the same for fiber or copper. With fiber you do not have to put amplifiers or other electronics in the field - just at the side of the house and in the central office. This saves the provider money. The big cost of deploying any telecom infrastructure is the people leaning on the shovels burying the cable, and paying the city for the right-of-way to bury this cable. (or paying to put in aerial cable right-of-way).
SO - for those service providers who are putting in new infrastructure anyway - it makes a lot of sense to put in fiber. The cost is the same, and we know the bandwidth limitations of the copper. The bandwidth limitations of fiber are 1000 times higer.
Disclaimer - I work for a company that delivers Fiber-to-the-Home systems providing, Voice, Video, and Data over the same fiber. We are currently shipping systems to customers.
The big question to ask - are you looking for just a tool to manage versions of code or documents, or are you looking for a tool that helps with manageing builds, bug tracking, reproduceability of a version, etc.
CVS is great IMHO for file version management - if used by someone with a few brain cells to rub together. Dumb users can muck things up all too easily. (especially when stuck on Windoze platforms and needing to use shared file system reposititory instead of a proper server - )
Clearcase is my favorite for a Configuration Management tool. It costs lots of $. It also requires that someone become an expert in it to help those people who don't change their config files that often. Managing it also takes a little more work - but then the tool is probably doing more than CVS anyways. Lots of people complain about the management overhead of Clearcase. The problem is either an imcompetent clearcase manager (been there) or they expect to get a lot more functionality with zero additional management (done that).
Corvis's switch is an all-optical switch. No eletrical regeneration involved. What it is switching is wavelengths of light. NOT packets. So, you can take a wavelength of light from one fiber and send it out another. This allows you to set up 2.5Gbps (OC-48) circuits quickly.
What technology are they using - don't won't say. Almost all other people in this arena are basically splitting the dense-wave-division-multiplexed (DWDM) circuits into their individual wavelengths. Then routing them through micro-mirrors. The micro-mirrors allow you to connect any two fibers together optically. Then, the outputs from this are re-combined, optically amplified and transmitted.
This isn't for sure what Corvis is doing - but I would bet money that this is basically what they are doing.
One problem with this is that you can't have two circuits on a fiber using the same wavelength of light. So, you would need something that shifts the wavelength of light being used. Nobody that I know of has a commercial product to do this.
Press blurb about this particular thing is available in a Light Reading article.
A couple of weeks ago, Corvis announced that they had revenue - from this shipment of course.
One more link - Some hints to what technology they are using.
Cisco doesn't buy or own component manufacturers. Therefore - this would not be someone Cisco would buy.
As it looks, this is a hot chip and if 1/2 of the claims on the "data sheet" come true it will be a nice tool. However, that "data sheet" isn't much yet. A real data sheet for this chip should push 800 pages.
Big time vaporware at this time.
A while ago I also looked for something like this. My biggest problem was that I normally use a POP client to retrieve my email. However, when I am on the road, about all I can guarentee is that I can get at a web browser. Many windoze kioske type machines don't have a telnet client installed ;-(
So - does anyone know if any of these packages use the local spool and allow for quick browsing of messages there so that when I get home and start up my pop client it can just get the email normally?
Re-wiring households with fiber is NOT too expensive. There are several companies out there that are deploying fiber-to-the-home equipment right now.
The cost of the actual fiber in the ground is about the same as copper lines. Actually the cost of the cable is almost nothing compared to the cost of installing it. Because trenching new cable into neighborhoods is the biggest cost, don't expect to see this in your mid-life neighborhoods any time soon. Do expect to see it in new subdivisions, and older neighborhoods that are moving from telephone poles to below-ground installations. Since they are already running the DitchWitch in those neighborhoods, they might as well put in fiber, because then they don't have to come and do an upgrade in 10 years, AND they can sell the subscribers a lot more services right now.
As far as the equipment goes - the most expensive part is those lasers and optical receivers. As we all know - the electronics that hook up to them keep getting cheaper and cheaper.
The bandwidth that a Fiber-to-the-home network gives you is incredible. I believe that this will be a disruptive technology in that the big jump in access bandwidth (100x over most cable-modem or DSL technology) will transform the net.
Disclaimer - my company makes Fiber-to-the-home equipment and the options I have are worth crap if this is all false.
My worst project experience was with a contract company just down the street. I wouldn't want to think what it would be if they were half-way around the globe.
The biggest problem we ran into was that everything had to be spelled out in the utmost detail. The spec was several hundred pages, and even then they twisted things around and did things in complex ways, seemingly just because the spec didn't say that they couldn't. Of course every change or clarification to the spec had to be approved by managers and accountants on both ends, and resulted in charges more than the original contract.
If you can come up with a design document that has EVERY detail spelled out, and nothing in the system is unknown and nothing will change, then you might have a chance. Otherwise - you are in for one heck of a ride. Of course any software developer that has much experience will tell you that every system has changing requirements as it is being developed. So, you are pretty much screwed.
Bob Lewis of InfoWorld has a good column on this topic at: http://www.infoworld.com/articles/op/xml/00/09/04/ 000904oplewis.xml
Basically, it says that if you are an older worker and complaining that you can't find a job - look for the problem in the mirror.
From the message this sounds like a web server to support personal web pages at a university. Based on that, you can bet that a large percentage (most?) of the people will not use the space at all. Some small number will use the maximum of their quota (whatever that number is) and a bunch will put up just 1-2MB of stuff.
My swag would be that *maybe* 1/10th of the 2TB of theoretical maximum would be used. 200GB of storage is doable on a good server, with simple backup strategies, etc.
As for the Web server - I would bet that a single well-tuned machine (of the PC make) could do a reasonable job, assuming that no user has really nasty CGI scripts running. Yeah - it would slow down at peak times, but hey - it's a freebie for the students. You might saturate the uplink before the server.
It will take some system admin time on an ongoing basis to monitor performance and slap those students that run nasty CGI scripts that chew up lots of CPU time. That requires a carefully written user policy that basically states you can do stuff, but you can't hog the CPU. Then it also requires a system admin that can be a BOFH to clue in the lusers that need to be helped out. The need for maintenace is probably a greater cost than the actual hardware.
Fiber is not *that* expensive. Single mode fiber in large quanities is about $0.025 / foot / fiber (US $) if you have 36 or more fibers per cable. If you get down to having 6 fibers per cable then it is about $0.067 /foot/fiber or $0.40/foot for the cable of six fibers.
That is all for single mode fiber - i.e. the expensive stuff, but in large phone company size spools. It is also unterminated. Unfortunately, putting the connectors on the end of the fibers is often more expensive than the fiber itself.
For another datapoint - a quick look at the warehouse.com catalog I have laying on my desk. Bulk multimode cable - cost is about $0.33/foot/2 fiber cable. This isn't much different from what they have for plenum Cat 5E cable.
All that being said - I don't know of anyone who has serious amount of fiber in their house. The cable isn't that much more expensive, but the equipment you hook it up to is. Besides - what in a normal home would drive 100Mb ethernet hard, much less require higher speeds.
Bzzzt.
Technically, your DSL modem is a modem. With DSL, the IP packets are converted to ATM cells, and then the DSL modem modulates the 1's and 0's into frequencies that are outside of the normal voice bandwidth.
Yup - I was the one that mentioned constrained memory and CPU. I agree that on new designs that memory and CPU are not nearly as constrained as they used to be because they have gotten cheap. Heck - memory for a Linux desktop is not nearly as constrained as it was back in the 0.99pxx days. ;-) If you get deep embedded, then you might be limited to RAM embedded on the micro (256 bytes maybe). Also it isn't uncommon to be working on updates to that 15 year old design with the 10Mhz CPU and fixed memory size.
A long compile/test/fix cycle is also not uncommon. That is probably the one thing that I hammer on the most to try and reduce. Unix machiens that easily allow distributed builds are your friend. An ethernet port that is only on the lab boards is also another friend for speedy download. Burning PROMs is a pain in the *ss - but sometimes a necessary evil.
While I am currently pushing for using Linux on some of our next generation of products where I work, Linux as an embedded OS is not the answer to all problems. We have systems in developement that use both 8 bit and 16 bit CPUs with very limited memory footprints (10's of Kbytes). In once case there is no embedded OS - just a big loop and the entire executable is less than 20k in size.
;-)
In the embedded world - VxWorks is currently the most popular OS. Behind that is pSOS. Both are now owned by Wind River. Both also cost big bucks to get into. ($2k+) Although I seem to remember a big educational discount being offered - look here for more info: http://www.windriver.com/grad/
Learning on the cheap - embedded Linux is probably as good as anything because of the price.
Below are the biggest differences I see in programing "style" between a normal application on a normal OS and an embedded application.
1) You do not normally have access to a gui, or sometimes even a normal console. There may be a serial port, but it may be consumed communicating a specialized command line language.
2) Memory and CPU power are tight. Typically more of both of those add cost to the final product, and also add power consumption - both of which are limited in an embedded system. Making do with less is normal. Because of this, lots of dynamic allocation of memory is usally a no-no. Fragmented memory can't be easily cleaned up with a reboot.
3) Most embedded OS's do NOT do memory protection or virutal memory. The RAM you have is all that you have. If you aren't careful - you write on another task/thread/process address space and mess everything up.
4) It is usually a closed system. This means that you don't have some of the worries of having to run hostile applications. After all - you don't load new applications into your anti-lock brake controller do you? This unfortunately means that some designers take shortcuts that lead to future problems.
5) Real time aspects. Many (most?) embedded applications have some real time constraints. Some applications are more hard real time than others. i.e. a pacemaker had better deliver the pulse at EXACTLY the right moment +/- micro-seconds where a router might have milliseconds to make a decision on some things, and maybe seconds to handle routing updates. Fortuanately many embedded applications have a few hard real time constraints and then a lot of management code that is less constrained in it's real time requirements.
6) Crashing is not an option in most cases. If you've ever worked with someone coming from the Windoze world of programming into embedded world they have a hard time understanding that when you reboot you take down telephone service (and 911) and this is a "bad thing". Anything that can be possibly done on the fly without affecting the operation of the system is done that way. This includes software upgrades.
7) You debug on a system that is different than where you do your editing, compiling, etc. There is a little different mindset when every time you change and compile you also have to download to a target system. Also means that you get to read a different assembly language sometimes.
8) You interface with devices. This might be a motor, a switch, an LED. The motor won't turn on the instant you hit the bit to turn it on. The switch will need to be debounced. You can't see the LED flash when you pulse it for only a few clock cycles. All these things present unique challenges. These real devices can be fun and dangerous. Ask my friend you recently let the reset line on his board touch a 100V line on the power supply..... smoke
If you are looking to do a real embedded project - look at some of the robot contests out there. There are some relatively inexpensive evaluation boards that can be used to control remote control cars, or other robotic thingys. Going this route will almost undoubtably mean that you end up with a 8 or 16 bit CPU and a bunch of "real world" things to interface with. It will get a pure software geek to get their hands dirty with the hardware.
As you said - speed isn't as much of an issue as latency.
A nit to pick though is that ATM is *not* based on a 125uSec frame. ATM by itself does not have a frame rate. An ATM cell with a (common) payload of 40 bytes of voice traffic will have a packetization delay of 5 mSec. That's 1 byte per 125uSec as in 8000 bytes/sec or 64000 bits/sec. Yes, there are 48 bytes of payload per ATM cell - but the AAL layer can take one or more bytes, and then you also have some systems that just don't fully fill the cells (like voice-over-ATM) to reduce latency. To get bigger packets you have more delay.
You also have delay from the fact that once you have a packet you need to send it over the line. A 60 byte packet over a 56k modem line takes about 8.5 mSec to transmit. You add up a few more of these serialization delays and you have a BUNCH of latency. Not tolerable for a normal phone call.
Amen Russ!
A 9mm shouldn't have much problem bringing down a deer. You say no - then why did the 8mm I used last year worked just fine killing 2 deer each at about 150 yards. That was with open sights, and I don't want to admit how many shots I missed with. This year with the scope I was at much higher accuracy.
The size of the lead coming out of the barrel doesn't mean as much as the weight of the lead, and the speed it travels at. Remember physics (which is always y2k compliant) and E = m * v * v
Engergy = Mass * Velocity squared.
The amount of energy that is transfered to the animal (or man) is more telling of it's stopping power. If you catch a rib or the sholder of the animal, much (most) of the engergy goes into that animal and is usually translated into tearing up of the inards. So, a fast moving bullet is a good thing.
The size of the round does affect the amount of air resistance and therefore how quickly the bullet loses energy, so it is nice to have smaller caliber rounds for long range (200+ yards) shooting. Heck - a shotgun with slugs isn't that bad to 75 or 100 yards.
If you are going to talk about how and why corn is planted - please get your facts straight.
Yes - very few farmers use what they grow as seed for the next year. BUT it is not the storage costs. After you get corn dried down to about 20% moisture, you don't need expensive propane driers, etc. Just a cool (but not freezing) dry location.
Farmers don't replant what they grow because you don't get as strong of plants that way. Go back to basic genetics. To get a "super" plant you take two inbred lines, and then cross them to get a hybrid. This hybrid has "hybrid vigor" which makes it MUCH stronger and higher yielding than either of its parents.
Seed corn companies produce various varieties of inbred lines by growing corn that polinates itself for many generations. Then they plant the two inbreds in the same field. The one inbred is designated the female and so has it's male parts (the tassle) removed. The other inbred is designated the male and left alone. Wind (and sometimes helicopter generated wind) spread the pollen from the male plants tassle to the female plants ears of corn. This gives you the genetic cross or hybrid.
If the farmer was to replant his own corn, he would be planting an inbred line again and each generation would result in lower and lower yields. Obviously this doesn't make sense. However to get a good genetic hybrid takes a lot of high-school kids walking through fields removing tassles and specialized knowledge on which inbreds to cross etc. This specialized skill and knowlege and economies of scale are why companies like Pioneer specialize in producing the seed for farmers.
Monsanto has high prices for some of their agricultural chemicals because of the patents they have on them. But, these chemicals work well and farmers are pay the price for them because they allow them to get higher yields. People can (and a few do) farm without them, but their yeild is reduced so much that they loose more money than they would have paid for the chemicals. It is the free market - with a little patent protection.
While another interesting tidbit is that Motorola expects to continuing making G4s even with the introduction of the G5 and G6-embedded chips perhaps?
Motorola has been very good to embedded designers in making chips for a very long time. 10+ years.
Heck - where I work still uses a bunch of HC11's.
This is one reason that the 68k line of processors has been so popular in embedded systems. Not to mention the nifty stuff that Motorola tends to glue together with the CPU all into one chip. This is the reason you will probably still be using PowerPC products 10 years from now - even if you don't realize what that CPU is under the cover of your TV.
But - the Old MI/X stuff is X11-R5.x not
X11-R6. This makes it pretty much worthless for many things that are compiled against and use X11-R6 features.
The MIX Server is X11-R5.something
Not very useful if you are trying to use apps
written against X11-R6.x libraries.
I haven't tried playing with it, but some people are working on a port of xfree86 to cygwin. It is still very much a work in progress, so this is only for people not afraid to get their hands dirty in code.
You can get to the mailing list archive for porting xfree86 to cygwin at:
The volume is pretty low and from the messages there, you can find the pointers to the tar ball, etc.
Once this works, it will be an excellent alternative to the expensive x-servers for Windoze machines.
OpenMail may be fine if the corporate powers that be demand that you use X.400 crud.
My experience at my former empolyer (Alcatel - Richardson, USA) was that the OpenMail server was constantly being rebooted and down for a day or more at a time. Those rebels in R&D had Sun workstations running sendmail on their desktop. Not once in several years do I remember email for the R&D people being down.
It was great fun to laugh at those outside of R&D that had to depend on OpenMail.
Anyone who has used a line-of-sight optical system for doing a T1 or something similar knows that this won't work worth crap in a lot of typical outdoor situations.
;-)
I see a couple of good applications.
1) Get the bandwidth up today while you get the trencher out to bury your fiber.
2) Replace the bandwidth today after somebody else cut through your cable trenching in their fiber
3) Use it indoors. Large convention centers could use a couple of these puppies to move lots of data around where fiber runs might not be pratical. Also think of Boeing's assembly plant. VERY large building with pretty decent sight lines without weather problems.
In general though - this is only going to be useful to a far smaller number of people than would use a traditional fibered system.
No - not OC-768. What they have is 10Gbps which is OC-192.
But - what they actualy have is 4 OC-48 links.
Each OC-48 link is 2.5Gbps (really 2.488 - but close enough) and they use 4 different wavelengths of light.
Note that it is a 100mb *interface*.
So - they put a 10/100 ethernet interface on their box - big deal. What I really want to know is how much up/down bandwidth is available.
I'm guessing that it is basically a cable modem in
disguise.