Re: SQL and real time systems

hi,

The rt system that I have been working on is actually a class 5 telephone switch.
We need to be able to support 64000 connections. Thus the connection table can have 64k entries.

My problem with the design using sql that has been proposed is

Consider if I have to get all the connections through a port card

1. If I do a select statement it can return up to 64k items, I need to create a huge static block or allocate on the stack a block to get this data. That was my memory concern.
2. I really only need to get records one at a time, so an interface getting a first, then allowing me to get a next and so on etc is better. Getting a single record can be done in log 64k accesses, getting the next in <= log64k accesses. (very snmp like).

This is predictable wont use up memory and shouldnt take up a lot of processing time.

The argument for using sql is that we can use a commercial database.

I think it totally unsuitable.

roger

Terrence Enger <tenger_at_idirect.com> wrote in message news:<3E1A381C.8050909_at_idirect.com>...
> --CELKO-- wrote:
>
> >>>Any comments on the suitability of using an sql database in a real
> >>>
> > time system ... In my mind it doesnt seem suitable becaause of the
> > memory usage and the amount of real time used in performing queries.
> > <<
> >
> > I would not do that. Most RT applications will be doing straight data
> > capture from a few (usually one) sources and you will not share it
> > with anyone else. Speed is the most important thing in RT
> > applications, while data integrity, sharing, etc. are what is
> > important in an OLTP application.
>
>
> Well, to be picky about terminology, at least about what words *should*
> mean <grin> ...
>
> What a real-time system requires is not necessarily great speed, but
> rather predictable speed. And so Joe's recommendation stands.
>
>
> >
> > Stuff your data into a file in your RT/OS, scub it, then move it over
> > to an analysis tool or a database later.
> >
Received on Wed Jan 08 2003 - 12:35:38 CST