|
1)
留言板 :
News :
Final data is in the splitter queue.
(消息 2050261)
发表于:24 May 2020 作者: Bryn Post: Just a few days short of 19 years' crunching, through the evolution of at least 4 machines, my Seti tasks have finally fallen to zero. A wonderful endeavour, and the first project I joined. If I might poorly quote (I believe) Arthur C. Clarke: "There either is or there isn't extraterrestrial life. Either is utterly mind-blowing." Here's hoping something mind-blowing is found amongst all that data. So long Seti, and thanks for the ride. |
|
2)
疑难解答 :
Unix/Linux :
Boinc running Seti won't shut down still
(消息 700131)
发表于:15 Jan 2008 作者: Bryn Post:
Yep - that's exactly the sort of weirdness I mean. A USB device should just be that: a USB device. Electrically, it's about as boring as a parallel port and for an 'ordinary' thing like a mouse to get as far as affecting the RAM says (to me, any way!) that there's something sinister going on with the motherboard. I'm not really expecting to find RAM faults as such, just (maybe) some esoteric mapping problems which I think may not be uncovered by a RAM test.
Even so, I still think it's worth swapping it around and halving the physical memory - just to try and nail what's going on with your motherboard.
Ah yes - but ultimately, nothing checks out correct system functionality quite like running applications! ;)
Yes indeed. But it's not BOINC/seti per se which is faulty because surely, this clobbering of 'common' applications like Firefox & Thunderbird would be affecting many more people. I'm running a box with the same CPU and less RAM than on your system yet I have no problems at all. BOINC/seti might as well not be running for all the difference I can detect in machine behaviour/responsiveness, including Firefox etc., yet I allow it 100% access at all times. Also, as applications, BOINC/seti don't need to get up to anything really fancy WRT accessing hardware: one is a front-end manager and the other is a maths engine, with both making the odd use of file and net access. Nothing too magical there and likely to be much less busy with the hardware than say, something like KDE (or even that other OS). But - a true aside... I once worked for a PC manufacturer which produced its own motherboards and they worked very well. Strangely, one reviewer reported horribly slow RAM benchmarks when comparing against someone else's motherboard using the same support chipset and same CPU. The results should have been virtually identical. After much head scratching it was eventually discovered that although the benchmark he was using was the same type as other reviewers (who reported no odd timings), his particular release had been compiled using a different library to the other versions. (for reasons known only to the benchmark manufacturer) There was a trick this particular library was pulling which caused some very odd things to happen with the memory mapping in certain regions - enough to highlight a tiny, TINY design problem with the motherboard. Fortunately it was relatively easy to fix with BIOS firmware alone and the end result was that all available versions of this benchmark behaved properly with none reporting odd timings. At no point did any of a range of benchmarks, system and memory tests show up anything odd. Just this one - yet it was still a hardware problem at the root of it. |
|
3)
疑难解答 :
Unix/Linux :
Boinc running Seti won't shut down still
(消息 699385)
发表于:11 Jan 2008 作者: Bryn Post: Wonder if the memory controller or something else in the north bridge is getting too busy to handle I/O requests from your network card or something I had a quick Google for problems related to the ASUS CUV4X and found a selection of "it's great" to "it sucks" reports with nothing usefully specific - but, I'm thinking along the same lines as you - especially as Slim reported similar problems when running the same motherboard under Windows. I wonder if it's worth removing a couple of SIMMs (or removing whatever's required) to drop the physical memory to say, half its current size, just as a test for motherboard-related memory mapping or I/O weirdness? Or, try moving the network card to a different slot to force it to pick up a different IRQ. |
|
4)
疑难解答 :
Unix/Linux :
Boinc running Seti won't shut down still
(消息 698147)
发表于:7 Jan 2008 作者: Bryn Post:
Here's a dumb test to show what happens with respect to 'top' showing 100% CPU usage. It depends on the installation of 'bc' (an arbitrary precision calculator - a whole 63 kBytes in size) which IIRC gets installed generally along with the base packages but if not, on Ubuntu, just do sudo apt-get install bc Paste the following into a file in your home directory called cpuloader.sh --- snip --- # thrash the CPU using a recursive factorial function f() # on a 3.06GHz P4 with HT - # f(1000) takes 30 mS # f(2000) takes 120 mS # f(4000) takes 500 mS # f(10000) takes 3.5 sec # f(100000) takes 9 min 22 sec Num=4000 # or pass yer own [ -z $1 ] || Num=$1 echo "f($Num)" echo "define f (x) {if (x <= 1) return (1);return (f(x-1) * x);} f($Num)"|bc --- snip --- If this is started with no parameter it will default to using 4000 - half a second run time on my P4. Open a couple of shell windows and after ensuring that BOINC/seti is running, in one of the windows start 'top' with top -d1 which will cause the process list to be updated every second. You should see seti apparently using ~100% CPU resources. In the other shell window, run the cpuloader script with sh ./cpuloader.sh 100000 I don't know how quickly this will complete on a multi-core CPU (lucky you!) but it should chug away for at least a couple of minutes. If it's insanely fast, try passing 200000 instead - on my 3.06GHz P4 that makes it run for a slightly silly 30 minutes plus... (to display the run time instead of reaching for a stopwatch, prepend time to the sh ./ cpuloader.sh ... line) While it's running (there will be no output until it completes), switch to the shell window running top - where you should see that 'bc' is now loading the CPU and seti has dropped down the list. On my P3 box, 'top' now shows: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13110 brian 25 0 13404 11m 476 R 92.9 1.6 15:27.85 bc 12490 brian 39 19 39268 34m 8 R 4.3 4.6 468:16.56 setiathome-5.27 If cpuloader completes while you're watching the output from top, you should see that 'bc' vanishes from the list and seti is once again given the most CPU usage. The basic idea is that if a resource is available then it should be used, with Linux quietly handling the switching between processes clamouring for access to resources according to their priority. This happens many thousands of times a second - much too fast for 'top' and other monitors to give a truly accurate picture. You may even see other processes coming & going on the displayed list - that's because as 'top' grabs a snapshot of the processes, a process just happened to be given a 'run slot' by Linux at the same time. (you can kill cpuloader.sh with ^C) I appreciate that BOINC may well be ignoring the limit CPU usage parameters, but I just wanted to demonstrate how process loading of the CPU is still being handled and shared correctly, even though 'top' and friends are apparently showing otherwise. |
|
5)
疑难解答 :
Unix/Linux :
Boinc running Seti won't shut down still
(消息 698134)
发表于:7 Jan 2008 作者: Bryn Post: Yours also appears to be broken 'if' you also have it set to shut off when 'you' are using the machine. It isn't unlatching your CPU either. No no - the machine remains completely responsive at all times. There's no noticeable difference in the 'feel' of the machine between running BOINC/seti or not running it. Please remember that 'top' displaying near 100% CPU usage doesn't mean anything is necessarily latched up. :)
I think this is just an indication of problems elsewhere. I've not asked BOINC to do anything special with respect to CPU usage yet it's still perfectly well behaved. (mind you, BOINC may well ignore this setting: it's not something I've ever tweaked - but this isn't what's causing your problem, I'm sure) |
|
6)
疑难解答 :
Unix/Linux :
Boinc running Seti won't shut down still
(消息 697742)
发表于:5 Jan 2008 作者: Bryn Post:
Hmm, but there's the odd thing: I'm running the same version as you on the same CPU and in less RAM - yet because mine is behaving fine, I really don't think it's BOINC which has the problem. A few posts back you gave this 'top' output (edited) when running BOINC/seti: top - 14:28:58 up 24 min, 2 users, load average: 1.45, 0.84, 0.54 Tasks: 97 total, 2 running, 95 sleeping, 0 stopped, 0 zombie Cpu(s): 4.3%us, 0.7%sy, 94.4%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.7%si, 0.0%st Mem: 1555796k total, 414040k used, 1141756k free, 14728k buffers Swap: 514072k total, 0k used, 514072k free, 219300k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5665 mike 39 19 37076 33m 8 R 95.0 2.2 3:35.32 setiathome-5.27 4747 root 15 0 42464 25m 8144 S 2.0 1.7 0:52.09 Xorg 5660 mike 15 0 45780 16m 12m S 1.7 1.1 0:06.61 boincmgr 5647 mike 15 0 4232 2104 1556 S 0.3 0.1 0:00.24 boinc 1 root 16 0 2948 1852 532 S 0.0 0.1 0:02.08 init 2 root 10 -5 0 0 0 S 0.0 0.0 0:00.01 kthreadd 3 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0 (...) Here's mine (through 'top -b -n1' and edited for brevity):
top - 22:59:41 up 1 day, 10:21, 5 users, load average: 1.03, 1.03, 1.03
Tasks: 95 total, 2 running, 93 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.3% us, 0.2% sy, 98.9% ni, 0.2% id, 0.1% wa, 0.4% hi, 0.0% si
Mem: 776060k total, 644032k used, 132028k free, 214844k buffers
Swap: 1052216k total, 0k used, 1052216k free, 177648k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9148 brian 39 19 39272 34m 8 R 90.8 4.6 333:25.84 setiathome-5.27
5980 root 15 0 56328 19m 3608 S 7.3 2.6 4:27.36 X
9678 brian 15 0 2052 868 656 R 3.6 0.1 0:00.02 top
1 root 16 0 680 248 216 S 0.0 0.0 0:01.67 init
2 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
(...)
6639 brian 15 0 11484 6136 5168 S 0.0 0.8 0:43.23 boincmgr
6640 brian 15 0 3904 2124 1448 S 0.0 0.3 0:05.69 boinc
(...)
9146 brian 34 19 39272 34m 8 S 0.0 4.6 0:00.12 setiathome-5.27
9147 brian 34 19 39272 34m 8 S 0.0 4.6 0:00.00 setiathome-5.27
9149 brian 34 19 39272 34m 8 S 0.0 4.6 0:00.01 setiathome-5.27
This is running under KDE and is started manually from a desktop icon with just 'run_manager' as the command component, from within the BOINC installation directory off my home directory. I just installed it with the default GUI stuff as-is, and made no other tweaks to the installation. The machine is generally left running so I've not bothered with any auto-start scripting. There's also no unusual or heavy network use as a result of running BOINC/seti - only what I might be getting up to (nothing else, apart from a few shell windows waiting for input at the time of this 'top' output).
Sorry, that was my loose description. I just meant the sort of 'grind to a halt' thing you've described when running BOINC/seti. Odd... <scratches head> |
|
7)
疑难解答 :
Unix/Linux :
Boinc running Seti won't shut down still
(消息 697620)
发表于:5 Jan 2008 作者: Bryn Post:
There seems to be something wrong as I write this. I just tried grabbing both mprime2414.tar.gz and sprime2414.tar.gz from http://www.mersenne.org/freesoft.htm but in each case the Firefox downloads window showed 'waiting' for a few minutes and then 'completed' - but nothing had actually been downloaded. The Russian mirror site mentioned at the above site fails to resolve - it seems to no longer exist. As to your main problem - I do find it a little suspicious that this is the same motherboard which gave similar 'heavy load' problems with BOINC when it was running under Windows. I'm inclined to agree with Dotsch that there's a fundamental hardware problem lurking at the back of all this. For what it's worth, I have BOINC running perfectly well on an ancient Intel 440BX-based motherboard with 1GB RAM and a PIII CPU. Actually, it's a card adapter carrying the PIII since this motherboard only has a Pentium II slot. I did say it was ancient! :) I also use this machine as an alternate "browsing base", plus a few other things, yet it's never shown anything like the sort of performance hit you describe. It's left running BOINC 24/7. The OS is a fairly old SUSE 9.3 release. Well, it ain't broke so I ain't fixing it... If left to its own devices, BOINC will always try to obtain 100% CPU usage (really, like almost any other application would typically want to do) but bear in mind that when using things like 'top' to display loadings, you're only getting a tiny snapshot every second or so. All the time, running processes are given access to resources (and have them taken away) very quickly so what appears to be a constant high load isn't necessarily so. Also, the resource management of Linux is such that as other tasks require more CPU time or other resources, access is granted very efficiently and in a very controlled/controllable way. It's probably only because of this good behaviour that I'm able to run BOINC on this venerable box - when running Windows98 (on another dusty old partition) and not doing very much at all, it's horribly sluggish. Just my $0.2, and I hope that whatever's going wrong is quickly nailed. |
|
8)
疑难解答 :
Unix/Linux :
Linux Client is complete and absolute Garbage
(消息 697409)
发表于:4 Jan 2008 作者: Bryn Post: /rant mode 1Er, posting nothing but a whine is not much use to anyone. Instead, try giving us some details like the distribution you're using, how you installed BOIC/seti, what you did next, and what happened. Thousands of people are successfully using it on Linux with many projects so it can't be that bad. |
|
9)
疑难解答 :
Unix/Linux :
Linux Client is complete and absolute Garbage
(消息 697408)
发表于:4 Jan 2008 作者: Bryn Post: I installed BOINC under Ubuntu.If you installed it using one of the prepared Ubuntu packages (and assuming you're running a GUI), you should find that seti is all set up to auto-start and there's a BOINC entry on the applications menu waiting for you to click it. IIRC, the GUI manager which you should then see will also have menu options which provides a nice easy way to enter your account key. No mess, no fuss. In fact this holds true for many other things too: first see if there's a ready-rolled version of <whatever> aimed at the distribution you're using. The post from KC7ZRU should work just as well - I don't bother with the GUI interface on my server and that's pretty much what I'd done to fire it up - but if you already have the "official" package installed via Ubuntu, I figure you might as well use it. ;) |
|
10)
疑难解答 :
Unix/Linux :
5.10.8-Ubuntu 7.10- BOINC won't keep screen size saved.
(消息 676198)
发表于:11 Nov 2007 作者: Bryn Post:
If you're running KDE, a right-click|Advanced on the title bar provides a menu which will allow the screen size/position to be fixed. (Special Window Settings/Special Application Settings) Of course a corrected BOINC is better, but this should work as a fall-back. |
|
11)
疑难解答 :
Unix/Linux :
New BOINC install on Ubuntu 7.10
(消息 676193)
发表于:11 Nov 2007 作者: Bryn Post:
Don't think that's right - AFAIR nothing needs to be modified if you've installed the package built for your distribution via apt-get etc. and when starting the GUI manager from the menu, the client will also be started if necessary. Try to back-track your modifications (or re-install) - once you've started the GUI part and have successfully used it to join a project, running 'ps ax' from a terminal prompt should show the client chugging away. |
|
12)
疑难解答 :
Unix/Linux :
Boinc and crontab
(消息 662827)
发表于:19 Oct 2007 作者: Bryn Post: I want to setup the 'run_manager' program/script as a cron job every hour As DJStarfox says, run_manager is for the GUI, and including BOINC as a service is a better, more 'system-friendly' way of handling it - but you could kick BOINC via CRON with: 01 * * * * /home/BOINC/kick.sh where kick.sh contains: ---snip--- cd /home/BOINC # start boinc if not already running if ! ps ax|grep boinc|grep -v grep > /dev/null; then exec ./boinc fi ---snip--- Save this to your BOINC directory then do: chmod +x kick.sh to make it executable BOINC itself will be crunching away without the GUI, but you can start that manually whenever you want to monitor BOINC. |
|
13)
疑难解答 :
Unix/Linux :
Out of Disk Space Error
(消息 656184)
发表于:8 Oct 2007 作者: Bryn Post: 1. I suspect that Konquerer is lying to you about free space. 1. Konqueror him not speak with forked tongue. ;) 2. KDE doesn't play games like that. Brodo, did you try my suggestion? |
|
14)
疑难解答 :
Unix/Linux :
Out of Disk Space Error
(消息 655116)
发表于:6 Oct 2007 作者: Bryn Post:
Disk use by SAH is pretty modest: one entire BOIC directory, containing the SAH binaries and any project files is currently at a typical 24MB and on another box it's at 81MB - including the World Community Grid binaries and projects, plus some of my garbage. The box using 24MB has a max/min SAH usage of 100MB/0.1MB and IIRC, the other box is similar. But just to check whether it's something related to SAH or not, log out/reboot etc. to 'reset' whatever it is that's causing the problem - but don't start SAH for at least 24 hours after your machine has been running what you'd normally be doing with it. If SAH complains immediately about disk space then the problem lies elsewhere. |
|
15)
疑难解答 :
Unix/Linux :
newbie questions Debian_Seti
(消息 652501)
发表于:1 Oct 2007 作者: Bryn Post: ... but I have no idea how to set it so that works as a screensaver The screensaver hasn't been ported to the Linux versions of seti@home, so you're not doing anything wrong. ;) |
|
16)
疑难解答 :
Unix/Linux :
kubuntu 7.04
(消息 620272)
发表于:16 Aug 2007 作者: Bryn Post: Yes, it will. See this thread here for information. (message 591486, specifically) |
|
17)
疑难解答 :
Unix/Linux :
overheating computer/auto shutdown
(消息 599885)
发表于:7 Jul 2007 作者: Bryn Post:
Well, the situation is pretty much as Dotsch says - sometimes manufacturers cut so many corners to stuff a PC into a tiny sleek case that if it gets used for anything much beyond word processing the whole system just cooks. Unfortunately it's often a case of system build cost or aesthetics triumphing over system design requirements, with the inevitable result of reduced reliability. |
|
18)
疑难解答 :
Unix/Linux :
CPU limited to 50%
(消息 591754)
发表于:24 Jun 2007 作者: Bryn Post:
That's only because no other processes are after the CPU. Or would you rather the CPU sat there looking bored & twiddling its thumbs? ;) Linux resource management actually works, unlike that other OS where the user is often lumbered with making sure there's enough 'spare'. Here's a trivial demo of it in action. Open two shell windows and in one, run 'top'. In the other, run something fairly busy like: find / -type f -exec grep dummyword {} \\; This harmlessly and inefficiently wastes time & resources trying to find the word "dummyword" in every single file on your disk. (ignore the 'permission denied' messages; they're expected) While it's running, watch what happens in the shell running 'top' - notice how the CPU usage for seti changes? Use Ctrl-C to kill the resource-waster and type q to exit 'top'. Don't worry, it's fine. You can drop all that other OS baggage now. ;) |
|
19)
疑难解答 :
Unix/Linux :
How to install boinc software in Ubuntu 7.04 feisty fawn
(消息 591732)
发表于:24 Jun 2007 作者: Bryn Post:
Er, well why not install it and find out? ;) The 'completeness' of the ready-rolled package installations performed on/by Feisty seem to be pretty good from what I've seen so far, so I'd say you'll likely find what you need - probably with any Feisty-specific documentation installed too. But if not, there are previous posts here explaining what to do and links to other sites also. Sometimes you need to just roll up your sleeves and do a spot of reading - but at least you'll end up understanding how to auto-start things, and along the way discover related stuff like finding out if a process is running. BTW: the screensaver hasn't been implemented in the Linux ports. See previous posts. |
|
20)
疑难解答 :
Unix/Linux :
How to install boinc software in Ubuntu 7.04 feisty fawn
(消息 591486)
发表于:24 Jun 2007 作者: Bryn Post: Did anyone try what Neil Walker said a few posts back? You'd be surprised. ;) I did a 'dry run' using the apt-get line he gave and it suggested I add 'boinc-app-seti' - so here's a full dry-run under Feisty. Nothing gets installed; it's just testing if it would install Ok: drop the -s to actually install it all.
Oh look - it works perfectly... |
©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.