Re: [Xastir] Xastir on VMWare Segfault
On Tue, 26 Dec 2006, James Ewen wrote: > Xastir never fails to challenge me! So I'm sitting here trying to figure out whether that's derogatory or a compliment... That makes it a very good comment in any case! -- Curt, WE7U. archer at eskimo dot com http://www.eskimo.com/~archer Lotto: A tax on people who are bad at math. - unknown Windows: Microsoft's tax on computer illiterates. - WE7U. The world DOES revolve around me: I picked the coordinate system!" ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Xastir on VMWare Segfault
I've got a theory. I ran the VM this weekend for several days. It never crashed or bogged down as you describe, but when I used a bunch of shapefile maps it did use a bit more memory than I thought it would have needed. I betcha dollars to donuts what you're seeing is that xastir is starting to take up more RAM than has been allocated and eventually the VM starts thrashing. I started the VMWare appliance again... With no dbfawk file, I was able to zoom around pretty decently. No serious lags in rendering. The full province took about 10 seconds to render. Xastir sits at about 7% memory usage. There was about 8K of memory available. I zoomed close in (4 second render), and then renamed the dbfawk file back so it matched the file names. Another zoom in, and it took 45 seconds to display. Xastir moved up to about 9% memory usage, and memory available moved down to about 3K. Used swap space never changes... I think there's a problem with the dbfawk file though. I'm following the original instructions you gave me just over 2 years ago. This should have almost everything rendering in red and 4 pixels wide. Nothing ends up that way, but the names all appear as None, which means that it is working somewhat. With the huge rendering lag, I haven't been looking at the dbfawk file though. Xastir never fails to challenge me! James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Xastir on VMWare Segfault
On Tue, Dec 26, 2006 at 11:51:47AM -0700, we recorded a bogon-computron collision of the <[EMAIL PROTECTED]> flavor, containing: > I had Xastir running from a terminal window, and found out that it seg > faulted. I can't find a core dump though. > > I also seem to be having problems with the shapefiles. It seemed to > work pretty fast when I first started playing with them. Now it can > take up to 2 or 3 minutes to render an image. I thought it was because > I had created a dbfawk file, and it was taking a while to parse out > the file, but I removed the dbfawk file, and still get massive delays > when trying to use shapefiles. I've got a theory. I ran the VM this weekend for several days. It never crashed or bogged down as you describe, but when I used a bunch of shapefile maps it did use a bit more memory than I thought it would have needed. I betcha dollars to donuts what you're seeing is that xastir is starting to take up more RAM than has been allocated and eventually the VM starts thrashing. You can see if that's the case by running "top" in another terminal window and watching the available memory and swap usage (up near the top of the display). If you start to see the swap usage go up as you use xastir, then yes, xastir is starting to take up more RAM than was reserved to it, and is trying to use swap. If it tries to use swap a lot, then it will slow down dramatically. If it tries to use so much RAM that it tries to use more swap than is available, it will crash unceremoniously. I'm keen to know if that's what's going on. If it is, and if you have enough RAM on your computer, you could try bumping up the allocation to the virtual machine. Out-of-the-box the VM is allocated only 256MB, and in the instance I had running for a few days I found that it liked to use almost all of that, sometimes coming within 2 or 3 MB of the available RAM. This was with a fair number of shapefiles in use, while zooming and panning a little. If I'd added a few more shapefiles that needed rtrees, especially large maps that had lots of shapes in them, I can imagine that it would start to have trouble finding room for them. If you're running with shapefiles that cover very large areas, and viewing them in screens that only cover a small part of those areas, it's possible that your usage is causing some hefty memory usage due to all the rtrees. Bumping up to 300 or 512MB (if you can spare it on your computer) would probably help, and more is better. Stay within the range recommended by vmware and guide your choice by watching the windows task manager performance meter, though, because if you make the VM too big then windows could start having trouble finding space for its own bloat, and then *it* would start to thrash to swap. I saw no obvious signs that there was a memory leak that would cause rtree to consume memory without bounds --- if I left xastir alone for a few hours then memory consumption went down so there were a few dozen MB of free space. But I can't positively rule out that possibility at this point, but am reasonably convinced there's none by pointing to a few years of using the feature without seeing RAM-related crashes or unbounded growth). Rtree enhances shapefile speed by caching some information about shapefiles, trading RAM for speed. If you have lots of shapefiles and are doing lots of zooming and panning you could cause a fair amount of memory bloat. There is some attempt to throw away rtrees that aren't being used, but that only helps so much. (Details: an rtree spatial index is built for each shapefile the first time it's rendered in such a way that it is not wholly contained in the current screen view. The rtree stores information about the bounding box of each shape in the shapefile, and allows fast lookups to answer the question "which shapes intersect the screen?" Without rtree, that was answered by reading each shape sequentially from the file and checking every time the screen is redrawn. An existing spatial index is used whenever the associated shapefile is again rendered into a window that doesn't wholly contain it, but the spatial index is NOT accessed if the entire shapefile is contained in the window. Any rtree spatial index that hasn't been accessed in an hour is discarded and its memory freed. The idea is not to bother keeping around indices that aren't being used often, and only use them when they help (i.e. when the answer to the question "which shapes intersect the screen?" is not "all of them". Even with this attempt at minimizing memory footprint, rtrees can wind up taking up a fair amount of RAM.) One of the decisions I had to make when generating the virtual machine was to pick something that would be small enough to get running quickly and would cater to the lowest common denominator machine. If you have enough RAM, you should definitely allocate more to the virtual m
[Xastir] Xastir on VMWare Segfault
I had Xastir running from a terminal window, and found out that it seg faulted. I can't find a core dump though. I also seem to be having problems with the shapefiles. It seemed to work pretty fast when I first started playing with them. Now it can take up to 2 or 3 minutes to render an image. I thought it was because I had created a dbfawk file, and it was taking a while to parse out the file, but I removed the dbfawk file, and still get massive delays when trying to use shapefiles. James VE6SRV ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] non-kernel mkiss app usefulness?
On Dec 26, 2006, at 6:14 AM, Carl Makin wrote: Source code to a linux mkiss daemon that should be pretty easy to make work without the linux ax25 code is reachable via the radio.linux.org.au site; http://radio.linux.org.au/pkgdetail.phtml? sectpat=All&ordpat=&descpat=&pkgid=93 Thanks. This looks like it does the job, and does it more simply that I would have expected. It's going to need a bit of work to compile on OS X. Here's a different solution for those who, like me, need to hook up a bunch of rs232 devices without much fuss. I stumbled across this: http://www.cooldrives.com/4rstousbadwm.html I have not bought one, but it looks like it meets my needs: 4 rs232 ports, one box, on cable back to computer (USB, not rs232), uses the FTDI chipset (drivers work on windows, linux, mac os x) and in addition can supply external power to the DB9 connector (not sure of the details on that one). Yeah, it's $90, but it's four usb/rs232 adapters plus a usb hub in one box, so the price is in line with the solution I've got now. Plus it's a nice metal box with mounting tabs and power distribution over DB9. If I hadn't already spent close to $100 on various usb/ rs232 adapters I'd already have one on the way. If anyone actually has one of these, please let me know how it performs. -Jason kg4wsv ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] non-kernel mkiss app usefulness?
On 22/11/2006, at 2:21 AM, Curt, WE7U wrote: On Mon, 20 Nov 2006, Jason Winningham wrote: Another solution would be a standalone mkiss type utility that runs outside the kernel. This type of utility should be portable to other systems, like Mac OS X or Solaris (maybe cygwin, but I don't know I thought about this as well. Kind of like the x_spider code we have now, only a separate utility that would hook to one MKISS hardware serial port, then would branch out to multiple PTY's in Source code to a linux mkiss daemon that should be pretty easy to make work without the linux ax25 code is reachable via the radio.linux.org.au site; http://radio.linux.org.au/pkgdetail.phtml? sectpat=All&ordpat=&descpat=&pkgid=93 Carl. ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Zoomable Google maps for Xastir ?
Curt Mills wrote: > On Sun, 24 Dec 2006, Henk Oegema wrote: > > >> My question : Is it possible to use zoom able Google maps online, >> > > No. Up until very recently the Google Maps licensing was so > restrictive that we couldn't use them at all. At that point they > specifically excluded any sort of vehicle tracking. At some point > within the last few months they changed their licensing drastically, > making it possible that we might be able to use their maps in the > future. Nobody has seriously looked into doing so yet. > > >> Like the one in use at the DB0ANF APRS Server >> >> (Or other zoom able maps for Europe) >> > > You might investigate the Shapefile format maps that Henk de Groot > has on his site, or look for WinAPRS/APRSdos/ or PocketAPRS maps > that are out there. Xastir can use any of them. You might also > prowl around on ESRI.com to see what they have for downloadable > maps. They have another site linked there that they also provide > which has a lot of downloadable Shapefiles. > > Tnx, Curt. Happy New Year for ALL. 73, Henk ON4HSO/PA2HO ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
