Hi David, On Tue, Feb 2, 2010 at 3:30 PM, David Fries <[email protected]> wrote: > I did not look into the content of the requests. How would I > instrument the code to find out?
Good question. I myself have been considering how to add the extra diagnostics in. Right now the stats handling reports the value returned from getFileRequestListSize() and getDataToCompileListSize(). The getFileRequestListSize() value is the sum of _fileRequestQueue and _httpRequestQueue _requestQueue sizes. > I was just guessing that they are repeated requests, otherwise they > would not keep increasing at a steady rate. I am using the Trackball > camera manipulator camera and give the earth.ive a nice fling, so it > is repeadily going over the same tiles and not all. The earth.ive > only has 12,450 files and there can be many more requests than that in > the request queue. Very strange, it does indicate that something is going amiss. When I fling the earth.ive model I can get to a thousand or so requests but not beyond this. Even this number of requests seems very high, the usage is odd of course, throwing a whole earth model to spin at tens of hrz is not something you can do in any normal type of human vehicle... We do need to get to the bottom of quite why there is so many requests, the scheme implemented in DatabasePager should prevent multiple DatabaseRequest objects per PageLOD, and we shouldn't be ended up with such high numbers of PagedLODs. > >> What hardware/OS are you working with? > > Linux kernel 2.6.27.26, 8 core Intel(R) Xeon(R) CPU E5440 @ 2.83GHz, > nVidia Quadro FX 3700 driver version 185.18.14. Not a long way different from my own system, a 2.6GHZ Core i7, which is four core, but with 8 threads. For me system: > uname --all Linux harris 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux I've enabled the precompilation but this doesn't make much difference to my ability to rack up requests. To enable it: export OSG_DO_PRE_COMPILE=ON osgviewer mymodel.ive I have ATI card and driver, the driver is pretty slow at compiling display lists, much more so than I've ever seen with NVidia cards/drivers, so I would expect to see more issues with not clearing the backlog of requests. I will add some diagnostics into the DatabasePager to track how many requests there are in the system and how many unique requests have been generated, perhaps this will shine a light on to what is going on. Independently from this I am wonder about whether we should have a mutex in DatabaseRequest, or possibly even PagedLOD to manage changes to the DatabaseRequest object such as data changes and re-assignment to a new queue. I am considering this as I'm concerned that if we are running on multi-card/multi-threaded systems it will be possible to have DatabasePager::requestNodeFile(..) called from the PagedLOD for the same child at the same time, this has the potential of thrashing the DatabaseRequest state and also possibly duplicating it. This also overlaps with the race condition that you've been working to address. W.r.t the race condition's, how are you seeing it reveal itself? I got a crash earlier about attempting to delete a osg::Referenced object while it's ref count was 1, which suggest to be a problem lurking somewhere. The crash only happened in one of dozens of runs I did so it's unfortunately one of those threading crashes where the locating it and knowing 100% it's fixed is rather illusive. Robert. Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
