Messages

[In progress]

Hello,

Looks like BoincTasks doesn't always show correct info on Status-column of the Projects-tab. For example, at the moment WUProp@Home scheduler is not responding (incorrect DNS resolution) and BoincTasks shows:

WUProp@Home ... Deferred for: 00:53:50, In progress

Looking boinccmd --get_project_status output for the same project:

1) -----------
   name: WUProp@Home
...
   nrpc_failures: 8
   master_fetch_failures: 0
   master fetch pending: no
   scheduler RPC pending: yes
   trickle upload pending: no
   attached via Account Manager: yes
   ended: no
   suspended via GUI: no
   don't request more work: no
   disk usage: 0.000000
   last RPC: 1408626277.443256
   project files downloaded: 0.000000

And project info in client_state.xml shows:

<project>
    <project_name>WUProp@Home</project_name>
...

    <nrpc_failures>8</nrpc_failures>
    <master_fetch_failures>0</master_fetch_failures>
    <min_rpc_time>1408805030.526604</min_rpc_time>
    <next_rpc_time>1408629877.443256</next_rpc_time>
    <sched_rpc_pending>7</sched_rpc_pending>
    <non_cpu_intensive/>

Now, the BT Deferred status is correct but RPC is not "In progress" but rather RPC is "Pending" and the reason code 7 means "Project Requested" as defined in http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=blob;f=lib/common_defs.h;hb=HEAD#l193.  I've also sometimes seen "sRPCp 3" status, which might mean BT doesn't also understand the reason code 3, which is explained in the same header. (RPC for this project is pending because "Need work".) Could you make sure these defines are correctly taken into account for BT Status-column? Thanks!

BTW, there's also upload pending and it's status is shown correctly on Transfers tab:

WUProp@Home ... Upload pending (Project backoff: 00:46:21)

Tried to upgrade to TT 7.51 and noticed that it keeps moving the small temperature graph window to my main monitor. I suspect this has something to do with the 7.50 change where you try to make sure the location is sane. Unfortunately, it seems it now considers my secondary monitor as "invalid" and resets the position everytime the program starts. I usually keep the graph at lower right corner of my second monitor that's on the left of my main monitor. This probably means the start position is negative..

