Posts by frankhagen

21) Message boards : Number crunching : Massive drop of credits per CPU hour (Message 582)
Posted 23 Mar 2012 by frankhagen
Post:

I went ahead and implemented the "--credit_from_runtime X" option in the validator. Now we wait to see if this fixes the problem with CreditNew...


Does this mean that my 5.10.45 clients will now get sensible credit? If so, I'll start crunching this project again :)


at least i think so - give it a try.

oh - and be careful not to take the real long WU's for the slow hosts!
22) Message boards : Number crunching : OpenCL/GPU app? (Message 580)
Posted 23 Mar 2012 by frankhagen
Post:
I'm all for posting the source though.


where can i sign? ;)
23) Message boards : Number crunching : abort? (Message 574)
Posted 22 Mar 2012 by frankhagen
Post:
Good evening the same thing happend to me,

6 (six) WUs running the same time since betwen 62 and 89 h, reached betw. 55 and 59 percent with a maturity of 55 - 66 h. The Deadline for all of them are today 23:58 o´clock. What schould i do ?


suspend all other projects and give them another day..
24) Message boards : Number crunching : abort? (Message 571)
Posted 21 Mar 2012 by frankhagen
Post:
Well, the WU that started this whole discussion has now disappeared from the database, no doubt from db_purge doing it's job. My fault, I should have disabled db_purge.


The question now is how to assign manual credit (as I promised) to a non existant result...


no way - now you can only edit the user record and raise his credit.
25) Message boards : Number crunching : abort? (Message 564)
Posted 19 Mar 2012 by frankhagen
Post:
OMFG!

and again - badly documented, no clue where to pull the strings.. :(
26) Message boards : Number crunching : OpenCL/GPU app? (Message 560)
Posted 19 Mar 2012 by frankhagen
Post:
Any chance of an app for our GPUs? I know some math does not port well to GPUs. But maybe this one would?


Greg and I discussed this a while back, and came to the conclusion that it might be possible but would require alot of work. We are using the pari/gp library to do the number theoretic calculations, and although this is open source code, it would require non-trivial modifications. We are also using the gmp library, which may not port well. But I am not an expert on GPUs, so maybe someone else can chime in here with some better insight.



well, at least GMP-ECM has a working CUDA-branch, you don't happen to be using that lib?

primegrid recently started a world-record hunt for Generalized Fermat-primes using CUDA-apps. current runtimes are up into several days on fastest GPU's, but would take months most likely on current high-end CPU's.

that app allready owns the top 4 spots. ;)
27) Message boards : Number crunching : DS-14x121 runtimes (Message 559)
Posted 19 Mar 2012 by frankhagen
Post:
I use -O3 optimization with the gcc compiler. With VS I use the "optimize for speed" option and also the "whole program optimization" option.


that way you get code which will run on any X86 (or AMD64) compatible machine. even those old ones that rarely exist anymore.
for AMD64 this (at least) enables the use of SSE-2 instructions, so they definitely will run faster than their 32-bit pendants. but every newer feature is simply left out.


I didn't think gcc used any special processor features to give an Intel CPU any advantage over the comparable AMD CPU.


right, not by default. to achieve that you have to use platform-specific compiler options - but that's exactly what MPIR supports with GCC. they even include special assembler code for several processor types.
28) Message boards : Number crunching : DS-14x121 runtimes (Message 552)
Posted 18 Mar 2012 by frankhagen
Post:
The difference between 32bit and 64bit could also be from different compilers (gnu for linux vs. visual studio for Windows). There also seems to be a difference between AMD and Intel, even at the same clock speed.


you can not compare them using clock-speed. and you need to know which compiler is used and with which optimization options.

special builds for processor features are often a lot faster.

which versions of GCC and VS are you using?
29) Message boards : Number crunching : abort? (Message 538)
Posted 15 Mar 2012 by frankhagen
Post:
there allways is the possibility to manually grant credits even if such things happen. but that's a decision eric has to make.

since we most likely are only talking about a few tasks in that misery, this could be a solution.
30) Message boards : News : Extra Credit for GetDecics (Message 523)
Posted 14 Mar 2012 by frankhagen
Post:
I know they're not slow, but I thought the client kept track of certain metrics that might infer that. Remember during the whole Credit New debacle, some really fast hosts were getting very low credits because the client (or maybe the validator?) thought the host was extremely slow.


second guess.. ;)

we are talking about Space Sciences Laboratory..

remember that one: http://en.wikipedia.org/wiki/Mars_Surveyor_%2798_program ?

but this time it's not a faulty parameter, but faulty design that can never work on projects which have huge differences in runtimes of batches on a single app.

