Posts by Grand Admiral Thrawn
|
1)
Message boards :
News :
SETI@home hibernation
(Message 2036010)
Posted 5 Mar 2020 by  Grand Admiral Thrawn
Post: I'd just like to thank everybody who was involved in this project. Been there almost from the start, but haven't really done any work for a few years now (5 or so years maybe?). As a last greeting I reconfigured BOINC on my old Linux workstation and re-attached to the SETI@Home project. A small Radeon RX550 is currently saying bye-bye to SETI@Home by computing my final WUs. It's been a great time! |
|
2)
Message boards :
Number crunching :
Rejecting/Avoiding VLAR on an Intel i486 DX4-S/100?
(Message 1365825)
Posted 8 May 2013 by Grand Admiral Thrawn
Post: Ok, it's now at around 33% being 1057 hours into the WU. This is not working. I'm thinking that maybe even a shortie wouldn't make it for the deadline it'd be given. Damn. :( |
|
3)
Message boards :
Number crunching :
I see the whispers are now starting ... NVIDIA Geforce 7 series cards
(Message 1357693)
Posted 17 Apr 2013 by Grand Admiral Thrawn
Post: I was so confused when I saw the threads topic, I assumed somebody wanted to crunch on a GeForce 7800 or something. ;) I think nVidia would call the next incarnation "700 series", just like current Kepler cards, which are "600 series". Correct me if I'm wrong.. but it's not official yet anyway. |
|
4)
Message boards :
Number crunching :
Windows XP 365 days support remaining
(Message 1357070)
Posted 15 Apr 2013 by Grand Admiral Thrawn
Post: I'm still running Win XP x64 Edition on my most modern x86 machine, which is a Core i7 980X, 24GB RAM, two GTX 580s in SLI. For gaming I'm finally approaching the end of the line, but I'm simply refusing to give up on that OS. It's also nice that it can do GPT (other than 32-Bit XP, which can't), that way it was easy to partition my large RAID array. Plus you get StorPort drivers and tons of memory address space. Also I'm picking my hardware with some care, for instance an Intel SSD, because you can TRIM that on XP and XP x64 using Intel tools. I was surprised how good driver support actually is however. Most manufacturers still give you XP x64 kernel drivers, even for my crappy Razer mouse or that Logitech G25 racing wheel.. XP x64 till the bloody end! ;) And after that probably more likely Debian than anything else. Unless I'm willing to give Win7 a chance, but I'm undecided yet. |
|
5)
Message boards :
Number crunching :
Rejecting/Avoiding VLAR on an Intel i486 DX4-S/100?
(Message 1355739)
Posted 11 Apr 2013 by Grand Admiral Thrawn
Post: Just think about it. A true DOS binary would also need TCP/IP installed on DOS. I tried that once (Microsoft offered the software back then), but failed miserably. IPX yes, but TCP... And then it would need XMS/EMS, because conventional 640k are not enough anyway.. I don't think such a thing ever existed? From what I know all SETI applications for MS operating systems were Win32 code. I haven't used the REALLY old SETI classic clients though, I also started with 3.03. So it all comes down to the little optimizations suggested by HAL9000 (switching off benchmarks by launching from CLI with proper options) as well as Terror Australis and Josef W. Segur (disabling BOINC Manager). I'll let the current WU finish which will still take AGES from now and see if I can do the next one in time. ;) I have already completed another project of mine on that box, that took 9 months (!!) to crunch and compute completely on the 486. That's what I had to use Debian for, because I had no idea how to compile and especially LINK the code involved for Win98 and a CPU older than i686 (CygWin toolchains are i686, so..). So Linux. GCC. GNU make. GNU autoconf. 386/486 libs to link against. Easier. So I am used to stuff taking some time. But my other project had no bothersome deadlines to meet... |
|
6)
Message boards :
Number crunching :
Rejecting/Avoiding VLAR on an Intel i486 DX4-S/100?
(Message 1355185)
Posted 10 Apr 2013 by Grand Admiral Thrawn
Post: @HAL9000: Thank you for your tips, that's helpful. Unfortunately keeping Process Explorer running eats a lot more CPU time than keeping explorer.exe running. But I will relaunch the task from the CLI as suggested by you to disable the benchmarking! Should free up at least a little bit! @Cheopis: I never used Memmaker actually (you're talking about [that DOS program], right?). I always wrote my own optimized config.sys/autoexec.bat to free up as much as possible under 640k. But since SETI is Win32, this shouldn't be an issue? Also, I had Linux running on the box already. Running a very minimized low-memory Debian 4.0 kernel with about every kernel module removed and nothing else but the shell and essential core services running made it a good single-purpose system that consumed under 10MB of memory (kernel space + user space!!!) before launching a task. I just don't want to go through all the pain setting it up again. Linux (in a useable form, not the early stuff, mind you) is a lot newer than the 486, so there is lots of trouble getting it to run. Won't go into detail, since this is the wrong place for it. You are right about this being a single-purpose machine though, Cheopis. At least when it comes to what is running at any given time. I have tried turning it into a gaming machine, even for Windows+Glide games (3dfx Voodoo graphics). Also problematic, as many driver libraries and APIs need 586-class machines, but yeah. Now that gaming is no longer an issue, the only thing running on the box is SETI! |
|
7)
Message boards :
Number crunching :
Rejecting/Avoiding VLAR on an Intel i486 DX4-S/100?
(Message 1354950)
Posted 9 Apr 2013 by Grand Admiral Thrawn
Post: Oh man, that's it. I should've closed the BOINC manager! The remaining BOINC is not actually eating much. But the manager was. Closed it now! Unfortunately I can't kill the explorer shell, because Win98 doesn't have a task manager yet. Not in the NT style at least. So I couldn't relaunch it after the kill (not sure whether Win98 would relaunch the shell explorer.exe automatically). It's not eating much CPU anyway and I am using an older version of process explorer as a replacement for the task manager. But having killed Boincmgr already helped a lot! Maybe I should restart the SETI worker though to get it into an L2 cached area in case it's sitting "too high" in memory? Hm. Not sure about how addressing works in 98. |
|
8)
Message boards :
Number crunching :
Rejecting/Avoiding VLAR on an Intel i486 DX4-S/100?
(Message 1354815)
Posted 8 Apr 2013 by Grand Admiral Thrawn
Post: Machine's 100MHz and 128MB of EDO-DRAM with 64MB being cached by L2 (largest possible L2 cache address space with maximum size tag SRAM). The CPU's L1 cache is write-through though, not the slightly faster write-back variant. There is no screensaver active, not the Win98 one and not the SETI one! RAM drive won't do anything? I/O is not limiting the performance, so moving data from disk to RAM would just be a waste of RAM as I see it. From what I can tell it's just the CPU itself slowing everything down. RAM is still ok (quite full, but it's *not* swapping). Also, when the drive is being used, it's not going to be a problem (U160 SCSI with 10.000rpm drive on modern PCI bus using an Adaptec AHA-29160N with Win32 drivers, not Dos16 ones). Of course, for swap it still sucks, as access time and IOPS/s limit stuff, but well, it does not seem to be swapping. I guess the CPU just SUCKS. lol. Edit: What's crap is that BOINC itself already consumes 10-30% of CPU on the system, leaving whatever rest there still is to SETI@Home itself. I mean, what is BOINC even doing there? pffh. ;) |
|
9)
Message boards :
Number crunching :
Rejecting/Avoiding VLAR on an Intel i486 DX4-S/100?
(Message 1354616)
Posted 8 Apr 2013 by Grand Admiral Thrawn
Post: ETA close to 1900 hours now, lol. There is no way this is ever going to work, unless I get lucky with some super-short WU. Maybe rebooting Win98 would also help, cleaning up the memory, but I dunno.. Even if I would re-install Debian 4 on that box (which was an immeasurable pain to get to work), I doubt it would be any faster by custom-compiling the worker app. I mean, custom-compile for what SIMD extensions? There just are none! Not even MMX. I'll let it continue, but it looks grim. ;) |
|
10)
Message boards :
Number crunching :
Don't forget about the Server Relocation on 1st of April !
(Message 1353212)
Posted 4 Apr 2013 by Grand Admiral Thrawn
Post: I didn't flush my DNS caches, but I did restart BOINC on that Linux box. No change for a while. Then, all of a sudden: Thu 04 Apr 2013 09:42:17 AM CEST | SETI@home | update requested by user Thu 04 Apr 2013 09:42:19 AM CEST | SETI@home | Fetching scheduler list Thu 04 Apr 2013 09:42:20 AM CEST | SETI@home | Master file download succeeded Thu 04 Apr 2013 09:42:25 AM CEST | SETI@home | Sending scheduler request: Requested by user. Thu 04 Apr 2013 09:42:25 AM CEST | SETI@home | Reporting 98 completed tasks Meanwhile, 3 hours later it even downloaded a few WUs. Seems ok, maybe just luck or something. :) |
|
11)
Message boards :
Number crunching :
Don't forget about the Server Relocation on 1st of April !
(Message 1353171)
Posted 4 Apr 2013 by Grand Admiral Thrawn
Post: Hm, most of my clients can at least communicate with the servers. However, my Linux box running BOINC 7.1.0 gets stuck at "Fetching scheduler list": Thu 04 Apr 2013 09:25:54 AM CEST | SETI@home | update requested by user Thu 04 Apr 2013 09:25:57 AM CEST | SETI@home | Fetching scheduler list Thu 04 Apr 2013 09:26:14 AM CEST | Project communication failed: attempting access to reference site Thu 04 Apr 2013 09:26:15 AM CEST | Internet access OK - project servers may be temporarily down. |
|
12)
Message boards :
Number crunching :
Rejecting/Avoiding VLAR on an Intel i486 DX4-S/100?
(Message 1352703)
Posted 1 Apr 2013 by Grand Admiral Thrawn
Post: Looking really bad. It's now 159 hours into the VLAR WU, 3.47% done. ETA has risen and risen, now sitting at almost 1800 hours. This is looking bad even when considering Josef W. Segurs information. I think there is no way it can finish before the deadline. |
|
13)
Message boards :
Number crunching :
Would need some help with app_info.xml under Linux (MB+AP+CUDA)
(Message 1352093)
Posted 30 Mar 2013 by Grand Admiral Thrawn
Post: So this is one from the Lunatics Package basically.. ok. Works for me. :) I just logged in via SSH and found that the CUDA worker is currently running on the machine! And CPU load is miniscule, which looks really good! Maybe I'll try adding CPU MB on Tuesday, maybe not, we'll see. But for today it seems that machine is only allowed to turn in 2 results, so I guess it may take some time before it's treated as a trusted cruncher again. It seems to work so far though, thanks! :) |
|
14)
Message boards :
Number crunching :
Would need some help with app_info.xml under Linux (MB+AP+CUDA)
(Message 1351907)
Posted 29 Mar 2013 by Grand Admiral Thrawn
Post: I thought as much. So I'm just gonna wait a little bit and see if it works maybe tomorrow. I have to check that remotely though as I can't physically access the machine until Tuesday. But my custom compiled BOINC build is still running and it might fetch work tomorrow if it's just that protection mechanism kicking in. I also did one hell of a lot of project resets which seems to have worsened the situation considerably.. I assume that the Opera WebGL/OpenGL acceleration was the culprit for the first attempt (where BOINC told me that CUDA WU's were in "scheduler wait" mode). And then I started messing everything up without noticing soon enough were the REAL problem was. That means, that TBar's app_info.xml might just work perfectly, so me blaming it might have been in error. Could have just been Opera filling up my VRAM with its hardware accelerated rendering crap (the Browser is almost always open!), thus preventing CUDA SETI from doing its work. We will see, on Tuesday at the latest. |
|
15)
Message boards :
Number crunching :
Would need some help with app_info.xml under Linux (MB+AP+CUDA)
(Message 1351756)
Posted 29 Mar 2013 by Grand Admiral Thrawn
Post: Sorry for posting so much, but the Edit button seems to go away after some while, maybe to prevent stupid edits? It seems with all the playing around I may have triggered some kind of regret/punishment mechanism in BOINC or on the server. I hope the Your app_info.xml file doesn't have a usable version of SETI@home Enhanced message from the server is linked to that, as I also get this: Fri 29 Mar 2013 12:34:18 PM CET | SETI@home | This computer has finished a daily quota of 1 tasks Means I cannot continue testing I suppose. |
|
16)
Message boards :
Number crunching :
Would need some help with app_info.xml under Linux (MB+AP+CUDA)
(Message 1351750)
Posted 29 Mar 2013 by Grand Admiral Thrawn
Post: Ew, where did the Edit button go? Am I blind? Weird. Ok, the VRAM was actually my fault! I had the experimental hardware acceleration / WebGL active in my Opera browser on Linux. As I am running proprietary nVidia drivers again now (for CUDA..) instead of nv open source drivers (no nouveau for me), the setting in Opera kicked back in and ate almost all my VRAM according to the nvidia-smi cli tool. ;) So that was entirely my fault. Now let's see if it works now... Edit: I don't get it. SAME app_info.xml (copy&paste), resetted project, same apps, and now: Fri 29 Mar 2013 11:38:41 AM CET | SETI@home | Message from server: Your app_info.xml file doesn't have a usable version of SETI@home Enhanced. |
|
17)
Message boards :
Number crunching :
Would need some help with app_info.xml under Linux (MB+AP+CUDA)
(Message 1351736)
Posted 29 Mar 2013 by Grand Admiral Thrawn
Post: Wow, I'd love that. It takes me hours to download just 2-3. Even on my high bandwidth workplace (100Mbit up/down) and also on my "low" bandwidth home workstation with 8Mbit both up and down. Ok, I had a hard time finding a proper 64-Bit BOINC build that would work on my system. There basically is NONE. Why the hell is everybody building for Ubuntu (ew..) as a target system instead of just linking statically? This makes me really angry... So I went through the trouble of compiling my own custom version. To my surprise I got a pre-release BOINC 7.1.0 from git, and to my even bigger surprise it DID compile without trouble on CentOS 6.3. To my MASSIVE surprise it even runs without any linking trouble at runtime. I just need to figure out where it puts stuff (data directory) and then I'm running the most modern BOINC and can try running 64-Bit only with your app_info-xml! Edit: To minimze possible error sources, I used the same worker versions and your app_info.xml, TBar. However, a new problem appears now. While it does work fine for AP, the CUDA WUs all go into "scheduler wait" mode, which seems to be a problem with my GPU load? There is actually no GPU load other than my X11 server running (no 3D stuff on my desktop). Graphics card has 512MB VRAM. |
|
18)
Message boards :
Number crunching :
Would need some help with app_info.xml under Linux (MB+AP+CUDA)
(Message 1351551)
Posted 28 Mar 2013 by Grand Admiral Thrawn
Post: Thanks for the link @Terror Australis, I will study the thread! @TBar: Looking at your app_info.xml, I can't help but notice you don't seem to have a S@H app for the CPU, only AP. Is this intentional? I'd like to run S@H both on CPU and GPU plus AP on CPU (AP WU's aren't always available it seems, plus they're harder to download, so the CPU should also do S@H WUs, when no AP WUs are there to crunch). I wonder whether I could just add a CPU worker to that. Also I may try to get a x86_64 version of BOINC that still runs on my OS and also the x86_64 S@H/MB CPU worker, there are some linked in that other thread. Maybe it works better without bitness or "<platform></platform>" mixing. |
|
19)
Message boards :
Number crunching :
Would need some help with app_info.xml under Linux (MB+AP+CUDA)
(Message 1351483)
Posted 28 Mar 2013 by Grand Admiral Thrawn
Post: Ok, will do! I thought the cuda_fermi might crash on an older G92b GPU or produce invalid results. Still, that leaves the problem with my obviously buggy app_info.xml! Oh, also: My BOINC is x86_32. And yes, I do have all the necessary 32-Bit libraries on my system to run both BOINC itself and the 32-Bit SETI MB worker. Has to be something in app_info.xml, right? |
|
20)
Message boards :
Number crunching :
Would need some help with app_info.xml under Linux (MB+AP+CUDA)
(Message 1351461)
Posted 28 Mar 2013 by Grand Admiral Thrawn
Post: Greetings! I have tried for days, but I just can't get it to work properly. Either my GPU is crunching together with AstroPulse, or only the GPU is crunching, AP is being reset, or I change a few bits in my app_info.xml and it just restarts my CUDA work units on the CPU, what the hell?! Also, I got some reeaaally weird behavior, where the CUDA worker seemingly crunches on the CPU! How is this even possible? Must be a wrong WU? GPU load drops to zero, 1 CPU core is constantly being used 100% by the CUDA (!!) worker and crunching speed is about that of a normal CPU worker. lol. Ok, I just can't do this alone, even googling and searching around didn't really help. What I tried to do is use several of Lunatics app_info.xml examples and adapt them to run the following worker applications together on one system:
setiathome-CUDA-6.08.x86_64-pc-linux-gnu (CUDA, x86_64) ap_6.01r546_sse3_linux64 (Astropulse V6, x86_64)
GeForce GTS 250 (driver: 310.32, CUDA Toolkit installed) CentOS 6.3 Linux, x86_64 BOINC 6.4.4 (newer versions won't run because of the dynamic linking..)
<app_info>
<app>
<name>setiathome_enhanced</name>
</app>
<file_info>
<name>AK_V8_linux32_ssse3</name>
<executable/>
</file_info>
<app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>603</version_num>
<platform>i686-pc-linux-gnu</platform>
<plan_class>sse3</plan_class>
<avg_ncpus>1.000000</avg_ncpus>
<max_ncpus>1.000000</max_ncpus>
<file_ref>
<file_name>AK_V8_linux32_ssse3</file_name>
<main_program/>
</file_ref>
</app_version>
<file_info>
<name>setiathome-CUDA-6.08.x86_64-pc-linux-gnu</name>
<executable/>
</file_info>
<file_info>
<name>libcudart.so.2</name>
<executable/>
</file_info>
<file_info>
<name>libcufft.so.2</name>
<executable/>
</file_info>
<app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>528</version_num>
<platform>x86_64-pc-linux-gnu</platform>
<plan_class>cuda</plan_class>
<avg_ncpus>0.040000</avg_ncpus>
<max_ncpus>0.040000</max_ncpus>
<coproc>
<type>CUDA</type>
<count>1</count>
</coproc>
<file_ref>
<file_name>setiathome-CUDA-6.08.x86_64-pc-linux-gnu</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>libcudart.so.2</file_name>
</file_ref>
<file_ref>
<file_name>libcufft.so.2</file_name>
</file_ref>
</app_version>
<app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>605</version_num>
<platform>x86_64-pc-linux-gnu</platform>
<plan_class>cuda</plan_class>
<avg_ncpus>0.040000</avg_ncpus>
<max_ncpus>0.040000</max_ncpus>
<coproc>
<type>CUDA</type>
<count>1</count>
</coproc>
<file_ref>
<file_name>setiathome-CUDA-6.08.x86_64-pc-linux-gnu</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>libcudart.so.2</file_name>
</file_ref>
<file_ref>
<file_name>libcufft.so.2</file_name>
</file_ref>
</app_version>
<app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>606</version_num>
<platform>x86_64-pc-linux-gnu</platform>
<plan_class>cuda</plan_class>
<avg_ncpus>0.040000</avg_ncpus>
<max_ncpus>0.040000</max_ncpus>
<coproc>
<type>CUDA</type>
<count>1</count>
</coproc>
<file_ref>
<file_name>setiathome-CUDA-6.08.x86_64-pc-linux-gnu</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>libcudart.so.2</file_name>
</file_ref>
<file_ref>
<file_name>libcufft.so.2</file_name>
</file_ref>
</app_version>
<app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>608</version_num>
<platform>x86_64-pc-linux-gnu</platform>
<plan_class>cuda</plan_class>
<avg_ncpus>0.040000</avg_ncpus>
<max_ncpus>0.040000</max_ncpus>
<coproc>
<type>CUDA</type>
<count>1</count>
</coproc>
<file_ref>
<file_name>setiathome-CUDA-6.08.x86_64-pc-linux-gnu</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>libcudart.so.2</file_name>
</file_ref>
<file_ref>
<file_name>libcufft.so.2</file_name>
</file_ref>
</app_version>
<app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>609</version_num>
<platform>x86_64-pc-linux-gnu</platform>
<plan_class>cuda</plan_class>
<avg_ncpus>0.040000</avg_ncpus>
<max_ncpus>0.040000</max_ncpus>
<coproc>
<type>CUDA</type>
<count>1</count>
</coproc>
<file_ref>
<file_name>setiathome-CUDA-6.08.x86_64-pc-linux-gnu</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>libcudart.so.2</file_name>
</file_ref>
<file_ref>
<file_name>libcufft.so.2</file_name>
</file_ref>
</app_version>
<app>
<name>astropulse_v6</name>
</app>
<file_info>
<name>ap_6.01r546_sse3_linux64</name>
<executable/>
</file_info>
<app_version>
<app_name>astropulse_v6</app_name>
<version_num>601</version_num>
<platform>x86_64-pc-linux-gnu</platform>
<plan_class>sse3</plan_class>
<file_ref>
<file_name>ap_6.01r546_sse3_linux64</file_name>
<main_program/>
</file_ref>
</app_version>
</app_info>Help, please! I can't figure it out. :( |
Next 20
©2024 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.