Posts by Jeff Buck


log in
1) Message boards : Number crunching : GUPPI Rescheduler for Linux and Windows - Automatically move GUPPI work to CPU and non-GUPPI to GPU (Message 1805209)
Posted 1 day ago by Profile Jeff Buck
[More people will probably use the default program location, but a high proportion of your target audience will have relocated the DATADIR, either to reduce wear and tear on an SSD system disk, or simply to avoid data loss when periodically nuking their Windows installation. I don't know why, but that's what they do.]

Even for those using the default DATADIR location, it's different on an XP system than on later Windows systems, so a hard-coded "C:\ProgramData\BOINC" isn't going to work for those users. Registry lookup is really the only way to go.
2) Message boards : Number crunching : USB Risers (Message 1804103)
Posted 7 days ago by Profile Jeff Buck
Bottom line.....I have no idea what that's all really telling me. ;^)

Maximum power usage is around 72% of the maximum possible, so around 43W according to GPU-Z.

Yeah, but that's inconsistent with what Kill-A-Watt was showing me, where just the increase in power usage from the previous GT630 card to the GTX750Ti was in the 39-51W range. So, even if the GT630 was only using, say, 15 watts, the total for the 750Ti would be in the 54-66W range. I suspect that some of these factory-overclocked cards actually consume more power than the reference wattage that NVIDIA provides.

Oh, well, I mainly just care about the total wattage for each box and what that does to my electric bill, which I'll think about another day. It's past this old man's bedtime. ;^)
3) Message boards : Number crunching : USB Risers (Message 1804095)
Posted 7 days ago by Profile Jeff Buck
Okay, I just looked at the GPU-Z numbers for all 3 of my 750Tis and can't relate them to much of anything. The PNY that I just installed on 6949656 showed an average GPU Load of 99% running one guppi VLAR and one non-VLAR, with a power range of 35.1% to 65.9% TDP. When the VLAR finished and a non-VLAR took its place, the GPU Load dropped to 96% and the power increased to a range of 53.5% to 71.9%.

On my host 6980751 which has two 750Tis (both EVGA, but with different base clocks) and two GTX 660s, each of which is running 3 tasks at a time (which happen to all be non-VLARs at the moment), one 750Ti has a GPU Load of 86%, with power ranging from 48.6% to 71.7% TDP. The other has a GPU Load of 85%, with power ranging from 40.0% to 71.7% TDP.

Bottom line.....I have no idea what that's all really telling me. ;^)
4) Message boards : Number crunching : BoincLogX: where are the logs hiding? (Message 1804058)
Posted 7 days ago by Profile Jeff Buck
The BoincLogX logs are where You put them...

Not if Windows decides you don't have administrative authority to put them there (such as in a Programs folder, as you noted), in which case they sometimes wind up in an alternate "Virtual Store" reality, which appears to be what happened in this case. It's a User Account Control thing. The program still thinks it's writing them to the user- or application-specified folder and, in most cases, can still read them, but if you go looking for them in Windows Explorer, they don't appear to exist. That drove me crazy when I first started using Windows Vista, but UAC was such a headache for so many reasons, I finally just turned it off. Virtual Store problem solved.

Make your own directory (e.g. C:\Programs_XP) and install old programs there.

Yep, if you make your own, hopefully UAC will let you and your programs write to it.
5) Message boards : Number crunching : USB Risers (Message 1804032)
Posted 7 days ago by Profile Jeff Buck
I don't think I've ever paid attention to what the Max TDP percent was. I just used my Kill-A-Watt to check changes in total wattage used.

It would be interesting to see just how the GPU-Z % of max TDP values and the Kill-A-Watt readings compare.
My UPS gives me load readings, but they vary depending on whether it's on mains power or battery. And even then it gives the load in 13W increments. Not very useful.
:-/

Yeah, I'd probably have to swap cards in and out to do that kind of comparison, so not something likely to happen. When I'm replacing a card, I usually just take a Kill-A-Watt reading before and after. For instance, on the recent replacement of the GT630 with the GTX750Ti on host 6949656, under the GT630 configuration the host was using ~139-144W total, while the initial reading on the GTX750Ti configuration showed ~182-191W total, in both cases only running 1 task at a time on the GPU. Bumping that up to 2 tasks at a time on the 750Ti didn't seem to change the power usage that much, but the range widened slightly, to ~178-195W total.

If I think of it later, I'll check the current max TDP when that box starts back up again this evening. (All my crunch-only machines take a 5 hour break starting in late afternoon, to avoid the "peak period" electric rates.) I'll probably also check where the GPU Load is at, and whether or not increasing to 3 at a time makes sense on that host. Even with rescheduling as many VLARs to the CPU as the two cores can reasonably handle, the GPU is still having to crunch an awful lot of those suckers.
6) Message boards : Number crunching : USB Risers (Message 1804027)
Posted 7 days ago by Profile Jeff Buck
I'm pretty sure mine are drawing closer to 60 watts when crunching flat out, as I recall that when I replaced a GT 640 with an EVGA 750Ti (in September, 2014), my power use went up by 4-5 watts, instead of going down by about that amount, as I had expected. I also just replaced a passively-cooled GT 630 (very low power usage) with a PNY 750Ti several days ago, and the draw increased by about 45-50 watts.

Did you check the older cards, and the current GTX 750Ti, with GPU-Z (or similar) to see what the load on the cards was/is?

As far as GPU Load goes on the 2 older cards, I've generally been able to keep them at about 92-98%. Under S@h v7, that was running 2 tasks at a time, but with v8, it initially dropped into the mid-80s, so then I switched to 3 at a time. Now, with the VLARs on GPUs, I don't know where I'm at, so I'll have to check it all again some time. I haven't, however, checked the load on the new card yet, and I don't think I've ever paid attention to what the Max TDP percent was. I just used my Kill-A-Watt to check changes in total wattage used.
7) Message boards : Number crunching : USB Risers (Message 1804016)
Posted 7 days ago by Profile Jeff Buck
There was a whole thread on the 750Ti a while back, The GTX750(Ti) Thread. Perhaps there's some power draw info in there. I'm pretty sure mine are drawing closer to 60 watts when crunching flat out, as I recall that when I replaced a GT 640 with an EVGA 750Ti (in September, 2014), my power use went up by 4-5 watts, instead of going down by about that amount, as I had expected. I also just replaced a passively-cooled GT 630 (very low power usage) with a PNY 750Ti several days ago, and the draw increased by about 45-50 watts.
8) Message boards : Number crunching : Ongoing computation errors (Message 1803988)
Posted 7 days ago by Profile Jeff Buck
Yep, you're getting the "-1073741205 (0xc000026b)" error (aka: 3221226091 (0xc000026b)). The simplest workaround currently is just to shut down BOINC completely prior to shutting down or restarting your system. That will avoid the contention between the OS, which is busily shutting down running tasks, and BOINC, which is blissfully trying to restart them during the shutdown.
9) Message boards : Number crunching : Download old work (Message 1803985)
Posted 7 days ago by Profile Jeff Buck
Well, I went through the process but instead of shutting down BOINC I hit the "red X" in the upper right corner, which closes most other software but not BOINC. (I knew that, but it slipped my mind) Anyway, it didn't work, so I'll let these units expire and be sent to someone else. Thanks everyone for your help.

Tsk, tsk. A Jedi master who gives up so easily. Whatever is the galaxy coming to? ;^)
10) Message boards : Number crunching : Download old work (Message 1803970)
Posted 7 days ago by Profile Jeff Buck
I am doing something wrong: I hit the "Update" button numerous times and it says scheduler request completed, but the old tasks aren't coming.

It's not as simple as just hitting the "Update" button. As Claggy said, it first requires "a double reporting of a completed task". If you're not doing that each time, it won't fool the scheduler into sending the lost tasks.

There have been a couple threads on this topic earlier in the year. Specifically you could take a look at my post in Message 1798083, as well as a couple of links mentioned in that post.
11) Message boards : Number crunching : Download old work (Message 1803965)
Posted 7 days ago by Profile Jeff Buck
Do I have to wait the 5 minutes between update requests?

No, But the server will only resend 20 tasks at a time.

Claggy

