[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
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
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
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: