BOINC Tasks Settings->WWW: clicking OK does not close the window.
Quote from: glennaxl on November 12, 2010, 02:05:07 PM
BOINC Tasks Settings->WWW: clicking OK does not close the window.
Forgot that one, use the [X] for now. Or an OK in another window.
It doesn't seem to generate the tasks.html
I've look at the appdata folder and installdir of bt but nothing is in there after more than 30 mins. WWW update is enabled. Am I missing something?
Quote from: glennaxl on November 12, 2010, 03:50:42 PM
It doesn't seem to generate the tasks.html
I've look at the appdata folder and installdir of bt but nothing is in there after more than 30 mins. WWW update is enabled. Am I missing something?
When you did all this: http://www.efmer.eu/forum_tt/index.php?board=27.0 (http://www.efmer.eu/forum_tt/index.php?board=27.0)
Goto the log and enable debugging. Set the time for a minute or so and check for error messages.
Quote from: fred on November 12, 2010, 03:53:36 PM
Quote from: glennaxl on November 12, 2010, 03:50:42 PM
It doesn't seem to generate the tasks.html
I've look at the appdata folder and installdir of bt but nothing is in there after more than 30 mins. WWW update is enabled. Am I missing something?
When you did all this: http://www.efmer.eu/forum_tt/index.php?board=27.0 (http://www.efmer.eu/forum_tt/index.php?board=27.0)
Goto the log and enable debugging. Set the time for a minute or so and check for error messages.
Cool, just have to copy tasks_template.html
Now its time to design my page. Thanks
Hi Fred, using BT 0.87 and TT 3.00, the temperature graph now displays properly for my computer without a GPU - thanks.
Couple problems that have been around for awhile:
1) In Projects/Tasks 0 tasks shown even though 1 is running for nci projects WUProp & FreeHAL.
2) When tasks start or finish a high value (20-30 minutes) is often shown in Tasks/Checkpoint for 1 update period,
which triggers the warning flag. This is particularly noticeable in MilkyWay and Collatz where the WUs are short.
Quote from: Beyond on November 13, 2010, 07:13:41 PM
Couple problems that have been around for awhile:
1) In Projects/Tasks 0 tasks shown even though 1 is running for nci projects WUProp & FreeHAL.
2) When tasks start or finish a high value (20-30 minutes) is often shown in Tasks/Checkpoint for 1 update period,
which triggers the warning flag. This is particularly noticeable in MilkyWay and Collatz where the WUs are short.
1) Tasks that use up only memory or other resources are not counted.
2) Be a bit more specific, so I can test it.
BT not always allowing BOINC to start. Boinc gives error message "another instance of BOINC is running" and quits. However, there is no other instance of BOINC running according to Windows 7 task manager. If I stop BT using the "Exit" then BOINC can be started. I am guessing that BOINC tries to use port 31416 and when it cant, it then assumes a copy of itself is running ???
To duplicate this problem BT must have " [X] Start BOINC at login" checked and be iconized. It can sometimes take 3 tries before the failure shows up. Once the failure show up, BOINC will never start unless BT exits.
This is what it looks like when the failure occures
(http://stateson.net/images/boinc_bt_bug1.png)
The following image was taken immediately after entering the RETURN key on the command line. Note that BOINC is running
(http://stateson.net/images/boinc_bt_bug2.png)
This image was taken a few seconds later and shows the error message. Note that BOINC is no longer in the task manager
(http://stateson.net/images/boinc_bt_bug3.png)
This images was taken after terminating BT (note it is no longer in the task manager, and BOINC is running fine
(http://stateson.net/images/boinc_bt_bug4.png)
The purpose of my stopping boinc was to allow CD and DVD burning to proceed at full speed on the few occassions when there is a heavy load on my system. Maybe there is another way to pause all tasks so multiple DVD burns can run at full speed.
Quote from: BeemerBiker on November 14, 2010, 02:51:33 PM
BT not always allowing BOINC to start. Boinc gives error message "another instance of BOINC is running" and quits. However, there is no other instance of BOINC running according to Windows 7 task manager. If I stop BT using the "Exit" then BOINC can be started. I am guessing that BOINC tries to use port 31416 and when it cant, it then assumes a copy of itself is running ???
To duplicate this problem BT must have " [X] Start BOINC at login" checked and be iconized. It can sometimes take 3 tries before the failure shows up. Once the failure show up, BOINC will never start unless BT exits.
The purpose of my stopping boinc was to allow CD and DVD burning to proceed at full speed on the few occassions when there is a heavy load on my system. Maybe there is another way to pause all tasks so multiple DVD burns can run at full speed.
I think it's the mutex that is still set.
The problem with the mutex that it is sometimes only released when the main program that starts BOINC.exe is closed.
BT starts the BOINC client and gives the BOINC client instructions to detach itself, so this problem should be avoided (about the same way you did). But this varies from OS to OS and sometimes it doesn't work.
The port can be used more than once, you can run BT and BOINC manager at the same time.
The easiest way to close everything down is using Extra->allow to run -> computer -> never. Or use snooze, but that only lasts for 1 hour.
Another way is to add the exe to the exclude list for the BOINC client, this should stop everything, for as long as a number of programs are running.
When you want to stop and start the client. Use File->Start or Stop.
But sometimes there is simply something wrong with the client and it refused to do so....
Quote from: BeemerBiker on November 14, 2010, 02:51:33 PM
BT not always allowing BOINC to start. Boinc gives error message "another instance of BOINC is running" and quits. However, there is no other instance of BOINC running according to Windows 7 task manager. If I stop BT using the "Exit" then BOINC can be started. I am guessing that BOINC tries to use port 31416 and when it cant, it then assumes a copy of itself is running ???
Try killing boinctray.exe in task manager and see if BOINC will start. Sometimes when boinctray.exe is running BOINC refuses to start. Killing the process ssolves the problem. You can also eliminate it from starting with MSCONFIG. I reported this to the BOINC devs, so far no fix. If you have BOINC set to run always boinctray.exe is unnecessary.
Quote from: fred on November 14, 2010, 03:07:57 PM
When you want to stop and start the client. Use File->Start or Stop.
But sometimes there is simply something wrong with the client and it refused to do so....
Another bug that several of us have reported to the BOINC devs. So far they deny it happens...
Quote from: fred on November 14, 2010, 07:22:27 AM
Quote from: Beyond on November 13, 2010, 07:13:41 PM
Couple problems that have been around for awhile:
1) In Projects/Tasks 0 tasks shown even though 1 is running for nci projects WUProp & FreeHAL.
2) When tasks start or finish a high value (20-30 minutes) is often shown in Tasks/Checkpoint for 1 update period,
which triggers the warning flag. This is particularly noticeable in MilkyWay and Collatz where the WUs are short.
1) Tasks that use up only memory or other resources are not counted.
2) Be a bit more specific, so I can test it.
1) Why not count them? I find myself having to count FreeHAL processes and trying to figure out which client isn't running. Yes, FreeHAL is a problem child and doesn't always get a WU when the previous one is finished.
2) Not sure how to be more specific. When tasks start or finish a high value (20-30 minutes) is often shown in Tasks/Checkpoint for 1 BoincTasks update period (6 seconds or so), which triggers the checkpoint warning color in Tasks/Checkpoint. Since some WUs like MW are very short it looks a bit like a Christmas tree flashing (if running a lot of clients). Of course it is getting to be that season ;)
Quote from: Beyond on November 14, 2010, 04:04:30 PM
1) Why not count them? I find myself having to count FreeHAL processes and trying to figure out which client isn't running. Yes, FreeHAL is a problem child and doesn't always get a WU when the previous one is finished.
2) Not sure how to be more specific. When tasks start or finish a high value (20-30 minutes) is often shown in Tasks/Checkpoint for 1 BoincTasks update period (6 seconds or so), which triggers the checkpoint warning color in Tasks/Checkpoint. Since some WUs like MW are very short it looks a bit like a Christmas tree flashing (if running a lot of clients). Of course it is getting to be that season ;)
1) Because I add up run time an nr of tasks running to get an est time left. FreeHAL shouldn't be counted in the nr of tasks running and est time left, because it's not a regular tasks but only an idle memory consuming task. At least that's what it tells BOINC. ;D
2) MW does not checkpoint, so the will always show up as a warning.
You can give the MW checkpoint color the OK color, so it will not show up.
http://www.efmer.eu/forum_tt/index.php?topic=503.0 (http://www.efmer.eu/forum_tt/index.php?topic=503.0)
Quote from: fred on November 14, 2010, 04:25:46 PM
1) Because I add up run time an nr of tasks running to get an est time left. FreeHAL shouldn't be counted in the nr of tasks running and est time left, because it's not a regular tasks but only an idle memory consuming task. At least that's what it tells BOINC. ;D
2) MW does not checkpoint, so the will always show up as a warning.
You can give the MW checkpoint color the OK color, so it will not show up.
http://www.efmer.eu/forum_tt/index.php?topic=503.0 (http://www.efmer.eu/forum_tt/index.php?topic=503.0)
1) Maybe a new indicator under Projects/Tasks so it looks like 0/0/1? :) ;) ;D ;) :)
2) MW tasks run for 3-4 minutes on my systems. My checkpoint warning triggers are set at 5, 10 & 20 minutes. About 40% of the time the last BT update period shows a checkpoint time of over 20 minutes and thus flashes the > 20 minute warning color. Don't know where this erroneous checkpoint time is coming from but it can't be correct to show a > 20 minute checkpoint time on a 3 minute WU. I have set custom global checkpoints in config.xml. Here's my checkpoints:
<config>
<checkpoint>
<project>milkyway</project>
<application></application>
<seconds>100</seconds>
<red>120</red>
<green>255</green>
<blue>215</blue>
</checkpoint>
<checkpoint>
<project></project>
<application></application>
<seconds>300</seconds>
<red>0</red>
<green>175</green>
<blue>255</blue>
</checkpoint>
<checkpoint>
<project></project>
<application></application>
<seconds>600</seconds>
<red>255</red>
<green>75</green>
<blue>255</blue>
</checkpoint>
<checkpoint>
<project></project>
<application></application>
<seconds>1200</seconds>
<red>255</red>
<green>50</green>
<blue>50</blue>
</checkpoint>
</config>
The above does enforce the milkyway checkpoint warning color (same as the GPU running color) from 100 to 300 seconds, then is overridden by the global values and the 20 minute red warning color appears. Have tried many different configurations but the global settings always override the milkyway specific settings. What am I doing incorrectly?
Quote from: Beyond on November 14, 2010, 05:10:14 PM
1) Maybe a new indicator under Projects/Tasks so it looks like 0/0/1? :) ;) ;D ;) :)
2) MW tasks run for 3-4 minutes on my systems. My checkpoint warning triggers are set at 5, 10 & 20 minutes. About 40% of the time the last BT update period shows a checkpoint time of over 20 minutes and thus flashes the > 20 minute warning color. Don't know where this erroneous checkpoint time is coming from but it can't be correct to show a > 20 minute checkpoint time on a 3 minute WU. I have set custom global checkpoints in config.xml. Here's my checkpoints:
1) On the list.
2) I will investigate.
Quote from: fred on November 14, 2010, 05:32:50 PM
Quote from: Beyond on November 14, 2010, 05:10:14 PM
1) Maybe a new indicator under Projects/Tasks so it looks like 0/0/1? :) ;) ;D ;) :)
2) MW tasks run for 3-4 minutes on my systems. My checkpoint warning triggers are set at 5, 10 & 20 minutes. About 40% of the time the last BT update period shows a checkpoint time of over 20 minutes and thus flashes the > 20 minute warning color. Don't know where this erroneous checkpoint time is coming from but it can't be correct to show a > 20 minute checkpoint time on a 3 minute WU. I have set custom global checkpoints in config.xml. Here's my checkpoints:
1) On the list.
2) I will investigate.
Thanks!
2) After watching the tasks a lot more it appears to be showing this erroneous checkpoint time only on the LAST update period before the WU exits. I thought that it happened both at the start and the finish of the WU, but it seems to be only at the WU finish. As far as the behavior of the config.xml checkpoint settings, shouldn't the individual project/app settings override the global settings instead of the other way around?
To add my bit to the flashing Christmas trees ;)
Well I've noticed that my CPDN task shows red highlighted "[0] 14d,02:58:24" from last checkpoint (which is pretty unusual for CPDN), but its elapsed times were just around 18:38:20 (19:11:47) hours (snapshots taken if necessary). So I've looked in BT's task properties
Name famous_s303_599_200_000222072_1
CPU time at last checkpoint 14d,02:58:24
CPU time 18:38:20
Elapsed time 19:11:47
Estimated time remaining 01d,02:36:25
Fraction done 92.972 %
and BOINC Mgr's task properties
CPU time for last checkpoint 338:58:24
CPU time 339:04:33
Elapsed time 350:50:31
then took the numbers from client_state.xml
<result>
<name>famous_s303_599_200_000222072_1</name>
<final_cpu_time>67100.070000</final_cpu_time> (18:38:20)
<final_elapsed_time>69107.507910</final_elapsed_time> (19:11:48)
<exit_status>0</exit_status>
<state>2</state>
<platform>windows_intelx86</platform>
<version_num>611</version_num>
<wu_name>famous_s303_599_200_000222072</wu_name>
<report_deadline>1296099703.000000</report_deadline>
<received_time>1288210643.950953</received_time>
....
</result>
<active_task>
<project_master_url>http://cpdnbeta.oerc.ox.ac.uk/</project_master_url>
<result_name>famous_s303_599_200_000222072_1</result_name>
<active_task_state>9</active_task_state>
<app_version_num>611</app_version_num>
<slot>1</slot>
<checkpoint_cpu_time>1220304.000000</checkpoint_cpu_time> (338:58:24)
<checkpoint_elapsed_time>1262638.891236</checkpoint_elapsed_time> (350:43:59)
<fraction_done>0.929725</fraction_done>
<current_cpu_time>1220673.000000</current_cpu_time> (339:04:33)
<once_ran_edf>0</once_ran_edf>
<swap_size>102150144.000000</swap_size>
<working_set_size>59330560.000000</working_set_size>
<working_set_size_smoothed>59330560.000000</working_set_size_smoothed>
<page_fault_rate>0.000000</page_fault_rate>
</active_task>
No idea what could went wrong. The task was just waiting preempted. A few hours later, when the task was again running, BT was correctly displaying the Elapsed times around 14 days and the checkpoint delay in minutes.
Finally one snapshot: (http://i488.photobucket.com/albums/rr244/peposobr/TThrottle%20BoincTasks/CPDN14dayscheckpoint_.png)
Quote from: Pepo on November 15, 2010, 09:38:53 AM
Well I've noticed that my CPDN task shows red highlighted "[0] 14d,02:58:24" from last checkpoint (which is pretty unusual for CPDN), but its elapsed times were just around 18:38:20 (19:11:47) hours (snapshots taken if necessary). So I've looked in BT's task properties
Name famous_s303_599_200_000222072_1
CPU time at last checkpoint 14d,02:58:24
CPU time 18:38:20
Elapsed time 19:11:47
Estimated time remaining 01d,02:36:25
Fraction done 92.972 %
And again now:
CPU time at last checkpoint 14d,21:02:11
CPU time 18:38:20
Elapsed time 19:11:47
Estimated time remaining 12:13:06
Fraction done 96.805 %I'll try to let it run...
...suddenly it's fine, at least the Tasks tab's Elapsed column (like 15d,10:02:43 (14d,21:09:47) a moment later), but it was not really in the properties window:
CPU time at last checkpoint 14d,21:02:11
CPU time 18:38:20
Elapsed time 19:11:47
Estimated time remaining 12:12:59
Fraction done 96.806 %
and again wrong in the Tasks tab after suspending the task.
OK, it seems like the CPU time is constantly wrong in the Properties, and also wrong in the Elapsed column, while the task is not running.
Quote from: Pepo on November 15, 2010, 11:37:41 AM
OK, it seems like the CPU time is constantly wrong in the Properties, and also wrong in the Elapsed column, while the task is not running.
That's why I proposed to show checkpoints only on running tasks. Values in other states may be unpredictable.
Quote from: fred on November 15, 2010, 11:49:41 AM
Quote from: Pepo on November 15, 2010, 11:37:41 AM
OK, it seems like the CPU time is constantly wrong in the Properties, and also wrong in the Elapsed column, while the task is not running.
That's why I proposed to show checkpoints only on running tasks. Values in other states may be unpredictable.
How should (current_cpu_time-checkpoint_cpu_time) value differ between running and other states? What should be predicted there?
The Properties' values are interestingly wrong too...
0.86 behaves similarly. I've checked also the 0.84 and 0.83: Properties wrong the same way, but in the Tasks tab, CPU and checkpoint are fine, just the elapsed wall-clock time is wrong (19:11:47). Interestingly a Collatz task (around 1d2h) and PrimeGrid task (3 1/2 days) are everywhere displayed correctly, also in Properties.
Quote from: Pepo on November 15, 2010, 12:11:52 PM
Interestingly a Collatz task (around 1d2h) and PrimeGrid task (3 1/2 days) are everywhere displayed correctly, also in Properties.
OK, to be fair to the CPDN task, I can now see also a waiting Collatz task with highlighted [
0] 01d,02:37:36 in Checkpoint column, following (apparently correct?) could be seen in the Properties:
CPU time at last checkpoint 01d,02:37:36
CPU time 01d,00:53:03
Elapsed time 01d,02:20:55
Estimated time remaining 01:03:18
Fraction done 96.388 %
Perhaps an overflow by a number of days, or what?
Quote from: fred on November 15, 2010, 11:49:41 AM
Quote from: Pepo on November 15, 2010, 11:37:41 AM
OK, it seems like the CPU time is constantly wrong in the Properties, and also wrong in the Elapsed column, while the task is not running.
That's why I proposed to show checkpoints only on running tasks. Values in other states may be unpredictable.
This makes sense to me. Maybe that's why the last value of a task as it's ending gives such a crazy checkpoint value: because it's not actually running anymore?
Quote from: Beyond on November 15, 2010, 05:08:06 PM
Quote from: fred on November 15, 2010, 11:49:41 AM
Quote from: Pepo on November 15, 2010, 11:37:41 AM
OK, it seems like the CPU time is constantly wrong in the Properties, and also wrong in the Elapsed column, while the task is not running.
That's why I proposed to show checkpoints only on running tasks. Values in other states may be unpredictable.
This makes sense to me. Maybe that's why the last value of a task as it's ending gives such a crazy checkpoint value: because it's not actually running anymore?
NO! Because it is incorrectly calculated. Or read from the protocol data. Or the RPC protocol contains wrong data. Or whatever else? Because I can not imagine how could be the (current_cpu_time-checkpoint_cpu_time) value incorrectly calculated.
Note that the BOINC Manager has both values correct at the same moment in the Task Properties dialog, while the BT's Properties sometimes shows crazy elapsed + cpu values, which are the source of the checkpoint column. And both BM and BT read the same GUI RPC data streams.
Quote from: Pepo on November 15, 2010, 12:11:52 PM
Interestingly a Collatz task (around 1d2h) and PrimeGrid task (3 1/2 days) are everywhere displayed correctly, also in Properties.
OK, to be even more fair to the CPDN task, I can now see also the PrimeGrid task waiting with highlighted [
0] 03d,16:30:02 in Checkpoint column, following (apparently correct?) could be seen in the Properties:
CPU time at last checkpoint 03d,16:30:02
CPU time 03d,13:06:42
Elapsed time 03d,18:24:29
Estimated time remaining 01d,18:55:47
Fraction done 75.260 %
No idea what the cause could be.
Quote from: Pepo on November 16, 2010, 09:35:48 AM
Quote from: Pepo on November 15, 2010, 12:11:52 PM
Interestingly a Collatz task (around 1d2h) and PrimeGrid task (3 1/2 days) are everywhere displayed correctly, also in Properties.
OK, to be even more fair to the CPDN task, I can now see also the PrimeGrid task waiting with highlighted [0] 03d,16:30:02 in Checkpoint column, following (apparently correct?) could be seen in the Properties: CPU time at last checkpoint 03d,16:30:02
CPU time 03d,13:06:42
Elapsed time 03d,18:24:29
Estimated time remaining 01d,18:55:47
Fraction done 75.260 %
No idea what the cause could be.
But as you can see the CPU time at last checkpoint is higher than the CPU time. ???
This should be impossible, as the checkpoint is always in the past. The value should be the last check point CPU time, this can never be more than the CPU time.
The value shown in this case is the Checkpoint time.
Quote from: Beyond on November 14, 2010, 05:10:14 PM
2) MW tasks run for 3-4 minutes on my systems. My checkpoint warning triggers are set at 5, 10 & 20 minutes. About 40% of the time the last BT update period shows a checkpoint time of over 20 minutes and thus flashes the > 20 minute warning color. Don't know where this erroneous checkpoint time is coming from but it can't be correct to show a > 20 minute checkpoint time on a 3 minute WU. I have set custom global checkpoints in config.xml.
I just checked the checkpoints:
The xml values will override the default settings.
The xml is read sequentially, so the LAST command in the list that matches will be the one used.
So don't place global expressions at the end, but at the beginning. See example: http://www.efmer.eu/forum_tt/index.php?topic=503.0 (http://www.efmer.eu/forum_tt/index.php?topic=503.0)
in previous versions I said that there was a nasty bug, which didn't say anything but closes BT, now I suspect how is.
two computers running BT in one x64 (no problem about OS XP or win 7 Pro) in the other x32 (XP pro SP3 x32) both of them working marvellous, and both computers looking at each other and another computers attached too, same computers controlled from both computers.
for any reason I have to restart the x64 machine, when this happens and the x64 machine is starting, the program in the x32 machine crashes silently and without any window, message, etc.
If I restart immediately that the crash has happened, sometimes crashes again as before, silently, if I wait until the BT in the x64 machine is up and running, restarted the BT x32 and no problem.
strange problem ?? ?? ?? ??
Quote from: Corsair on November 16, 2010, 10:26:18 AM
in previous versions I said that there was a nasty bug, which didn't say anything but closes BT, now I suspect how is.
two computers running BT in one x64 (no problem about OS XP or win 7 Pro) in the other x32 (XP pro SP3 x32) both of them working marvellous, and both computers looking at each other and another computers attached too, same computers controlled from both computers.
for any reason I have to restart the x64 machine, when this happens and the x64 machine is starting, the program in the x32 machine crashes silently and without any window, message, etc.
If I restart immediately that the crash has happened, sometimes crashes again as before, silently, if I wait until the BT in the x64 machine is up and running, restarted the BT x32 and no problem.
strange problem ?? ?? ?? ??
No dump file at all?
Quote from: fred on November 16, 2010, 09:40:53 AM
Quote from: Pepo on November 16, 2010, 09:35:48 AM
Quote from: Pepo on November 15, 2010, 12:11:52 PM
Interestingly a Collatz task (around 1d2h) and PrimeGrid task (3 1/2 days) are everywhere displayed correctly, also in Properties.
OK, to be even more fair to the CPDN task, I can now see also the PrimeGrid task waiting with highlighted [0] 03d,16:30:02 in Checkpoint column, following (apparently correct?) could be seen in the Properties: CPU time at last checkpoint 03d,16:30:02
CPU time 03d,13:06:42
Elapsed time 03d,18:24:29
Estimated time remaining 01d,18:55:47
Fraction done 75.260 %
No idea what the cause could be.
But as you can see the CPU time at last checkpoint is higher than the CPU time. ???
This should be impossible, as the checkpoint is always in the past. The value should be the last check point CPU time, this can never be more than the CPU time.
The value shown in this case is the Checkpoint time.
I've noticed it. So, to to compare apples to apples, I've switched to hhh:mm:ss notation and here are the task's Properties from BT:
CPU time at last checkpoint 88:30:02
CPU time 85:06:42 <=-
Elapsed time 90:24:29 <=-
Estimated time remaining 42:55:47
Fraction done 75.260 %
and from BM:
CPU time for last checkpoint 88:30:02
CPU time 88:42:43
Elapsed time 94:03:36
Estimated time remaining 42:55:47
Fraction done 75.260 %
Immediately after forcing the task to run and 5-6 seconds later on next display refresh, BT's Elapsed time column value will immediately change from "90:24:29 (85:06:42)" to "94:03:42 (88:42:48)" and Checkpoint column to "[
0] 00:12:45".
Therefore I believe that something in BT's internals gets vice-versa when displaying the elapsed+cpu times and thus also the checkpoint difference gets wrong.
Quote from: Pepo on November 16, 2010, 10:40:36 AM
Immediately after forcing the task to run and 5-6 seconds later on next display refresh, BT's Elapsed time column value will immediately change from "90:24:29 (85:06:42)" to "94:03:42 (88:42:48)" and Checkpoint column to "[0] 00:12:45".
Therefore I believe that something in BT's internals gets vice-versa when displaying the elapsed+cpu times and thus also the checkpoint difference gets wrong.
I found one problem, the time in task properties wasn't always correct, sometimes it was way to high.
The value for the warning calculations was correct.
And I found another one, when not running, the elapsed time may be incorrect. And the checkpoint may be incorrect as well.
Quote from: fred on November 16, 2010, 10:30:22 AM
No dump file at all?
Nope, nothing at all, crash folder empty. :'(
Quote from: fred on November 16, 2010, 10:15:33 AMThe xml values will override the default settings.
The xml is read sequentially, so the LAST command in the list that matches will be the one used.
So don't place global expressions at the end, but at the beginning. See example: http://www.efmer.eu/forum_tt/index.php?topic=503.0 (http://www.efmer.eu/forum_tt/index.php?topic=503.0)
By golly it worked. Thanks!