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. ;)

No, we need the standard GMP. And even if GMP had cuda support, we still have the pari/gp library to deal with. We use pari for computing integral bases, checking irreducibility, computing field discriminants, and also factoring large integers. It's a large amount of code that would need to be "cudified". It would be a fun undertaking, if only I had the time.

Well... i'm not sure why you don't upload a copy of the code somewhere for users to have a look at it. Maybe one will have time to look at it an port it to use a GPU.

Actually, since you're using GPL'ed GMP and PARI, you'll have to release your source code upone request (cosider this post a request ;) ), or otherwhise you're violating GPL.

TIA

Wiki updated for the confusion over units, though I don't think that's the real underlying problem.

Thanks Richard. That was quick.

I am pretty sure I was using the "report_grace_period", otherwise I wouldn't have questioned the units. I cant ssh into the project server from work, so I have a call into Greg to take a look at the config file. He will be able to tell us exactly what is going on there.

i only want to run Get Bounded Decics.

i am not getting a single WU for days now.

should i stay or should i go?

I won't be getting home until very late tonight, so I decided to turn the bounded app back on. This time I set the weights to 100-to-1. We will see if that has any effect.

I made the above change via the admin web interface. But I might need to restart the project daemons in order for the change to take effect, and I cant do this from work (no ssh allowed, dont ask me why). Anyways, I have a call into the other admin Greg so that he can do it. Should happen relatively soon...

Eric

Good day everybody.

Is there a page with ETA for project?

Hi,
I had a few task, that were running, for example, for 30h.
When validated, the time credited was only 32000 sec, which is less than 9h.
Why is that?

Greg,

Here are the docs regarding resends (retries).

I would suggest setting the <reliable_reduced_delay_bound> to 1 rather than less than 1. A value less than 1 reduces the deadline on the resend to something less than the normal 3 day deadline. If the task is being resent because it's a 100 hour task that missed deadline it might not be wise to reduce the deadline, even if it will be sent to a fast-reliable host. You might even consider setting <reliable_reduced_delay_bound> to 1.33 to increase the resend's deadline from 3 days to 3.99.

One of the sad things about that WU is that it bounced around from 1 slow computer to another before ending up on a host with a fairly fast processor and short turnaround time. With the possibility of 100 hour run times and 3 day deadlines, it might be wise to start using the "issue task resends to fast-reliable hosts" mechanism but not reduce the deadline for resends. It might even make sense to extend the deadline for resends because the initial deadline is rather short and resends seem to be happening because the user aborts the task because it has no hope of finishing on time or the task simply times out.

Unfortunately the server documentation pages are unavailable at this time. I'll post a link later when the pages are back online.

I am currently out of town and have limited access to the internet. When I return I will look into the "resend to fast-reliable hosts" mechanism, which sounds like a good idea. Unless Greg wants to take a stab at it while I am gone...

Interesting that this seems to be the only wu having the problem out of almost 60000 for that set. Of course there were other slow ones, but they managed to make it through and get assimilated without drawing any attention.

wu_12E10_SF161-1_Idx3_Grp57438of59290
getting stuck. aborted after 70 hours

I am having similar problems on my RHEL5 x64 hosts,
...
% ./GetBoundedDecics_1.07_x86_64-pc-linux-gnu
FATAL: kernel too old
Segmentation fault (core dumped)

Well I can't work out why my faster computer (by only 200 MHz, an AMD Phenom II 1100T @ 3.3 GHz, my other is AMD Phenom II 955 @ 3.2 GHz), is getting consistently much lower results than my slower machine.
...

I'm getting PARI errors too.

http://stat.la.asu.edu/NumberFields/result.php?resultid=59267
*** overflow in t_INT-->t_INT assignment.
*** Error in the PARI system. End of program.

http://stat.la.asu.edu/NumberFields/result.php?resultid=59281
*** bug in PARI/GP (Segmentation Fault), please report
*** Error in the PARI system. End of program.

If you browse through my errored tasks you'll also see I've been getting "Maximum disk size exceeded", exit code -177, but I haven't seen anymore of those since alloting more disk space to BOINC so ignore them.

I am aware of the pari seg faults. It seems like every time I find a bug and fix it, another one appears. Needless to say, that's on the top of my list of to-do's.

Out of curiosity, what did you need to set your maximum disk usage to? I just checked and mine was set to 20GB which I'm sure is overkill. I've noticed a few other users with exit code -177, so this information might help them set their preferences.

I don't think it has anything to do with lib versions on the client. I think something early is ill conditioned or relies on a failed syscall that leads to the exception. Any chance someone can run under a debugger? You would do #gdb <app name> then r for run. After the exception it should trap and give you a line number. That would be great since we have no way to reproduce. Any takers?

Well, this doesn't look real helpful, but here it is.

This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from /tmp/GetBoundedDecics_1.06_x86_64-pc-linux-gnu...done.
(gdb) r
Starting program: /tmp/GetBoundedDecics_1.06_x86_64-pc-linux-gnu

Program received signal SIGFPE, Arithmetic exception.
0x00000031fee72b4c in ?? () from /lib64/libc.so.6

Perhaps there's a USE flag I need to enable in my glibc?

emerge -vp glibc

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild R ] sys-libs/glibc-2.12.2 USE="(multilib) nls -debug -gd -glibc-omitfp (-hardened) -profile (-selinux) -vanilla" 0 kB

Sure thing. System has 16Gb Ram with almost all of it totally free right now.

(gdb) bt
#0  0x0000003a76277e13 in _int_free () from /lib64/libc.so.6
#1  0x0000003a76265eed in fclose@@GLIBC_2.2.5 () from /lib64/libc.so.6
#2  0x00007ffff7de1f3a in _nss_files_getpwuid_r () from /lib64/libnss_files.so.2
#3  0x000000000085345d in getpwuid_r ()
#4  0x0000000000853029 in getpwuid ()
#5  0x000000000068a5e5 in pari_get_homedir ()
#6  0x000000000068abea in path_expand ()
#7  0x000000000068af29 in gp_expand_path ()
#8  0x000000000069cca0 in pari_init_opts ()
#9  0x000000000041150e in MartinetSearch(char*, char*, int, long, long, long*) ()
#10 0x0000000000403196 in main ()

Tried the debug-info command but it didn't find anything to install. Looks like the debuginfo repos for centos 6 are not updated yet.. Do I need a version compiled with a -g ?

Reading symbols from /root/BOINC/projects/stat.la.asu.edu_NumberFields/GetBoundedDecics_1.06_x86_64-pc-linux-gnu...done.
(gdb) r
Starting program: /root/BOINC/projects/stat.la.asu.edu_NumberFields/GetBoundedDecics_1.06_x86_64-pc-linux-gnu

Program received signal SIGFPE, Arithmetic exception.
0x0000003a76277e13 in _int_free () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.7.el6.x86_64