James Kimble wrote: > >> I'm in the process of architecting the software for an embedded Linux system >> >>> that functions as a remote and local user interface to a control system. >>> There >>> will be a lot of analog (fast) data arriving via SPI bus and I'm thinking of >>> using SQLite to store this data in a well organized and easy to access >>> manner. >>> >>> My main concern is performance. Has anyone had any similar application >>> experience they could comment on? I want to be able to insert data arriving >>> on the SPI bus and then query the data to update a GUI at a very high rate >>> (less than 250Ms). This is not real time so 250Ms is desirable but does not >>> have to be guaranteed. >>> >>> Any thoughts or experience would be appreciated... >>> >>> >> >> >> > > >>> You arn't clear about your update rate, or the amount of data you need >>> to extract for each GUI update. You also haven't said where you will be >>> storing the database, in RAM, on a hard disk, or in flash. >>> > > >>> If the data is only updated every 250 ms, i.e. at a 4 Hz rate, it is not >>> really very fast, and SQLite should have no problem keeping up even on >>> an embedded processor. >>> > > >>> If the GUI has to display only the last value every 250 ms, then you >>> should have no trouble. If you are trying to redraw a scrolling graph of >>> the last 400 samples every 250 ms you may have issues to be concerned about. >>> > > >>> Dennis Cote >>> > > > Thanks for your reply. > > The one thing that scares me is that this will be residing on a flash > based file system > and not a disk. I'm hoping that's not too much of a performance hit. > Right now I've > got it running out of RAM and that may be fine 99% of the time but I > will need to > write it back to flash at some set interval (minutes) to prevent loss of > data in the case > of a power failure. Not sure how to mix modes like that yet. > > The biggest thing on the GUI will be some power level meters. Very slow > moving > and mostly fixed data. Possibly a spectrum diagram but again, slow > moving. This > is a control system for commercial TV/Radio transmitter systems. > > I didn't give many details because I haven't implemented anything yet. I > am still > considering my options. I thing SQLite will work I've just got to test > it. I'm in the > process of setting up a test database and tables that I can work on in a > way similar to > what I will need. That's probably the best way to be sure in any case. > If it doesn't > perform fast enough I will work on optimizations. I've dealt with some > big DB's in the > past (Oracle, Informix, Ingres) but never one quite like this and never > on an embedded > system. Very new to me. > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > One thing I can highly recommend on embedded systems, especially flash based ones, is turn pragma synchronous to off. Having sqlite write every record modification to the flash, is a stunningly expensive process, even when it's all encapsulated in a large transaction. Let linux handle the synchronisation and write caching for you. A lot less robust, but, the benefits more than outweighed the cost. If you need guaranteed write to disk, then perform the synch yourself.
Cost vs benefit and all that guff. -- Bill King, Software Engineer Trolltech, Brisbane Technology Park 26 Brandl St, Eight Mile Plains, QLD, Australia, 4113 Tel + 61 7 3219 9906 (x137) Fax + 61 7 3219 9938 mobile: 0423 532 733 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