Actually, I've found that the minimal 5 minute interval is necessary. Otherwise, only the task reporting happens. The scheduler refuses to send any tasks if the last request was too recent.
12) Message boards : Number crunching : Ongoing computation errors (Message 1803960)
Posted 7 days ago by Profile Jeff Buck
I've been receiving multiple computation errors on my desktop for a while now and it invariably happens when I'm required to reboot my system, but not always. I had a few system issues and had all downloaded SETI units showing a computation error a while back, but the system issue has been resolved. However this problem doesn't happen with any other project or my laptop. Today, on a required software upgrade/restart I received 25 more computation errors, some in work process, some pending and am really puzzled. Anyone else have the same issues or suggestions?

With your computer(s) hidden, it's impossible to know just what errors you're getting. However, since you say it happens only when you reboot, take a look at the 1073741205 Error Code (Unknown Error) thread and see if it applies.
13) Message boards : Number crunching : 21 ghosts (Message 1803308)
Posted 10 days ago by Profile Jeff Buck
You might try the technique that I last suggested several weeks ago in this post. It's complicated, but it does work.
14) Message boards : Number crunching : Is it possible to swap a guppi assigned to GPU with a Arecibo assigned to CPU? (Message 1802759)
Posted 13 days ago by Profile Jeff Buck
For those working on developing a VLAR rescheduler (and I know there are at least 2 of you), I want to mention a situation that I ran into on one of my own boxes last evening, which probably should be taken into consideration in a rescheduler.

I'm currently running my own little home-grown VLAR rescheduler on each of my crunch-only machines as a scheduled task at user logon. After the rescheduling is completed, the routine then launches BOINC Manager (instead of having BM launch itself at startup). Last evening, the rescheduler's log on my WinVISTA machine showed that 7 VLARs had been moved to the CPU. However, BOINC Manager was showing me that those 7 VLARs were still scheduled to run on the GPU.

I didn't have time to look into it then, but this morning I reviewed the BOINC Event Log and found a curious line:

7/14/2016 9:00:57 PM | | Using state file client_state_next.xml

It seems that when the system shut down yesterday afternoon (a normal weekday occurrence), BOINC hadn't finished cleanly writing and renaming its assorted client_state files, probably because that machine experienced one of those "restarting tasks during shutdown" episodes that has been discussed in several threads here. No tasks actually failed, but apparently the OS ultimately terminated BOINC "with prejudice" while it was still busy with client_state activities.

So, it seems that during BOINC startup, if it finds a client_state_next.xml file, it uses it to the exclusion of any client_state.xml file that exists. I think that makes sense since, assuming the client_state_next file is complete (and was cleanly closed before the previous BOINC shutdown), it would contain the most up-to-date client_state data.

Ultimately, that probably means that any alterations made to a client_state.xml file (while BOINC is shut down, of course), whether for rescheduling or any other purpose, should only be performed when a client_state_next.xml file doesn't currently exist. Food for thought! :^)
15) Message boards : Number crunching : guppie on NVIDIA cards (Message 1802185)
Posted 17 days ago by Profile Jeff Buck
With all the talk about rescheduling WUs and not having guppie's run on NVIDIA cards I would just like to share my experience.
A guppie seems to take about 30 minutes on my 750TI
A non-guppie takes about 20 minutes

A guppie on my CPU takes about 3 hours.

Why would I even want to run them on my CPU? or am I not understanding something here.

Well, I do think you're missing the point a bit. Certainly a VLAR runs faster on a GPU than on a CPU, as do non-VLARs and APs (unless you've got a really slow GPU paired with a really fast CPU). The issue is really which task type runs most efficiently on which device, assuming that you are trying to maximize the total output of your hardware and the money you're shelling out for your electricity (which is certainly my goal).

If you go back and look at the run times for various comparable tasks that I posted in Message 1799300 from my early VLAR rescheduling attempts, you can see that while VLARs run consistently slower than "normal" AR tasks on my GPUs (whether looking at the GT 630 or the GTX 670), they run consistently faster than the "normal" AR tasks on either of the CPUs shown. Therefore, if I can swap a VLAR originally assigned to a GPU with a non-VLAR originally assigned to a CPU, it's a win-win. The VLAR will finish faster than the non-VLAR would have on the CPU, while the non-VLAR will finish faster than the VLAR would have on the GPU. The end result is a significant increase in total throughput.