Also, dragging the graph is hard since it seems like the mouse keeps dropping the graph in middle of drag operation (no, I don't release the mouse).

Assume the BIOS (AMI 0901 dated July 5, 2011) is looking at a temperature sensor, so I'm asking if Tthrotle can be exanded to cover the Mobo?

No, it's simply too much work to adapt to all kinds of motherboard. Simply too much work for me to handle.

I've been using little utility known as SpeedFan, that has already done "adapting for different mobos" thing. It can usually find and show all the temperature readings that are available on a system and is been enhanced to work with more and more monitoring chips. IIRC, it does have some features to deal with "too high" temps but not necessarily throttling. But at least you can keep an eye on the mobo temp with that.

Unable to  connect via BOINC Manager after turning Firewall off on all three systems. Looks like the problem is with BOINC instead of BoincTasks. I can PathPing in one hop to any of the other two systems.

This sounds like there is a firewall or port restrictions on the PK5000 modem. Have you verified that part?

Now you tell me, had only 5 BSOD, due to some minor bug.

Hehe, so you know well why I was scared. I just did try v4.20 on my main system and it seems to be stable so far. I had TThrottle uninstalled for a while to see if it was causing my BSODs after hibernation but turns out it didn't. Must be that known bug on Vista and 7 where it crashes because BIOS uses some restricted memory area during sleep.

I'm still having issues.  If I set eFMer Priority to normal for the dnetc*.exe in Moo! Wrapper the GPU usage stays unchanged at around 70%.  Process priority still says low in Task Manager.  If I set the process priority to normal in Task Manager the GPU usage jumps to an average of about 95%.

Both the wrapper and the child process (dnet client) set their own process and thread priorities (during startup), which should be correct for them. Dnet client will always use low process priority but bumps it's thread priorities up according to internal logic.

If you are still having problems with getting your GPU up to full speed, you might want to try changing priority in the dnet client config (you will need to use anonymous platform to safely edit the config file) and see if that helps.. It is set to 4 by default, which is what is recommended on Windows to keep GPU fully loaded.

What I'm working on right now is moving the regulator to the driver. Lots of interesting work , this should also eliminate any access problems in Win 7.

More code in kernel mode of the driver? Sounds scary.. you need to be extra careful for not introducing any bugs when coding in that area.

1 CPU + 1 GPU tasks are running. After snoozing the whole computation, the machine goes correctly silent. Just the logging:

----------------------------------------------------------------------------------------------------------------------------------------------
30 March 2011 - 01:43:21  Počet zhodných programov (procesov): 1
Suspended: CPU:0, GPU:1, PID:8408 (0)   Slot:4   http://boinc.thesonntags.com/collatz/   collatz_2368747883356106762600_824633720832
CPU:1, GPU:0, PID:12956 (3)   Slot:1   http://boinc.thesonntags.com/collatz/   collatz_2368747395894498535784_103079215104
----------------------------------------------------------------------------------------------------------------------------------------------

For some reasons, the GPU tasks are still handled differently.
The GPU task is gone, as there are 0 threads running, but the CPU task is still there, 3 threads.

I believe what you are seeing is the difference between GPU and CPU tasks suspending when it comes to the "leave applications in memory when suspended" parameter. GPU tasks are never left in memory but are always fully shutdown. (To free up any GPU memory and other resources to, for example, a resource hungry game.) CPU tasks can be left in memory (if enabled by the parameter), just waiting to be re-enabled to get going again. This happens no matter what the suspend reason of a task is.

[wicked]

Maybe a request for the project, to update their application.

Maybe wicked could also know something about...

Sorry, I'm not sure I follow you. About what?

I think I added checkpoint notifications from the wrapper to BOINC Client. I based my work on the sample wrapper provided in BOINC because DNETC wrapper code is not public, AFAICS. So I don't know what they do or don't do these days. However, looking at their latest control file at http://dnetc.net/download/job_2.56.xml they enable Distributed.net checkpoints but not the automatic wrapper checkpoint feature.

You could try to enable <app_msg_receive> logging in BOINC Client and see what numbers DNETC wrapper reports (sometimes funky ones) to the BOINC Client. There's also one value that's not reported from it but rather BOINC Client calculates it on behalf of the wrapper/application. Unfortunately, I don't remember what each of these values were out of my head.

I do remember that there has been a bug in BOINC Client (on the application API part, I think) that affected it's calcuation whenever a task is restarted after checkpointing.

snoozed GPU - as this DNETC task disappeared, BT immediately fell back to normal. Starting any other GPU task or the same DNETC task again (surely from zero, as they do not checkpoint) was fine.

No, not from zero. DNETC tasks have been using the checkpoint feature of Distributed.net clients. Although, they don't seem to always report this correctly to BOINC Client (via their wrapper). Also, there have been some known bugs in their wrapper implementation that can cause erratic reporting of progress. I've fixed them myself (and rewritten the wrapper logic quite a bit, including handling a hang during start) and BT has been behaving for me.

Maybe BT goes overdrive when it sees strange progress numbers or things "closing to 100%" readiness?

1) When the computer goes off line, there may be some longer delays. The computer has to timeout first. After a couple of times the computer is regarded disconnected and things should go back to normal.
2) The update counter is linked to the last time it refreshed (wall clock) and the number of tasks, the more the slower it gets.
You may see the update of the history refresh. The history refresh is depended on the remaining time and has a maximum of 30 or 1/2 the expected remaining time.

1) Is the lightning symbol appearing at the same time host is timed out? So that when I see the lightning symbol, the computer should be in disconnected state and not part of the updating? Because the symbol was already there when the switching was delayed. It could have been that the reconnect time had passed when I tried. Or will tab switching always trigger a retry attempt?

Maybe regular updating and tab switching should be separated from the reconnection attempts? They should probably happen according to schedule and on background thread, IMHO. Additionally, an implicit menu command could be run by the user to trigger backgroun retry attempt (no "hidden" triggering for seemingly unrelated actions).

2) BT seems to go on overdrive sometimes (like it is at the moment) and is updating something every second. It claims to only have 36 tasks to update and I'm still only selecting only one computer (out of three that are all online). BT transfers about ~145kB total per second from all three hosts. That seems a bit excessive, although does seem to be affected according to number of tasks on the host. I guess this is history fetching that now gueries all tasks every second?

BT is on overdrive but the switching seems to be fast at the moment so I guess these are unrelated problems.

Is there anyone else, who recognizes these problems.

