Hi Jason, Thanks. It is good to know that the - Default=x, where x = 0-2 is 'normal', but Chris reported that it was still running after 6 hours, or more... and still unable to exactly find where this is output, in the code...
When you say a 'long time', do you mean more than this, like DAYS? ;=(( Just trying to get an idea of how 'patient' one MUST be... before deciding something is really going 'wrong'... I do not know, or remember, what OS you are using, but after you mentioned it, I decided to take a quick look at server and client in WIN32, and there is absolutely NO WAY they would EVER run in windows ;=(( For a start neither do the WSAStartup() call, so you would not even get a socket allocated; then they do close(sock), which bombs in windows - that has to be closesocket(sock); and one (or both) use read(sock,...) and write(sock,...) instead of recv(sock,...) and send(sock,...), which also bombs in windows... Anyway I have made copious fixes for WIN32, and now they run fine for me... takes some setting up to get it all working... and added a new option to client, namely - --tool=<fgfs-construct-exe> so you do not have to make sure this 'exe' is in one of your PATH places... I am presently testing all this more, and will posted the fixes if it all works ;=)) I do not know much about the server stats yet, but it is indicating a rate of over 3,000 buckets per hour - a 10x10 chunk is about 2700 buckets, but ATM running both in the same machine... AND this is on only 'standard' mapserver cs landuse data, with VMAP0 boundaries, with an un- pushed terrafit on SRTM1 elevations... so is just minimal raw data being processed... And running the server somewhere, and then multiple clients should fully utilize any multi core machine... but still to test this... >> ( still building YSSY to YWLM ) This also happens to be one of my favorite scenery build areas, although I always extend that out to YGIL ;=)) That is the e150s40 and e140s40 chunks... and the s30 group if I want to include YBBN... Any chance we may see the harbor bridge in the scenery database ;=)) Sydney always looks a bit strange without it, and the Opera House, to name a few iconic indicators... maybe they are already there since I have not done a full check in a while... And Chris, you can see some of the comments associated with the 2009 patch to the rlimits code you pointed to are NOT correct! Even at that time any attempt to limit memory use was abandoned, and the CPU timeout was doubled... Like it seems you have done, this 'limit' is really NOT applicable to a specific area generation, as apposed to a whole world generation, using server/client, so like you, I 'chop' this 'rlimit' code completely... I do find after using my modified server/ client combination, the machine becomes very 'slow' until a re-boot. Obviously lots of resources/memory are used, and they are not fully recovered until after a re-boot... But even using server/client, where the client runs fgfs-construct _ONE_ bucket at a time, can still take 'hours', as opposed to days!, for a 10x10 chunk... As always, would really like input from others on this very important scenery generation topic... Some, like Gijs, and myself, are working on a GUI to assist in this scenery generation, but the important issue IS making sure the TG tools work well, otherwise such a GUI is rather pointless... In the GUI, like in server/client, I only ever run fgfs-construct one bucket ID at a time... ie with --tile-id=<id>... this at least gives you some indication on how things are progressing, or not... ;=() Regards, Geoff. ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