Now, I don't normally put much stock in the whole credit system as a reliable measurement technique but, at least in broad terms, it's probably the simplest way to see the effect of VLAR rescheduling on my boxes. I've been doing VLAR rescheduling for just about 3 weeks now, and taking a weekly RAC snapshot for my account shows:
Monday, June 20: RAC = 61,275.91
Monday, June 27: RAC = 65,050.05
Monday, July 4: RAC = 66,102.52
Monday, July 11: RAC = 70,191.34

Even allowing for the vagaries of the credit system, I think that increase in RAC shows that I'm getting a good bit more productivity out of my hardware and my electricity than I was when I was just letting the VLARs fall where they may.
16) Message boards : Number crunching : USB Risers (Message 1801586)
Posted 20 days ago by Profile Jeff Buck
I probably should have clarified in my earlier post that the riser cables I'm using are all standard PCIe ribbon cables, not the USB risers. I think they range from about 7 to 10 inches. I try to use the minimum length necessary to get the GPU where it needs to go, with no excess cable.

Since virtually all my hardware is inexpensive, pre-owned stuff, scrounged off of eBay and elsewhere, I went with the cheaper cables, too ($12 being at the high end, I think). No problems found so far in nearly 3 years of operation.

As to the Frankenbox mentioned in my earlier post, I don't know that the "eye candy" label would be particularly fitting. ;^) Inside are the GTX 780 and GTX 670, while the GTX 660 hangs out the back.

17) Message boards : Number crunching : USB Risers (Message 1801444)
Posted 21 days ago by Profile Jeff Buck
I use riser cables (not cards) on three of my boxes, two of them because there's only room for two large cards inside the box and one just because the friggin' power connector is too close to the PCIe slot for a double-wide to seat properly.

Only the one riser cable on my old T7400 is a powered riser, with the extra Molex connector. That cable connects a GTX 660 that resides outside the box, while a GTX 670 and GTX 780 are mounted in the full PCIe x16 slots. Because the power supply on that box is split into 4 rails, I had to do a lot of juggling of connectors to get an acceptable balance of power to all 3 of those cards, so the extra power through the Molex was definitely necessary for that riser. I would imagine that anyone running multiple cards on a system that's not single-rail could sometimes run into problems with powered risers if they're not careful about where the power draw for each slot and connector comes from.
18) Message boards : Number crunching : Is it possible to swap a guppi assigned to GPU with a Arecibo assigned to CPU? (Message 1801361)
Posted 21 days ago by Profile Jeff Buck
One of them indicated that the file(s?) have a different format in Win32 which I had no idea of.

I have one 64-bit and four 32-bit machines on which I've been doing VLAR rescheduling for the last couple weeks, and I haven't noticed any format differences, at least not for the client_state.xml, which is the only file that I'm touching.
19) Message boards : Number crunching : Is it possible to swap a guppi assigned to GPU with a Arecibo assigned to CPU? (Message 1800142)
Posted 26 days ago by Profile Jeff Buck
The one abnormality I've come across is that a few reassigned-to-GPU tasks take much longer!

It looks like those may be Arecibo VLARs that you moved from CPU to GPU. VLARs of any kind just don't do well on NVIDIA GPUs. I treat both GBT and Arecibo VLARs the same when it comes to rescheduling.
20) Message boards : Number crunching : Is it possible to swap a guppi assigned to GPU with a Arecibo assigned to CPU? (Message 1799736)
Posted 28 days ago by Profile Jeff Buck
I wonder if BOINC reads the latest scheduler reply file on startup to ensure that the client_state.xml is in sync with it.

I think I just answered my own question. While I was eating lunch, it occurred to me that I could use Process Monitor during a BOINC startup to see what files were actually being read by the BOINC client.

So, here's a list of all the files that the client reads from the BOINC data directory ("C:\ProgramData\BOINC\" on my daily driver) from the time the client is launched (in my case, by BOINC Manager) and the time the active tasks are up and running. I've only listed the first ReadFile for each (although cc_config appears to be read twice).

12:55:12.2982954 PM boinc.exe 8072 ReadFile C:\ProgramData\BOINC\cc_config.xml SUCCESS Offset: 0, Length: 4,096, Priority: Normal 12:55:12.5438900 PM boinc.exe 8072 ReadFile C:\ProgramData\BOINC\daily_xfer_history.xml SUCCESS Offset: 0, Length: 4,096, Priority: Normal 12:55:12.7054181 PM boinc.exe 8072 ReadFile C:\ProgramData\BOINC\account_setiathome.berkeley.edu.xml SUCCESS Offset: 0, Length: 2,625, Priority: Normal 12:55:12.7242364 PM boinc.exe 8072 ReadFile C:\ProgramData\BOINC\statistics_setiathome.berkeley.edu.xml SUCCESS Offset: 0, Length: 4,096, Priority: Normal 12:55:13.0120202 PM boinc.exe 6060 ReadFile C:\ProgramData\BOINC\cc_config.xml SUCCESS Offset: 0, Length: 4,096, Priority: Normal 12:55:13.8964257 PM boinc.exe 8072 ReadFile C:\ProgramData\BOINC\coproc_info.xml SUCCESS Offset: 0, Length: 2,666, Priority: Normal 12:55:13.9640905 PM boinc.exe 8072 ReadFile C:\ProgramData\BOINC\projects\setiathome.berkeley.edu\app_info.xml SUCCESS Offset: 0, Length: 4,096, Priority: Normal 12:55:13.9875153 PM boinc.exe 8072 ReadFile C:\ProgramData\BOINC\client_state.xml SUCCESS Offset: 0, Length: 4,096, Priority: Normal 12:55:14.0896113 PM boinc.exe 8072 ReadFile C:\ProgramData\BOINC\projects\setiathome.berkeley.edu\app_config.xml SUCCESS Offset: 0, Length: 378, Priority: Normal 12:55:14.2975966 PM boinc.exe 8072 ReadFile C:\ProgramData\BOINC\global_prefs_override.xml SUCCESS Offset: 0, Length: 1,480, Priority: Normal 12:55:14.3439112 PM boinc.exe 8072 ReadFile C:\ProgramData\BOINC\global_prefs.xml SUCCESS Offset: 0, Length: 1,407, Priority: Normal 12:55:14.3635428 PM boinc.exe 8072 ReadFile C:\ProgramData\BOINC\slots\2\boinc_task_state.xml SUCCESS Offset: 0, Length: 539, Priority: Normal 12:55:14.3641406 PM boinc.exe 8072 ReadFile C:\ProgramData\BOINC\slots\1\boinc_task_state.xml SUCCESS Offset: 0, Length: 538, Priority: Normal 12:55:14.3646406 PM boinc.exe 8072 ReadFile C:\ProgramData\BOINC\slots\0\boinc_task_state.xml SUCCESS Offset: 0, Length: 500, Priority: Normal 12:55:14.3677519 PM boinc.exe 8072 ReadFile C:\ProgramData\BOINC\gui_rpc_auth.cfg SUCCESS Offset: 0, Length: 32, Priority: Normal 12:55:14.6029155 PM boinc.exe 8072 ReadFile C:\ProgramData\BOINC\notices\feeds_setiathome.berkeley.edu.xml SUCCESS Offset: 0, Length: 274, Priority: Normal 12:55:14.6378302 PM boinc.exe 8072 ReadFile C:\ProgramData\BOINC\notices\archive_setiathome.berkeley.edu_notices.php.xml SUCCESS Offset: 0, Length: 1,673, Priority: Normal 12:55:15.0231213 PM boinc.exe 8072 ReadFile C:\ProgramData\BOINC\projects\setiathome.berkeley.edu\MB8_win_x86_SSE3_VS2008_r3330.exe SUCCESS Offset: 735,232, Length: 1,024, Priority: Normal 12:55:15.0655795 PM boinc.exe 8072 ReadFile C:\ProgramData\BOINC\projects\setiathome.berkeley.edu\MB8_win_x86_SSE3_VS2008_r3330.exe SUCCESS Offset: 735,232, Length: 1,024, Priority: Normal 12:55:15.1006801 PM boinc.exe 8072 ReadFile C:\ProgramData\BOINC\projects\setiathome.berkeley.edu\Lunatics_x41zi_win32_cuda50.exe SUCCESS Offset: 6,853,632, Length: 1,024, Priority: Normal 12:55:16.5113042 PM boinc.exe 8072 ReadFile C:\ProgramData\BOINC\notices\setiathome.berkeley.edu_notices.php.xml SUCCESS Offset: 0, Length: 1,899, Priority: Normal

There's nothing indicating that any scheduler file is read, either before or after the client_state.xml is read.


Next 20

Copyright © 2016 University of California