Changing the priority in "Expert" doesn't change the priority (according to task manager). Do I need a different way to see the thread priority? Task manager always says boinctasks64.exe is at "normal".
Quote from: Beyond on May 13, 2011, 12:23:45 PM
Changing the priority in "Expert" doesn't change the priority (according to task manager). Do I need a different way to see the thread priority? Task manager always says boinctasks64.exe is at "normal".
It does, but the manager doesn't show threads. Use a e.g. Priority64.exe
Quote from: fred on May 13, 2011, 10:33:43 AM
Add: Debug logging option: snooze.
Where? I was looking around hard, but... ???
[edit]OK, I've found it in
BoincTasks\examples\log\log.xml (maybe it now the time to unify it with
C:\Program Files\eFMer\BoincTasks\log\xlog.xml)? They are actually duplicates). The "
</snooze>" closing tag is missing a slash and it is being ignored without![/edit]
Quote from: fred on May 13, 2011, 10:33:43 AM
Changed: Icon now blinks orange for Gpu snoozing.
I've started the 1.03 while GPU was snoozed. The icon kept solid white, although the icon's context menu correctly displayed some 1:43:25 snooze countdown.
After a BT restart a half hour later, the context menu (took some 10+ seconds to pop up) correctly displayed a snoozed GPU countdown (1:18:15), but it took the icon an additional 10 seconds to start flashing orange. Now it correctly recognizes the changes (GPU snoozed / resumed) in few seconds.
Let's see in a few days.
Quote from: Pepo on May 13, 2011, 01:43:10 PM
I've started the 1.03 while GPU was snoozed. The icon kept solid white, although the icon's context menu correctly displayed some 1:43:25 snooze countdown.
After a BT restart a half hour later, the context menu (took some 10+ seconds to pop up) correctly displayed a snoozed GPU countdown (1:18:15), but it took the icon an additional 10 seconds to start flashing orange. Now it correctly recognizes the changes (GPU snoozed / resumed) in few seconds.
Let's see in a few days.
There is of course some delay, as a real time check takes up a lot of CPU time.
Quote from: fred on May 13, 2011, 02:36:10 PM
Quote from: Pepo on May 13, 2011, 01:43:10 PM
I've started the 1.03 while GPU was snoozed. The icon kept solid white, although the icon's context menu correctly displayed some 1:43:25 snooze countdown.
After a BT restart a half hour later, the context menu (took some 10+ seconds to pop up) correctly displayed a snoozed GPU countdown (1:18:15), but it took the icon an additional 10 seconds to start flashing orange.
There is of course some delay, as a real time check takes up a lot of CPU time.
Sure, this would be too consuming.
Does BT contain two different triggers for the state? One to display the snooze countdown in tray context menu, another to log and let the icon blink?
According to the log, the <snooze> states' recognition happens approx. "each sometimes" (being either 62 sec, 32 sec or 8 sec). What does this interval depend on?
Quote from: Pepo on May 13, 2011, 02:43:45 PM
Sure, this would be too consuming.
Does BT contain two different triggers for the state? One to display the snooze countdown in tray context menu, another to log and let the icon blink?
According to the log, the <snooze> states' recognition happens approx. "each sometimes" (being either 62 sec, 32 sec or 8 sec). What does this interval depend on?
The blinker is an independent timer, the update is on a regular interval, probably more frequent when BT is shown.
The log is in the refresh callback loop, so at that point the state should change almost immediately..
Quote from: Pepo on May 13, 2011, 01:43:10 PM
Let's see in a few days.
Some time ago (at least 5-10 minutes, at most 2 hours) the tray icon got out of sync and stays solid orange. Since your last post (when the icon still worked), the GPU was in 3 hours snooze state, 40 seconds enabled, 1 hour snoozed, 3 minutes enabled. The system was sometimes short on memory and constantly paging the last 40 minutes, if it matters (I hope it should not).
The log is still in sync. But there is no info about the icon.
Quote from: fred on May 13, 2011, 02:51:05 PM
The blinker is an independent timer, the update is on a regular interval, probably more frequent when BT is shown.
The log is in the refresh callback loop, so at that point the state should change almost immediately..
Can you occasionally check the timer's state too and add it to the log? I could at least try to correlate any changes to what happened at the time...
Quote from: Pepo on May 13, 2011, 07:01:00 PM
Some time ago (at least 5-10 minutes, at most 2 hours) the tray icon got out of sync and stays solid orange. Since your last post (when the icon still worked), the GPU was in 3 hours snooze state, 40 seconds enabled, 1 hour snoozed, 3 minutes enabled. The system was sometimes short on memory and constantly paging the last 40 minutes, if it matters (I hope it should not).
BT was restarted less than 3 hours ago, now again solid orange.
The machine was hibernated for an hour and resumed 15 minutes ago, if it matters.
Quote from: Pepo on May 13, 2011, 09:57:32 PM
Quote from: Pepo on May 13, 2011, 07:01:00 PM
Some time ago (at least 5-10 minutes, at most 2 hours) the tray icon got out of sync and stays solid orange. Since your last post (when the icon still worked), the GPU was in 3 hours snooze state, 40 seconds enabled, 1 hour snoozed, 3 minutes enabled. The system was sometimes short on memory and constantly paging the last 40 minutes, if it matters (I hope it should not).
BT was restarted less than 3 hours ago, now again solid orange.
The machine was hibernated for an hour and resumed 15 minutes ago, if it matters.
I can't do anything without a logging.
I think I'm doing something wrong with the /location switch.
under the BoinTasks data directory done a folder named Locations
copied the actual computer.xml one to Home.xml, from the scratch dome the work.xml.
erased the computer.xml, now short-cut to boinctasks with /location home and another with /location work, and the program started with the last location saved in BT, why?? don't know probably I'm doing something wrong.
now I have another problem, the router, this is new because of the exchange of speed in the ISP, don't let forward port or don't know how to do it, but only one computer could be redirected, marvellous. >:( >:( >:(
Quote from: Corsair on May 14, 2011, 10:39:42 AM
I think I'm doing something wrong with the /location switch.
under the BoinTasks data directory done a folder named Locations
copied the actual computer.xml one to Home.xml, from the scratch dome the work.xml.
erased the computer.xml, now short-cut to boinctasks with /location home and another with /location work, and the program started with the last location saved in BT, why?? don't know probably I'm doing something wrong.
now I have another problem, the router, this is new because of the exchange of speed in the ISP, don't let forward port or don't know how to do it, but only one computer could be redirected, marvellous. >:( >:( >:(
Looks like a bug? :o
Quote
Fixed: Add project, isn't possible when there no projects on any computer.
I have to still select any project from any computer, otherwise add project window do not show up.
Quote from: miky on May 14, 2011, 04:31:55 PM
I have to still select any project from any computer, otherwise add project window do not show up.
Ok, I'll do some more testing on a blank computer.
Quote from: fred on May 14, 2011, 05:36:32 AM
Quote from: Pepo on May 13, 2011, 09:57:32 PM
BT was restarted less than 3 hours ago, now again solid orange.
The machine was hibernated for an hour and resumed 15 minutes ago, if it matters.
I can't do anything without a logging.
I've uploaded all 1.03 log files to SK lang files upload area.
BTW I'd be interested to know what are you looking for in the logs - I'm not able to see anything suspicious.
Quote from: BoincTasks 1.03Sorry but BoincTasks has crashed.
Dump file:
C:\Users\...\AppData\Roaming\eFMer\BoincTasks\crash\BoincTasks_103_16-05-2011_06-24.dmp, created successfully
To help us solve this problem, please send the dump file (.dmp) per e-mail.
As the full dump was 165 MB, even compressed 34 MB, I've rather uploaded it - I assume it needs to be deleted soon because of its length.
Quote from: Pepo on May 17, 2011, 02:15:38 PM
As the full dump was 165 MB, even compressed 34 MB, I've rather uploaded it - I assume it needs to be deleted soon because of its length.
Got it and deleted.
In the history delete after time section.
But nothing definitive, may be a program problem somewhere else or a memory corruption by something.
Quote from: fred on May 17, 2011, 02:32:03 PM
Quote from: Pepo on May 17, 2011, 02:15:38 PM
As the full dump was 165 MB...
In the history delete after time section.
But nothing definitive, may be a program problem somewhere else or a memory corruption by something.
My history is 365+23, possibly some first old entries just started to get purged? ... No, the oldest ones will apparently just start to be deleted in a few days. (Or some oldest batch was already deleted and I've not noticed it.)
I'm regularly seeing Rosetta Mini CPU tasks, preempted just at 100%, still in a "Ready to run" state. (They really need just the last kick to finish, less than 1 second! >:()
In such state, like with my "casd_sr10_boinc_nmr_control.2vajA_30_abrelax_cs_frags_tex_IGNORE_THE_REST_25722_26751_0" now, BT states on the Tasks tab their "Elapsed (CPU) time" being "-(-)" (possibly because of the 100%??), "last checkpoint CPU time" is e.g. "[0] 01:51:00", ETA is "-". In the Properties window, there is no CPU time, but the checkpoint time is the same and Elapsed time is also available there - like "01:53:26". BOINC Manager displays also its CPU time (equal to the checkpoint time).
While the task is visible in the tab, BT should correctly display their Elapsed and CPU and checkpoint times...
One more crash dump (uploaded).
The message about a .dmp file being generated popped up after I've opened the tray icon's context menu. (I admit the system was pretty unstable during previous two hours - I've been punishing it ;D.) Nevertheless BT still seemed to work fine. (Possibly just some exception handler generated the dump). After confirming, one more message with exception description popped up, at the time BT closed itself.
Quote from: Pepo on April 28, 2011, 09:20:48 AM
One (http://www.chatsmileysemoticons.com/wp-content/uploads/2009/04/07-bug.gif) found:
- An errored-out (but not reported yet) task's Properties window is empty.
Something similar:
- A task, which failed to download (is similar to an errored-out task), but was also not reported yet, does show up its details in Properties window (except the state there is still "Downloading" instead of "Download failed" or so), but does not appear in History tab - possibly because of this neither in the tray icon's "Report finshed tasks" counter.
Quote from: Pepo on May 18, 2011, 09:00:37 PM
One more crash dump (uploaded).
The message about a .dmp file being generated popped up after I've opened the tray icon's context menu. (I admit the system was pretty unstable during previous two hours - I've been punishing it ;D.) Nevertheless BT still seemed to work fine. (Possibly just some exception handler generated the dump). After confirming, one more message with exception description popped up, at the time BT closed itself.
Three more crash dumps overnight ("
Sorry but BoincTasks has crashed. Dump file(s): BoincTasks_103_20-05-2011_05-59.dmp, BoincTasks_103_20-05-2011_07-12.dmp, BoincTasks_103_20-05-2011_07-45.dmp, created succesfully.") from the same BT instance - it again seemed to work until I've confirmed the dumps with OK ("boinctasks64.exe - Fatal Application Exit").
Do I have to upload (some of) them?
Again my system was low on memory - the EVO project launched 14 :o (fourteeeeeen) "20.09 LBCpp Beta" tasks in the same
.../slots/19/ - the
RunBoincWorkUnit_20.09_windows_intelx86.exe executable needs to allocate 1.7 GB of memory and the last two of them are still running and trying to grab some more RAM to proceed. My OS tried to adapt to the situation and enlarged my pagefile by 8 GB ::) AFAICT just BT and Skype did not survive.
Quote from: Pepo on May 20, 2011, 10:31:43 AM
Do I have to upload (some of) them?
Again my system was low on memory - the EVO project launched 14 :o (fourteeeeeen) "20.09 LBCpp Beta" tasks in the same .../slots/19/ - the RunBoincWorkUnit_20.09_windows_intelx86.exe executable needs to allocate 1.7 GB of memory and the last two of them are still running and trying to grab some more RAM to proceed. My OS tried to adapt to the situation and enlarged my pagefile by 8 GB ::) AFAICT just BT and Skype did not survive.
A low on memory will get you into serious problems.
I don't check for memory problems all the time. It's way to intense to check in thousands of places.
Quote from: fred on May 20, 2011, 11:38:28 AM
Quote from: Pepo on May 20, 2011, 10:31:43 AM
Do I have to upload (some of) them?
Again my system was low on memory ...
A low on memory will get you into serious problems.
I don't check for memory problems all the time. It's way to intense to check in thousands of places.
Sure. Then I'll assume it was because of lack of memory.
A few minutes ago (around 16:40) I've noticed a cryptic "20100-state" in History. I've copied the not-colored line, but a few seconds later the line completely disappeared! :o When ??? do such lines appear there?
It was a CPDN 6.09 HADAM3P EU task, Elapsed (CPU) time was "04d,21:24:36 (04d,18:39:56)", however I'm not sure, whether "20.05.11 14:38" was in the Finished or Reported column (the tabs were unfortunately replaced by spaces, but according to the number of spaces it was rather in Finished).
A counterpart Tasks line contained (a bit later): Elapsed (CPU) time = "04d,21:24:36 (04d,20:56:26)", Progress% = "62.604", Checkpoint = "[0] 00:00:06", Remaining = "03d,00:07:10", State = "Waiting to run".
OTOH, the two much different CPU times (while both Elapsed times were equal) seemed weird to me - I've compared it with BOINC Manager: Elapsed = 04d,23:19:12, CPU=04d,20:56:26 - again and still the wrong elapsed time bug (on preempted multi-day tasks) manifests itself here? :-\
Indeed!! after resuming the task, the Elapsed (CPU) time jumped to "04d,23:19:18 (04d,20:56:26)" and after suspending back to "04d,21:24:36 (04d,20:56:26)"!!
The task's last string of messages in log was:
20.05.2011 12:43:10 | climateprediction.net | [cpu_sched] Starting hadam3p_eu_2tpi_1960_1_007230948_1(resume)
20.05.2011 12:43:10 | climateprediction.net | [task] task_state=EXECUTING for hadam3p_eu_2tpi_1960_1_007230948_1 from start
20.05.2011 12:43:10 | climateprediction.net | Restarting task hadam3p_eu_2tpi_1960_1_007230948_1 using hadam3p_eu version 609
20.05.2011 12:43:17 | climateprediction.net | [task] result hadam3p_eu_2tpi_1960_1_007230948_1 checkpointed
20.05.2011 13:22:41 | climateprediction.net | [task] result hadam3p_eu_2tpi_1960_1_007230948_1 checkpointed
20.05.2011 14:04:30 | climateprediction.net | [task] result hadam3p_eu_2tpi_1960_1_007230948_1 checkpointed
20.05.2011 14:38:40 | climateprediction.net | [task] result hadam3p_eu_2tpi_1960_1_007230948_1 checkpointed
20.05.2011 14:38:40 | climateprediction.net | [cpu_sched] Preempting hadam3p_eu_2tpi_1960_1_007230948_1 (left in memory)
20.05.2011 14:38:40 | climateprediction.net | [task] task_state=SUSPENDED for hadam3p_eu_2tpi_1960_1_007230948_1 from suspend
Quote from: Pepo on May 20, 2011, 01:24:09 PM
OTOH, the two much different CPU times (while both Elapsed times were equal) seemed weird to me - I've compared it with BOINC Manager: Elapsed = 04d,23:19:12, CPU=04d,20:56:26 - again and still the wrong elapsed time bug (on preempted multi-day tasks) manifests itself here? :-\
Indeed!! after resuming the task, the Elapsed (CPU) time jumped to "04d,23:19:18 (04d,20:56:26)" and after suspending back to "04d,21:24:36 (04d,20:56:26)"!!
Possibly related - an EVO 20.09 task nearly immediately set its progress to 100%. From the moment, on the
Tasks tab the task's Elapsed time is still just 00:00:02 seconds, although the task's Properties window contains a correct elapsed time value. CPU time does increment correctly, checkpoint time correctly remains 00:00:02 (and Checkpoint column displays a correct difference value.
After suspending the task, both CPU and checkpoint time are 00:00:02 and the elapsed time is 00:00:35. After resuming the task again, its elapsed jumped back to 2 seconds, CPU is correct.
Progress still remains 100%.
Quote from: Pepo on May 20, 2011, 01:48:06 PM
Possibly related - an EVO 20.09 task nearly immediately set its progress to 100%. From the moment, on the Tasks tab the task's Elapsed time is still just 00:00:02 seconds, although the task's Properties window contains a correct elapsed time value. CPU time does increment correctly, checkpoint time correctly remains 00:00:02 (and Checkpoint column displays a correct difference value.
After suspending the task, both CPU and checkpoint time are 00:00:02 and the elapsed time is 00:00:35. After resuming the task again, its elapsed jumped back to 2 seconds, CPU is correct.
Progress still remains 100%.
I assume it is related to the Progress% and running state (fast history fetching kicks in again?) - 3 minutes after I've resumed the EVO task, BT's CPU usage jumped to 2/3 of a core and stayed for hours, with the exception of 3 minutes, while EVO task was temporarily suspended.
Quote from: Pepo on May 20, 2011, 01:24:09 PM
A few minutes ago (around 16:40) I've noticed a cryptic "20100-state" in History. I've copied the not-colored line, but a few seconds later the line completely disappeared! :o When ??? do such lines appear there?
I changed the cleanup routing to once every 5 minutes and that one removed it.
20100 = Waiting to run and shouldn't be there in the first place.
Quote from: Pepo on May 20, 2011, 04:07:16 PM
I assume it is related to the Progress% and running state (fast history fetching kicks in again?) - 3 minutes after I've resumed the EVO task, BT's CPU usage jumped to 2/3 of a core and stayed for hours, with the exception of 3 minutes, while EVO task was temporarily suspended.
The progress comes from the BOINC client and is wrong....
The CPU usage, comes from the BOINC client as well. Is the time difference over couple of seconds.
Quote from: fred on May 20, 2011, 04:12:20 PM
Quote from: Pepo on May 20, 2011, 04:07:16 PM
I assume it is related to the Progress% and running state (fast history fetching kicks in again?) - 3 minutes after I've resumed the EVO task, BT's CPU usage jumped to 2/3 of a core and stayed for hours, with the exception of 3 minutes, while EVO task was temporarily suspended.
The progress comes from the BOINC client and is wrong....
I believe it and I'm sure that the client gets it directly from EVO's wrapper (which behaves everything but correctly :))) - BOINC Manager sees the same. But the times are wrong.
QuoteThe CPU usage, comes from the BOINC client as well. Is the time difference over couple of seconds.
How this?? What time difference over few seconds? BT simply consumes that much CPU time and is totally unresponsive (like poured with glue, the same feeling like when GPU tasks are blocking everything visible)... When I suspend the EVO 100% task, BT's CPU usage goes down to 1-2% in a few seconds. When I resume the EVO task, in approx. 30 seconds BT's CPU usage goes again up and it gets slowly responsive. And suddenly makes 4 x more I/O.
One more weird problem: when in such slowly responsive state, BT is able to suspend/resume any of the running or ready-to-run tasks, but sometimes somehow can not modify the suspend/resume state of the not-yet-started (ready to start) tasks :o (I've tried to restart it a couple of times, but no joy - BOINC Manager had to help.)
I attached to the EVO project, lets see what problems I can produce.
Quote from: fred on May 21, 2011, 08:30:42 AM
I attached to the EVO project, lets see what problems I can produce.
Hmm, the EVO task crashed the BOINC client :o, it indicated a checkpoint at over an hour, but it started all over after the BOINC client was back up and running.
I see this is a Beta project, more like an Alpha project, lets wait, when they are out of Beta, to check if there are still any problems with BT.
Quote from: fred on May 21, 2011, 12:26:57 PM
Quote from: fred on May 21, 2011, 08:30:42 AM
I attached to the EVO project, lets see what problems I can produce.
Hmm, the EVO task crashed the BOINC client :o
You were warned :))
The "About BoincTasks" dialog is using own "hand with pointing finger" replacement for the default mouse cursor icon, then the cursor hovers over Translator's name (http://translator's%20name) and http://www.efmer.eu (http://www.efmer.eu) links.
Unfortunately this replacement cursor's hot spot is vertically misplaced by some 10-15 pixels, approx. to the middle of the hand. It is then visually pointing above these links.
Quote from: Pepo on May 27, 2011, 12:33:16 PM
The "About BoincTasks" dialog is using own "hand with pointing finger" replacement for the default mouse cursor icon, then the cursor hovers over Translator's name (http://translator's%20name) and http://www.efmer.eu (http://www.efmer.eu) links.
Unfortunately this replacement cursor's hot spot is vertically misplaced by some 10-15 pixels, approx. to the middle of the hand. It is then visually pointing above these links.
I moved the bitmap down, so the finger is more to the middle.