Date: Sun, 07 Feb 1999 14:35:40 -0800 From: Mike Smith <mike@smith.net.au> To: Andrzej Bialecki <abial@nask.pl> Cc: freebsd-small@FreeBSD.ORG Subject: Re: Call for help - FreeBSD/PicoBSD presentation Message-ID: <199902072235.OAA07961@dingo.cdrom.com> In-Reply-To: Your message of "Thu, 04 Feb 1999 11:59:30 %2B0100." <Pine.BSF.4.02A.9902041148200.16170-100000@korin.warman.org.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
> Hi, > > I was asked to do a presentation on "FreeBSD in embedded applications" at > a NordU99 (Nordic USENIX/EurOpen) conference in Stockholm. This is very > short term (the presentation itself will take place on Feb 12th), and I > could do with some help. :-) There will be quite a few famous names there > (you can see for yoursefl: http://www.europen.se/NordU99 ). > > What I basically need is some examples of embedded solutions you based on > FreeBSD - I know of a few of them, but I need more information about such > things as: hardware (CPU, RAM, peripherals), functions performed, your > impressions wrt. the efficiency and stability, possible directions for > development, etc... If you haven't already heard from Daniel O'Connor (doconnor@gsoft.com.au), here's some skeletal information on what we did at Genesis while I was there. Daniel took over my job, and he can talk a lot more about what they're doing now, but in my time we deployed a couple of embedded FreeBSD products as controllers in specialised research radar applications. Our standard hardware was a P5/120 on an 430HX board, SCSI disk, 19" rackmount chassis. We used simple digital I/O cards (Advantech PCL-732 and National Instruments AT-DIO-32) to interface with the custom hard-realtime hardware. Data processing and storage was also performed on the controlling systems; judicious hardware and software design made it possible for us to run both acquisition and heavy data analysis on the one system without compromising reliability. We initially deployed using a very early 2.2-current snapshot, and stability under load was very good. The initially-deployed systems were (ab)used mercilessly by the scientific staff, but complaints were usually related to the limited capacity of the system rather than its reliability. Later systems moved to IDE disk and custom PCI interface cards to reduce costs and improve performance, and it's at that point that I moved on. Basically, we used a single Pentium-class system to support: - raw data transfer at up 1 Megabyte/sec. - raw data archival (online and offline) - data analysis - analysed data archival (online and offline) - system scheduling - system health monitoring - GUI interfaces to scheduling, health monitoring and browsing of analysed data. On the whole, FreeBSD was more than capable; we took its capabilities and limitations into account in the early phases of system design and didn't run into any major unexpected difficulties. More significant problems were presented by the variable quality of PC hardware, particularly that available to a small company on a tight budget. Note sure how much that might help; I can fill in more details if you can be more specific. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902072235.OAA07961>