Oh yes, I've been haunted by "Switched, busy..." messages with BT. I currently have 1 external and 2 local machines monitored. (And 4 external that are ticked off in Computers-tab.) Machines can sometimes be slow to respond or even off line. This seems to especially happen when there are machines off line, even if it's one of the local ones.

I could actually just reproduce this as the external machine is off line. When I switch to Transfers-tab, it took a lot of time for the Switched-message to go away and BT to show an empty screen. It's like it's waiting a lot of time to give up on the offl ine machine.. I have only one of my local one selected for display, though. And it seems to have only happened once as now the subsequent switches are fast again.

There's another symptom I have seen that may or may not be related. Sometimes on Tasks-tab I see status line to show "Update in 6 seconds" then "Updating..." then "Update in 5 seconds" then "Updating..." again and then "Update in 4 seconds" followed by "Updating..." until countdown goes to 1 and then starts over. I have set refresh rate to Slow. I think this was associated with constant ~200kB network transfer rate I was seeing while back in BT.. (This was with all machines on line so 5 external were getting lot of traffic targeted to them.)

In 2.2 I added a switch in the tthrottle.xml, set to 1 should get a reading of 1.

Indeed, it does seem to limit TThrottle to only find and report one ATI card. Thanks!

I wonder if it's is related to this problem:
http://www.efmer.eu/forum_tt/index.php?topic=512.0

Perhaps, but I can only see my ATI temp reported when I hover over the icon. However, I have two nVidia cards and one ATI and ATI one is the last one listed on the gadget.

Does the ATI temp get reported correctly in BoincTasks or does it show up as the same temp as one of the NVidia cards?

Usually yes but looks like BT v0.72 can get confused when an ATI task gets suspended and then resumed. I just saw it reporting my second nVidia temp as the (only) ATI card temp but after a while it corrected itself (maybe after few more suspends/resumes or tasks completing). I also haven't verified if it works correctly when one task uses both nVidia cards (or other way in my other comp that has two ATI cards and only one nVidia).

Hi,

I'm test TThrottle 2.10.1 on a system that has one ATI Radeon HD5870 based card installed. It also has two nVidia GeForce GTX285 based cards. Whenever I connect my two monitors to the ATI card, TThrottle incorrectly detects two ATI cards and reports two, almost identical, temperatures in addition to the different nVidia temperatures. If I remove the second monitor (actually move it to one of the nVidia cards) TThrottle detectes correctly only one ATI card.

Here's a log excerpt from TThrottle, when I start it with two monitors connected:

Code Select Expand

29 August 2010 - 14:29:32 Driver installed properly. Driver Version: 2.0

Program version: 2.10 64Bit
Microsoft  (build 7600)

nvidia: found 2 logical devices
nvidia: found 2 physical devices
nvidia: Temperature 64 °C, max Temperature 191 °C
nvidia: Temperature 74 °C, max Temperature 191 °C

nvidia: GeForce GTX 285, GeForce GTX 285
Amd/Ati: found 2 devices
Amd/Ati: ASUS EAH5870 Series P (0-2)
29 August 2010 - 14:29:32 AdapterInfo: 0-2, Index: 2, ASUS EAH5870 Series
Pos: 0, Temperature: 90
Amd/Ati: ASUS EAH5870 Series P (1-3)
29 August 2010 - 14:29:32 AdapterInfo: 1-3, Index: 3, ASUS EAH5870 Series
Pos: 1, Temperature: 90

And here's a log excerpt when I start TThrottle with only one monitor connected (simply removed the monitor, no reboot, only restarted TThrottle to make it detect things again):

Code Select Expand

29 August 2010 - 14:40:10 Driver installed properly. Driver Version: 2.0

Program version: 2.10 64Bit
Microsoft  (build 7600)

Language: User: 1035 FIN ,System: 1035 FIN
Language: User: 1033 ENU ,System: 1033 ENU

nvidia: found 2 logical devices
nvidia: found 2 physical devices
nvidia: Temperature 64 °C, max Temperature 191 °C
nvidia: Temperature 74 °C, max Temperature 191 °C

nvidia: GeForce GTX 285, GeForce GTX 285
Amd/Ati: found 1 devices
Amd/Ati: ASUS EAH5870 Series P (0-2)
29 August 2010 - 14:40:10 AdapterInfo: 0-2, Index: 2, ASUS EAH5870 Series
Pos: 0, Temperature: 88