[kismac] Re: Large files/nos of APs

  • From: Michael Rossberg <mick@xxxxxxxxxxxxxxxx>
  • To: kismac@xxxxxxxxxxxxx
  • Date: Sat, 22 Jan 2005 19:06:51 +0100


Just to post a user experience:
I tried to work with r53 and the files I saved with 0.12a. I have quiet a big file ( about 4MB) with about 1400 nodes I collected in my town. When i open this file in r54 the whole system slows down and it takes minutes to open the file. It seems that KisMAC uses all my clocktime (TiBook G4 550, MacOSX 10.3.7, 768MB RAM). It was getting worse when i opened the map. And in the end I had to kill the app, because even the mousepointer reacts with a delay of several seconds. Starting with a fresh and empty file seems to be no problem, but what is the issue with the old file? I remember 0.12a being slow with this big file as well...

I'm also messing around with big files (composing 5000+ AP's by 'import' from separate 500+ AP files) on a G5 DP. Although waiting times are kept within limit, Kismac crashes frequently when over 5000 or so. Kismac has never been designed for these large number of AP's. Mick is looking into options, having been donated a few of these large files :-)
I'm composing these large files to find all AP's with a certain name. Fortunately, Mick has been kind enough to provide such a tool on the map page of .Kismac, on the web.

let me just write a small statement to this. i use kismac primarily as a test suite for single networks, lets say up to the size of a university.
as many of you probably can remember, kismac used to be much slower back in the really old days. back then i improved speed a lot by replacing generic apple cocoa objects with highly specialized c functions. even now it would be possible, by exchanging parts of kismac, to improve some functions. for an example the save files could be made more proprietary in order to gain more speed. i will keep looking for areas in the code, where a optimization will actually gain something.
but i think we are hitting another barrier here. with 3000 access points the data volume becomes to big to be handled entirely in memory in real time. this means we need a database alike function within kismac. this on the other hand would mean no instant updates, as we cannot execute a couple of database calls whenever a packet comes in.
the only solution that i see is an engine which uses for lately active networks a memory solution and for the rest a database backend. unfortunately i am not able to program in my spare time. this project size requires a commercial development team. sorry.


Other related posts: