Welcome to MilkyWay@home

Posts by Honza

1) Message boards : Number crunching : Losing my BOINC manager (Message 14699)
Posted 10 Mar 2009 by Honza
6.6.14 is a buggy one...I mean more buggy than usual.
There should be a quick fix, albeit only for Win x32 - http://boinc.berkeley.edu/dl/boincmgr.090309.zip

2 years old BOINCView is still doing great job and is superior in many aspects comparing to Manager. A must have if you want to manager dozens of boxes and donĀ§t want to fiddle whole days with Manager...
2) Message boards : Application Code Discussion : GPU app teaser (Message 12933)
Posted 26 Feb 2009 by Honza
1% CPU load is not possible with the current split of the work between GPU and CPU. I don't plan to change anything on that because the effort for doing the remaining 0.1% of the CPU calculations on the GPU appears to be too much. If all the more urgent issues are solved, maybe one can think about it again. But I doubt the conclusion will be much different.
One needs the CPU about half a second in the beginning and slightly more (about a second) at the end of a WU (scales with CPU speed of course). In between a CPU load of about 10% of a core or maybe even less should be doable.

Does it makes sense to compile ATI GPU version with CPU SSSE3, SSE4.1 and/or SSE4.2 instructions? Or at least try to see how it would behave...
3) Message boards : Application Code Discussion : GPU app teaser (Message 11023)
Posted 16 Feb 2009 by Honza
I think one of the recent updates to the BOINC server code allows for a separate daily WU queue for GPUs.
Well, it may (i don't know). But I known that even latest BOINC client 6.6.7 still doesn't recognize GPUs (means both nVidia and ATI/AMD GPUs), only CUDA capable devices.

(not only) MW would benefit a lot from support of ATI GPUs under BOINC, especially those capable of double precision...
4) Message boards : Application Code Discussion : GPU app teaser (Message 11017)
Posted 16 Feb 2009 by Honza
Also, I can raise the workunit-per-cpu limit. What would be a good value?

3600*24/9 is up to ~10K WUs per day on HD4870.

Too bad BOINC is still far from ready for GPUs.
I would have suggested to raise WU limit only for hosts with GPUs and distribute WUs with pretty short deadline or extra large ones for such hosts...
5) Message boards : Number crunching : v0.18/v0.19 issues here (Message 10999)
Posted 16 Feb 2009 by Honza
Seems the server can be finicky about updating the application for some reason. I deleted the previous versions (instead of deprecating them), so hopefully it should send them out now.

Can you also delete the old old aplication as well?
MilkyWay@Home Old 1.22
6) Message boards : Application Code Discussion : GPU app teaser (Message 9532)
Posted 1 Feb 2009 by Honza
I don't know about .NET for Catalyst, but I'm running Windows 7 beta x64. It should have .NET already installed, same version as or later than Vista. As for drivers, no I haven't tried 9.1. 8.12 is all that's available for Win7 for now.

Well, what's good for Vista (and server 2008) should be good for Win 7 (and server 2008 R2). Including drivers like Catalyst.
Win 7 should be shipped with .NET 2 (server 2008 and 2008 R2 comes with it). It has both x86 and x64 .NET 2 version in it.

Anyway, if you installed (full) Catalyst, CCC (Catalyst Control Center) needs .NET. If it's working, means you have .NET 2 working.
7) Message boards : Application Code Discussion : GPU app teaser (Message 9528)
Posted 1 Feb 2009 by Honza
The files are there, and the only thing I've tweaked in the app_info is the avg_ncpus to 1. However, could it be caused by an older version of BOINC? I'm running 6.2.19.

It runs on 5.10.30 as well.
8) Message boards : Application Code Discussion : GPU app teaser (Message 9519)
Posted 1 Feb 2009 by Honza
@ the guys, where it runs, had you similiar problems?

Well, I had some issues but not app related.
Running under Win 2008 with Catalyst 8.12, automatic regulation of fan speed is not working on my HD3870. It was set to ~20% which cause GPU to overheat under full load. Driver stopped responding, W2K8 was able to recover without crashing but some WUs trashed of course.

Running ATI Tray Tool and setting fan speed to 40-50% helped was good solution.
I'm able to monitor GPU load, temps and fan speed with ATT without problems.
In general, app is working just fine (with comments in Message 9432).

9) Message boards : Application Code Discussion : GPU app teaser (Message 9436)
Posted 31 Jan 2009 by Honza
Have you played around a bit with the settings in the app_info.xml, cc_config.xml and the resource share?

I see you have updated the client from 5.10.30 to 6.6.3 before running the GPU app. This should have been unnecessary as the GPU stuff in there is only for nvidia cards and is not used at all.

Thanks for your comments.

Yes, I've played with app_info.xml, cc_config.xml.
Since there is no way to split computing to 4 CPU tasks and n GPU tasks (none that I'm aware of), I have settled to ncpus=5 and put both avg_ncpus and max_ncpus to 1. This way GPU is fequently idle so setting avg_ncpus=0.5 will make better change for GPU to take action but may slow down CPU dealing with too many tasks. No exact measurement in CPU performance was done when Q9550 is doing 4 or 8 tasks at once.
Once your GPU app is ready to other WU types, it would make more sense to play with settings and resource share in order to make GPU doing MW and let CPUs on other projects.

I'm using rather outdated 5.10.30 BOINC Studio core since it has backup project(s) ability. It is still left on my SSD with original projects configuration.
There is nothing really important/interesting in 6.x to upgrade dozens of hosts (no multithreading project apps available for example) and GPU support is far from bug free.
6.6.3 is a fresh install with only MW attached to play with. I may revert back to BS 5.10.30 completely.
10) Message boards : Application Code Discussion : GPU app teaser (Message 9432)
Posted 31 Jan 2009 by Honza
Tested GPU app on HD3870.
Performance is far superior to any CPU, no doubt.

I've notice that some WUs are "not compatible, falling back to a somewhat slow CPU code."

For example nm_s79, nm_s86 are run on GPU but nm_s20 or nm_s21 are run on CPU.
It is a known issue or some types of WUs can't be completed on a GPU at all?
11) Message boards : Number crunching : Reverting to Stock (Message 8888)
Posted 23 Jan 2009 by Honza
I known a stock version needs to be the one that runs on any architecture supported by the project but...

A suggestion.
Can you provide real Win x64 application, that has SSE2 enabled?
I mean - right now there is not x64 app (it's a 32-bit fake given to 64-bit hosts) but x64 CPUs are also SSE2 capable.
This way, 64-bit hosts can somehow benefit and provide better performance per watt.

I believe it can be even extened.
It is known what CPU features are available to each host (BOINC client reports what is known to OS) and app can be provided accordingly.
This would mean to have Win stock, Win SSE2, Win SSE3, Win x64 SSE2, Win x64 SSE3 etc and send them to hosts.

Or, you can make a single app that would have all version inside (stock...SSE4.2) and app itself will choose what code version to run.
12) Message boards : Number crunching : Extreme CUDA processing! (Message 8511)
Posted 17 Jan 2009 by Honza
Thanks for your insight, Cluster Physik.

@speedimic - running GPUs on SETI is good for heating, perhaps better that Intel's Presshot CPUs...considering performance per watt of oficial GPU app comparing to opt app running on Core i7.
13) Message boards : Application Code Discussion : milkyway code releases (Message 7101)
Posted 1 Dec 2008 by Honza
boinc is probably estimating the time wrong. if you let a few of them run it should fix it.

It is expected behaviour.

When someone runs opt app, duration correction factor (DCF) makes estimation of run times correct. But when estimation on project side comes within reasonable times again (ie. stock app with good task estimation), DCF still takes place.
You can eighter manually reset DCF to 1 or let BOINC to correct itself - but it would take some times as Travis mentioned.
14) Message boards : Number crunching : How to Switch to the New Official App? (Message 6289)
Posted 19 Nov 2008 by Honza
Thanks for the updates, Travis.
Especially the one in another thread about what's new in new version.
This somehow answer my question about progress of project...

As I see it, "Optimalized" version enables us to perform what we have been doing whole year withing a very few days. I'm still not sure if it is good news or bad news.
New app version is aiming at both - doing better science and doing it faster.
15) Message boards : Number crunching : Longer Double U-U's Please! (Message 6123)
Posted 13 Nov 2008 by Honza
Just wondering if longer running WU's are in the works...

It doesn't make sence before ineffective official app is replaced.
It would only make official apps to runs for even more hours and deadline issue is on the table.

So, as the new apps was promissed...
16) Message boards : Number crunching : No Work ? (Message 6092)
Posted 12 Nov 2008 by Honza
Well, I might be eager to get some more work BUT...I'm also interested what have been done with results alredy finished.

I mean - there has been considerable speed-up in work processing, more results completed and delivered back to the project...so where is the science? What science progress has been achieved?
17) Message boards : Number crunching : I think you made your point !! (Message 5600)
Posted 24 Oct 2008 by Honza
Well, I think I was waiting long enough for an improvement.
Setting 30+ boxes elsewhere - where I known it's not a 99% waste of CPU cycles and electricity.
18) Message boards : Number crunching : When will the deadline be extended? (Message 4743)
Posted 16 Aug 2008 by Honza
Thanks, 3 days deadline should be fine for boxes turned off over weekend. I'll monitor the issues...
19) Message boards : Number crunching : 8 Workunit limit (Message 4722)
Posted 15 Aug 2008 by Honza
Maybe if you could guarantee (yeah, right!) that work was always available we could go for a 0.05 day cache and provided there were no really short WUs and that BOINC manager requested works frequently enough, work would be pushed through quickly and always be 'fresh'.

I can't help but feel that this project doesn't really quite suit BOINC, as parameters have to be set to force the behaviour that you need. Maybe a standalone DC app would work better.

Report Results Immediately, a feature introduced in some older non-UCB BOINC cores like BOINC Studio core would solve the problem. It means once the result is finished and uploaded, it will trigger it's report.
20) Message boards : Number crunching : 8 Workunit limit (Message 4717)
Posted 15 Aug 2008 by Honza
Office boxes turned off over the weekend can just download new WUs when they're turned back on. If the ones in their queue aren't computed it really doesn't effect what we're doing. Really old WUs really don't have very much benefit to what we're doing and would just be wasting cycles, it's just the nature of the project.

Thanks for quick answer.

You are correct about those downloaded but not started.
Only those partialy computed will be wasted...from users perspective.
A 3 days deadline would overcome this problem - WUs started on Friday would have been finished on Monday.

Next 20

©2019 Astroinformatics Group