i'd say that APR-thing is as silly as it can get, but i'd not even bet a penny on DA not coming up with something even worse.. :(
31) Message boards : News : Extra Credit for GetDecics (Message 520)
Posted 14 Mar 2012 by frankhagen
Post:
I just checked the feeder log file and it has many GetDecic WUs in it's "slots". I wonder if something else is going on, like the feeder thinks your host is not fast enough to handle the tasks. Does this happen on all your hosts?


zombie67 does not have hosts here which can be considered really slow. and even then, afaik this would not result in "No tasks are available for Get Decic Fields ".
32) Message boards : Number crunching : abort? (Message 519)
Posted 14 Mar 2012 by frankhagen
Post:
just checked the server status. it's showing runtimes of up to 400h now for get decics.
you will not find a lot of guys out here who will dare to run such things.

if there is any chance to split the jobs so they take only a few hours, you'd probably be able to speed up progress.
33) Message boards : News : NumberFields@home still under construction (Message 513)
Posted 13 Mar 2012 by frankhagen
Post:
Unfortunately, "stat" is the name of the host and the rest of the url wont be changing for obvious reasons. As you probably know, changing the name of a host is not a trivial problem, not to mention the work that would be required of the campus IT people. So the stat.la.asu.edu address will have to stay.


aaah! there we go:

PING numberfields.asu.edu

Ping stat.la.asu.edu [129.219.44.120] mit 32 Bytes Daten:

Antwort von 129.219.44.120: Bytes=32 Zeit=208ms TTL=40
Antwort von 129.219.44.120: Bytes=32 Zeit=205ms TTL=40
Antwort von 129.219.44.120: Bytes=32 Zeit=207ms TTL=40
Antwort von 129.219.44.120: Bytes=32 Zeit=206ms TTL=40

ip-resolution of course works, but a redirected URL most likely is not a very bright idea in the long term..
34) Message boards : News : NumberFields@home still under construction (Message 511)
Posted 13 Mar 2012 by frankhagen
Post:
it allways happens if i end up on http://stat.la.asu.edu/NumberFields/

for whatever reason.

the browser has a cookie for numberfields.asu.edu - so not usable on the other URL.


Frank was right. I verified on both firefox and IE. Note that I did have to close down and restart the browser to get it to work on IE. I changed my bookmarks to the numberfields.asu.edu address and now the problem has gone away.


then just get rid of stat.la.asu.edu/NumberFields.

probably will block those still using the old url, but i'm sure they'll notice it then. ;)
35) Message boards : News : Extra Credit for GetDecics (Message 508)
Posted 12 Mar 2012 by frankhagen
Post:
You might be confusing the scheduler job cache with the amount of unsent work. There is plenty of unsent work.

i know - whatever it is, i got WU's now - some time ago the server did not hand out bounded WU's again.

probably cache, buffer or something else was completely filled with get decis.
36) Message boards : News : Extra Credit for GetDecics (Message 505)
Posted 12 Mar 2012 by frankhagen
Post:
I also found some config items that I wasn't previously aware of. One on them is the size of the job cache that the scheduler uses. I bumped this up from the default of 100 to 800 jobs. Let's hope that keeps it from running out of work.


could you bump up the cache further?

i have outages again and i don't want to run a local buffer of sevral days.
37) Message boards : News : NumberFields@home still under construction (Message 504)
Posted 12 Mar 2012 by frankhagen
Post:
it allways happens if i end up on http://stat.la.asu.edu/NumberFields/

for whatever reason.

the browser has a cookie for numberfields.asu.edu - so not usable on the other URL.
38) Message boards : News : NumberFields@home still under construction (Message 495)
Posted 11 Mar 2012 by frankhagen
Post:
well eric,

you missed some of the URL's when changing them.


some still point to http://stat.la.asu.edu/NumberFields/...
39) Message boards : Number crunching : abort? (Message 491)
Posted 10 Mar 2012 by frankhagen
Post:
I am not familiar with the atom d510, but it sounds like frank knows what he's talking about.


i got several of those things (even slower ones), i am not using them on boinc, but i got a pretty good idea how they perfom.

I will increase the grace period by another week just for safe measure.


that's exactly the right measure to take!


40) Message boards : News : Extra Credit for GetDecics (Message 488)
Posted 10 Mar 2012 by frankhagen
Post:
Any estimate on how long you will be giving out extra credit for the GetDecics tasks?


well, tough stuff deserves better payment.

i think that's the deal..


Previous 20 · Next 20


Main page · Your account · Message boards


Copyright © 2024 Arizona State University