留言板 :
Number crunching :
Bad WU
留言板合理
| 作者 | 消息 |
|---|---|
|
Urs Echternacht 发送消息 已加入:15 May 99 贴子:692 积分:135,197,781 近期平均积分:211
|
Thanks! Didn't notice that. Yes, the new library made it always at least "a little" (few percent) faster. _\|/_ U r s |
Khangollo 发送消息 已加入:1 Aug 00 贴子:245 积分:36,410,524 近期平均积分:0
|
|
|
Urs Echternacht 发送消息 已加入:15 May 99 贴子:692 积分:135,197,781 近期平均积分:211
|
If you were referring to me, that's what I was using/testing with. The r411 app for linux. I remember a long time ago I got a useful output, but I guess not anymore. The linux executables of r411 or r411b (new!) are so called static executables. It should have everything needed build in. Therefor "ldd" will not show anymore library infos. "ldd" works only if the executable is of shared type. _\|/_ U r s |
|
Cosmic_Ocean 发送消息 已加入:23 Dec 00 贴子:3027 积分:13,516,867 近期平均积分:13
|
running the opt ap on linux is a bit easier than what you are attempting If you were referring to me, that's what I was using/testing with. The r411 app for linux. I remember a long time ago I got a useful output, but I guess not anymore. Linux laptop: record uptime: 1511d 20h 19m (ended due to the power brick giving-up) |
skildude 发送消息 已加入:4 Oct 00 贴子:9541 积分:50,759,529 近期平均积分:60
|
running the opt ap on linux is a bit easier than what you are attempting In a rich man's house there is no place to spit but his face. Diogenes Of Sinope |
|
Cosmic_Ocean 发送消息 已加入:23 Dec 00 贴子:3027 积分:13,516,867 近期平均积分:13
|
I came across a report of late-onset Signal 11 at Einstein recently. Their stderr_txt had the decency to report LDD is supposed to inform you of what all it needs and what you have. for example: machine:~ # ldd /bin/vi
linux-gate.so.1 => (0xffffe000)
libm.so.6 => /lib/libm.so.6 (0xb77d8000)
libncurses.so.5 => /lib/libncurses.so.5 (0xb779b000)
libacl.so.1 => /lib/libacl.so.1 (0xb7792000)
libc.so.6 => /lib/libc.so.6 (0xb7636000)
libdl.so.2 => /lib/libdl.so.2 (0xb7631000)
/lib/ld-linux.so.2 (0xb7815000)
libattr.so.1 => /lib/libattr.so.1 (0xb762b000)
machine:~ #However, when I throw a linux AP binary at it, I get "not a dynamic executable". I'm pretty sure it worked before. That may have been before libfft was included instead of referenced. When I had the segment violation errors a while back, the output of LDD specifically mentioned that I needed GLIBC3.2 or higher and I only had I think 2.8? I don't remember the full details. I just remember that it did tell me what the problem was. Linux laptop: record uptime: 1511d 20h 19m (ended due to the power brick giving-up) |
Richard Haselgrove ![]() 发送消息 已加入:4 Jul 99 贴子:14152 积分:200,643,578 近期平均积分:874
|
I came across a report of late-onset Signal 11 at Einstein recently. Their stderr_txt had the decency to report libgcc_s.so.1 must be installed for pthread_cancel to work Maybe an installed library check - is that LDD? - would help. |
|
Cosmic_Ocean 发送消息 已加入:23 Dec 00 贴子:3027 积分:13,516,867 近期平均积分:13
|
Yeah, I don't think I've ever seen a Linux 5.06 stock app successfully run all the way through a WU. I do point at a glibc incompatibility though. When the opt app came out for ap_v505 (r168), my single core machine was running 64-bit linux at the time, and would instant-fail with a segment violation. Somebody had mentioned that I should run the 'LDD' (in lower-case) command on the binary and look for problems. Everything was fine except GLIBC. I tried upgrading that, but since it was an older distro, 200+ packages and the kernel had to be updated, so I just opted to grab a then-recent version of the same distro. Problem fixed. So that's usually my go-to when someone has a segment violation on a linux app (stock or optimized). Especially if it is within the first 60 seconds. Linux laptop: record uptime: 1511d 20h 19m (ended due to the power brick giving-up) |
HAL9000 发送消息 已加入:11 Sep 99 贴子:6533 积分:196,805,888 近期平均积分:57
|
that one is .... OUCH! Linux + stock AP app = no bueno I had noticed a machine I was paired with a while back that was doing that. I was informed the linux 5.06 app has an issue. Here is the post. It is decisions like this that make me wonder what the project admins are smoking sometimes. SETI@home classic workunits: 93,865 CPU time: 863,447 hours |
Dimly Lit Lightbulb 😀 发送消息 已加入:30 Aug 08 贴子:15393 积分:7,423,413 近期平均积分:1
|
that one is .... OUCH! Not surprised, looking at my wingmen I've only seen ONE Astropulse v505 v5.06 complete successfully over the last couple of months. Though they usually error out after a few seconds. Member of the People Encouraging Niceness In Society club.
|
Michel448a 发送消息 已加入:27 Oct 00 贴子:1331 积分:2,970,814 近期平均积分:0
|
that one is .... OUCH! http://setiathome.berkeley.edu/workunit.php?wuid=905551594 more than 66 hrs of hard work (239,847.70 secs) and end with ??? ''Error while computing'' i am happy it s not me. lol edit : oh ! that one is worst lol, same computer: 270,542.90 secs = 75 hrs of hard work ''Error while computing'' http://setiathome.berkeley.edu/workunit.php?wuid=909224268 |
Jim_S 发送消息 已加入:23 Feb 00 贴子:4705 积分:64,560,357 近期平均积分:31
|
How long until this disappears? Bad WU...BAD, Bad, bad! ;o) I Desire Peace and Justice, Jim Scott (Mod-Ret.) |
Tim 发送消息 已加入:19 May 99 贴子:211 积分:278,575,259 近期平均积分:0
|
How long until this disappears? Check this one. http://setiathome.berkeley.edu/workunit.php?wuid=631815542 It's from 2010. |
kittyman ![]() 发送消息 已加入:9 Jul 00 贴子:50498 积分:1,018,363,574 近期平均积分:1,004
|
How long until this disappears? Probably on the 5th of March, or when the last remaining cruncher that has it in cache has returned it. "Learn from yesterday. Live for today. Hope for tomorrow." Albert Einstein "With cats." kittyman
|
Jim_S 发送消息 已加入:23 Feb 00 贴子:4705 积分:64,560,357 近期平均积分:31
|
How long until this disappears? http://setiathome.berkeley.edu/workunit.php?wuid=909492654 I Desire Peace and Justice, Jim Scott (Mod-Ret.) |
©2020 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.