Reply With Quotehmmm I seem to be getting this on my windows machines as well. The linux client is fine though.
As per subject, progress.txt is getting stuck on my machines.
e.g.
Building structure 1 generation 85
49 until next generation
0 generations buffered
Best Energy so far: 10000000.000
Stop the service, re-start the service:
Building structure 43 generation 85
7 until next generation
1 generations buffered
Best Energy so far: 10.081
Repeatable on every machine I have.
hmmm I seem to be getting this on my windows machines as well. The linux client is fine though.
I do not understand the problem, please elaborate.
Howard Feldman
Basically when you let the client run the progress file always showsThe generation number changed but the output is always stuck on "bulding structure 1" and the "Best Energy" is stuck on 10000000.000 and so is current energy.Code:Building structure 1 generation 85 49 until next generation 0 generations buffered Best Energy so far: 10000000.000
However if you stop the windows service and restart it the Best Energy changes from 10000000.000 to proberbly your best energy in haloJones case it was 10.081 and the current energy is still 10000000.000, and build structure 1. If you leave it to run, the current energy doesn't change it sticks.
Again if we restart the service it'll show the new best energy and so on ... if you know what I mean
I have a bunch of NT4 clients. Ran the Phase I client superbly.
Now they are running, but after each generation, the progress.txt gets "stuck" showing 10000000 as the best energy. If you stop and re-start the service, progress.txt catches up to where it really is. Then at the next generation, again progress.txt gets stuck and doesn't update with what is actually happening.
This happened last night on both my home machines - one W2K, one XP - but a stop and a re-start has fixed them for good. (so far)
Ah ha! I stopped and started the service a couple of times and it still got stuck but it seem to have corrected itself after a reboot.
But one thing that is odd and I hope it's not related is that. I have serveral machines, now the 2.4G P4 running on linux and a AthlonXP 1800+ also on linux I started them crunching yesterday (but switched them off over night). I have an Althlon classic 700Mhz I started this morning ... but even with the head start and vastly faster CPUs of the linux machines the Athlon Classic 700Mhz is on generation 42. The P4 2.4G is also on 42 and the XP1800+ is on 31. Now I understand that structures can get "stuck" but this is insane ... the 700Mhz Althon is consistently pulling ahead and gaining
Howard, this is the same thing that I saw during the beta of Phase II.
If I started the client from gen 0 it never seems to update the best energy or structure properly using the default settings. If I stop and start the client, it will start working again, or if I had selected update after each structure (-g 1) then it does seem to always work fine.
I guess now that we have more people running the client, others are seeing the same thing.
Jeff.
I have that problem on some of my machines but I think that it is because I have the -g 100 flag set. In this case it will never update during a 50 structure generation. When you quit it writes to disk where ever you happen to be so then things get updated.
It does seem to go away if you eliminate the -g flag and run with the default which is 5.
i had this happen on a XP laptop NOT running as a service, just from a dos box
Use the right tool for the right job!
So far the following is working.
Change service.cfg to include progress=2
Start the service with services.msc
Start DFGui and watch.
Progress.txt updates nicely and regularly.
If you allow DFGui to start the service it removes the progress=2 line from service.cfg.
That is because when you start the client with dfGUI, it will start using whatever options you have in the Config tab of dfGUI.Originally posted by HaloJones
If you allow DFGui to start the service it removes the progress=2 line from service.cfg.
So if you want it to update after every 2 structures, in dfGUI go to the Config tab, change the Progress Update box to say 002 and then check the box. After that, when you start the service using dfGUI, the service.cfg file will contain the correct value.
Jeff.
so is this really just a reporting issue? not a "real work" being done issue? i.e. the client is doing good/real work, it just isn't being reported to the progress.txt file correctly? right/wrong?
Use the right tool for the right job!
Sorry, Jeff. I wasn't trying to impugn your awesome add-on, just talking about a possible fix.
The basic problem here is the default progress update doesn't seem to work as far as progress.txt is concerned. I'm hoping it is just the reporting of the progress and not the progres itself.
The athlon 700/windows2k is now on generation 54 whilst the P42.4G/linux is on 47 generation ... I really hope it's doing real work ...
I believe the client is still doing real work and it submits data to the server as far as I can tell its just that the progress.txt file doesn't seem to get updated properly if you leave it at the default setting. For me it only happens when I start from generation 0 but if I restart the client after that it seems to start working again.Originally posted by FoBoT
so is this really just a reporting issue? not a "real work" being done issue? i.e. the client is doing good/real work, it just isn't being reported to the progress.txt file correctly? right/wrong?
Jeff.
from my observations and reading other people posts, i concur
thanks
Use the right tool for the right job!
That seems to me what I'm seeing. I will be using the progress=2 setting in my service.cfg files from now on.
Just wanted to say that I'm seeing the same thing.
progress=2 is pretty often...
/me tries with progress=10
If you use progress=10 then you will only get 5 updates for the whole generation. Remember that after generation 0, each structure takes a lot more time so using progress=2 is not unreasonable. I like to user progress=1 just so I can get all the stats I need after each update.Originally posted by pointwood
progress=2 is pretty often...
/me tries with progress=10
Jeff.
Yup, I think it is solved but setting the progress= option in the config file. I'll change the default to 5 or something for future when running as service. Rest assured the 'stuckiness' is only in printing out the progress.txt, it really is doing work
Howard Feldman
I am havign this problem with the Linux version. I have now run into this twice in the last 4 hours or so. using DC Monitor to check the status of it.
System is running Debian Potato 2.4.20
Stopping and restarting it will fix it, but it will do it again later.
Would it be possible for the client to write the progress.txt file at a time based interval (ie every x mins) instead of a structure based interval? That way this problem shouldn't occur and would make monitoring the client easier even during the 'stuck' phases of structure simulation.
Posting Permissions