Re: FreeBSD and Robotics
On Sun, Jun 17, 2007 at 10:38:54PM -0700, Ted Mittelstaedt wrote: There's another issue and that is POST on standard PC hardware. POST takes too long. For example the auto industry has agreed on a standard time that a car engine computer must be fully operational, it is very short, no more than something like 2 seconds or so. Enough so that when you turn the key and the engine starts cranking, that the engine computer has completely booted and is running by the second crank. That is why you probably will never see standard computer hardware used in the operating room of a hospital to control patient life support, for example. If for example during an operation the computer controlling an artificial heart suddenly dies, the staff simply unplugs the lines from the computer and plug them into another computer which then is switched on and within a second has come fully ready, and operating. You could not wait the 30-60 seconds that POST on a regular PC would take to complete. If it's taking 30-60 seconds just for your system to POST, there's something desperately wrong. My laptop gets all the way to a login prompt in that range. I think you mean boot, not POST -- where POST stands for Power On, Self-Test and refers to that brief period at the beginning of booting before the boot manager is loaded. You know, the part where there's a screen that says IBM or AMI or something like that. -- CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ] John W. Russell: People point. Sometimes that's just easier. They also use words. Sometimes that's just easier. For the same reasons that pointing has not made words obsolete, there will always be command lines. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Robotics
On Mon, Jun 18, 2007 at 01:32:21PM +1000, Murray Taylor wrote: I can only think of one other point for this... Interrupt latency. Depending on what you are attempting to do, the variable nature of interrupt responses could be an issue. I.e. if the system becomes io bound during a data capture cycle, and something occurs that requires a response within a very narrow window, it is possible to miss the window due to other interrupt processes running. For this reason, robotics systems often run on highly optimised single process systems where there is a 'guaranteed' poll cycle and / or a very minimal defined interrupt system with minimal overheads. I suspect that increasing concurrency capability in the near future will change that a fair bit. It'll probably start with highly concurrent embedded and realtime OS development (he said, wildly guessing) and seep out into other areas of computing from there. -- CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ] awj @reddit: The terms never and always are never always true. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: FreeBSD and Robotics
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Chad Perrin Sent: Monday, June 18, 2007 3:32 AM To: [EMAIL PROTECTED] Subject: Re: FreeBSD and Robotics and within a second has come fully ready, and operating. You could not wait the 30-60 seconds that POST on a regular PC would take to complete. If it's taking 30-60 seconds just for your system to POST, there's something desperately wrong. No, you just have the extended memory check disabled. Most BIOSes these days do, with an option to turn it back on. Go into bios setup and look for something called quick boot I've also seen bioses where even when the quickboot is disabled, it will only test ram once - when the machine is powered up. Successive reboots it will not do a through ram test, until the machine is de-powered and re-powered. My laptop gets all the way to a login prompt in that range. I think you mean boot, not POST -- where boot is also an issue - however, that can be shortened by reducing the number of drivers loaded by the system. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD and Robotics
I've read some really good things about FreeBSD, especially its virus resistance and reliability. Will FreeBSD work on a robot that has to be trusted in critical situations? Kevin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Robotics
It's only as good as the drivers you write to control the robot. It also depends on just how critical your critical situations refers to. In situations where human life is directly dependent upon the integrity of the system, a modular kernel design has traditionally been preferred over the monolithic kernel designs found in Windows, Linux, BSD. That isn't to say that FreeBSD is unstable, in fact it's very stable. However, in a situation where people die if the system fails, there are some questions as to the safety of the underlying designs of these kernels. The reason for this is, (in general), device drivers operate in the kernel's memory space and therefore have the potential to bring down the rest of the system, should they fail, (again, in general). In a modular kernel design, where everything is run in user-space, if a single driver goes berserk it is entirely insulated from the rest of the system. Then there are embedded systems, which are regarded as more stable because the hardware they run on is identical from one system to the next and never changes. Contrast this to operating systems that must run on a wide range of consumer hardware; there is a statistically higher probability of mistakes, just due to the increased size of the codebase. (In practice this doesn't always work out though, as I've used some embedded systems that were embarrassingly unstable). The smaller codebase of embedded systems and modular kernels is typically easier to audit, as there is far less code. Where human life is directly dependent, the code must be audited by a third party. For pretty much any other critical application, FreeBSD Release has been quite stable in my experience. Strip the kernel of everything you don't need, write good drivers and run it all on stable hardware and you should be fine in most situations. You'll probably go years between reboots. Just my 2 cents. -Modulok- On 6/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I've read some really good things about FreeBSD, especially its virus resistance and reliability. Will FreeBSD work on a robot that has to be trusted in critical situations? Kevin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: FreeBSD and Robotics
I can only think of one other point for this... Interrupt latency. Depending on what you are attempting to do, the variable nature of interrupt responses could be an issue. I.e. if the system becomes io bound during a data capture cycle, and something occurs that requires a response within a very narrow window, it is possible to miss the window due to other interrupt processes running. For this reason, robotics systems often run on highly optimised single process systems where there is a 'guaranteed' poll cycle and / or a very minimal defined interrupt system with minimal overheads. mjt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Modulok Sent: Monday, 18 June 2007 12:40 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: FreeBSD and Robotics It's only as good as the drivers you write to control the robot. It also depends on just how critical your critical situations refers to. In situations where human life is directly dependent upon the integrity of the system, a modular kernel design has traditionally been preferred over the monolithic kernel designs found in Windows, Linux, BSD. That isn't to say that FreeBSD is unstable, in fact it's very stable. However, in a situation where people die if the system fails, there are some questions as to the safety of the underlying designs of these kernels. The reason for this is, (in general), device drivers operate in the kernel's memory space and therefore have the potential to bring down the rest of the system, should they fail, (again, in general). In a modular kernel design, where everything is run in user-space, if a single driver goes berserk it is entirely insulated from the rest of the system. Then there are embedded systems, which are regarded as more stable because the hardware they run on is identical from one system to the next and never changes. Contrast this to operating systems that must run on a wide range of consumer hardware; there is a statistically higher probability of mistakes, just due to the increased size of the codebase. (In practice this doesn't always work out though, as I've used some embedded systems that were embarrassingly unstable). The smaller codebase of embedded systems and modular kernels is typically easier to audit, as there is far less code. Where human life is directly dependent, the code must be audited by a third party. For pretty much any other critical application, FreeBSD Release has been quite stable in my experience. Strip the kernel of everything you don't need, write good drivers and run it all on stable hardware and you should be fine in most situations. You'll probably go years between reboots. Just my 2 cents. -Modulok- On 6/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I've read some really good things about FreeBSD, especially its virus resistance and reliability. Will FreeBSD work on a robot that has to be trusted in critical situations? Kevin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] --- The information transmitted in this e-mail is for the exclusive use of the intended addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. E-mails may not be secure, may contain computer viruses and may be corrupted in transmission. Please carefully check this e-mail (and any attachment) accordingly. No warranties are given and no liability is accepted for any loss or damage caused by such matters. --- ### This e-mail message has been scanned for Viruses by Bytecraft ### ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: FreeBSD and Robotics
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Modulok Sent: Sunday, June 17, 2007 7:40 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: FreeBSD and Robotics It's only as good as the drivers you write to control the robot. It also depends on just how critical your critical situations refers to. In situations where human life is directly dependent upon the integrity of the system, a modular kernel design has traditionally been preferred over the monolithic kernel designs found in Windows, Linux, BSD. That isn't to say that FreeBSD is unstable, in fact it's very stable. However, in a situation where people die if the system fails, there are some questions as to the safety of the underlying designs of these kernels. The reason for this is, (in general), device drivers operate in the kernel's memory space and therefore have the potential to bring down the rest of the system, should they fail, (again, in general). In a modular kernel design, where everything is run in user-space, if a single driver goes berserk it is entirely insulated from the rest of the system. Then there are embedded systems, which are regarded as more stable because the hardware they run on is identical from one system to the next and never changes. Contrast this to operating systems that must run on a wide range of consumer hardware; there is a statistically higher probability of mistakes, just due to the increased size of the codebase. (In practice this doesn't always work out though, as I've used some embedded systems that were embarrassingly unstable). The smaller codebase of embedded systems and modular kernels is typically easier to audit, as there is far less code. Where human life is directly dependent, the code must be audited by a third party. There's another issue and that is POST on standard PC hardware. POST takes too long. For example the auto industry has agreed on a standard time that a car engine computer must be fully operational, it is very short, no more than something like 2 seconds or so. Enough so that when you turn the key and the engine starts cranking, that the engine computer has completely booted and is running by the second crank. That is why you probably will never see standard computer hardware used in the operating room of a hospital to control patient life support, for example. If for example during an operation the computer controlling an artificial heart suddenly dies, the staff simply unplugs the lines from the computer and plug them into another computer which then is switched on and within a second has come fully ready, and operating. You could not wait the 30-60 seconds that POST on a regular PC would take to complete. By contrast, regular PC gear is used very much for stuff like image analysis and non-critical gear in a hospital. If the computer running a CAT scanner were to die in the middle of a scan, no big deal, you just replace it and restart the scan from the beginning. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
