Posts by JigPu
|
1)
Questions and Answers :
Unix/Linux :
Show Graphics - Redux
(Message 1913047)
Posted 14 Jan 2018 by  JigPu
Post: This is just a response to the (locked) thread titled "Show Graphics" which was posted back in October. In case anyone is interested, graphics are available in the Linux application, but the normal logs don't tell you what's broken when the button doesn't work. The fact that the button isn't greyed out is a sign that the GUI is available: applications without graphics for the platform leave it greyed out (e.g. LHC, Milkyway). In my particular case (Arch Linux), when trying to manually run the graphics app from the command-line, I noticed that "libglut.so.3" was missing: $ cat /var/lib/boinc/slots/*/graphics_app <soft_link>../../projects/setiathome.berkeley.edu/setigraphics_8.00_x86_64-pc-linux-gnu</soft_link> $ /var/lib/boinc/projects/setiathome.berkeley.edu/setigraphics_8.00_x86_64-pc-linux-gnu /var/lib/boinc/projects/setiathome.berkeley.edu/setigraphics_8.00_x86_64-pc-linux-gnu: error while loading shared libraries: libglut.so.3: cannot open shared object file: No such file or directory After installing the "freeglut" package, everything started working -- I could both run the graphics from the command-line and the "Show Graphics" button worked within BOINC Manager. The (somewhat out-of-date) Debian wiki article suggests that another possible problem could be related to X permissions, and that something like xhost +si:localuser:boincmay be necessary in some instances. |
|
2)
Message boards :
Number crunching :
Year 2038 Problem (Devs?)
(Message 252358)
Posted 23 Feb 2006 by JigPu
Post: Using a 64-bit value introduces a new problem date in about 290 billion years, on Sunday, December 4, 292,277,026,596 15:30:08 UTC. This problem is not, however, widely regarded as a pressing issue. OK, that's it. I'm recoding all date functions to use BigDecimal instead of a measly int. Integer part of the BigDecimal will be the number of seconds since Unix Epoch (just to keep things compatible :D). Decimal part will be the fractional number of seconds. Benefits: * Easily allows for the expression of any time, be it past, present, or future. * Integer part directly compatible with Unix Epoch. * Decimal part can be made as precicely as one wishes (for example, if measuring less than a planck time ever turns out to be important :D) Problems: * Can you say "memory hog"? * Slower than integer to update * Arbitrarily sized (making it harder to read/parse dates from files) * Fewer libraries support BigDecimal than support integers or 64-bit integers. (...ok, so I'm not actually. "64-bit should be enough for anybody!" ;)) Puffy |
|
3)
Message boards :
Number crunching :
Upgrading to Vista?
(Message 252348)
Posted 23 Feb 2006 by JigPu
Post: *plays devil's advocate* 1) How often is ANY OS released that you wouldn't call just a "fresh coat of paint?" On the Microsoft side, we've got Win9x (which applies to their 3.1 and earlier OSs too), WinNT, and WinCE if we decide to be really nice. Three essentially different OSs in 19 years. On the Apple front, the past 18 years of MacOS have resulted in anywhere from 3 to 5 unique OS (I would personally lean to 3 since System 6 and 7 seem very similar, along with MacOS 8 and 9, and then the current OSX). 15 years of Linux has brought countless kernel versions, though only three "major" ones -- 0.x, 1.x, 2.x. (Yes, I know linux tends to pack a lot more features within each sub-version than probably any other OS, but it would be exceedingly difficult to make a call for each version to determine if its just new paint.) So that's what? 5.5 years, plus or minus one? Microsoft is the slowest of the bunch when it comes to new kernels, but not by a very significant ammount. Heck, even if you decide that my treatment of Linux is unfair (which I'll admit it probably is), the two commercial companies are still fairly comparable. 2) "Eye candy? Thats what video cards and programs are for, not OS's. I really feel no great craving for a fancy desktop that I don't really look at anyway." It may not be an issue for you, but know tons of people who complained about XP's Fischer Price interface. Yes, that's negative eye candy (eye vegtables? :D) but it still goes to show that there are tons out there who DO care about the issue, stupid as it may be. 3) "Linux has had full seamless filesystem encryption for a long time now, and all done in the kernel software. No external "Trusted Computing Group" or other hardware is involved." I'll consent that Microsoft has been behind on this front. However, if you'd read to the next paragraph, you'll find that Vista dosen't need the hardware either. The hardware (I assume) is there to provide a secure location for the secret key to reside. I don't know any details, but I assume that all you need to decrypt a stolen linux/hardwareless-vista disk is the password. With the TPM (providing MS didn't screw up it's implementation :rolleyes: ), the password could very well be insufficient if the TPM adds salt via an embedded serial number or something. Just keep in mind I'm playing devil's advocate before flaming me :) While I'm not as hard on MS as several of you appear to be, I also don't have much positive to say about Vista (because, frankly, there isn't much to say.) Puffy |
|
4)
Message boards :
Number crunching :
Do we have a Boinc virus?
(Message 249717)
Posted 18 Feb 2006 by JigPu
Post: Good debate going on here :) I with Ned, since I personally know of one user who could hose their linux install. Me. I install enough crap on Linux without giving anything much of a second thought ("Hmmm... I need XXXX." *finds* *downloads* *switches to root as the README says to* *./configure && make && make install*) that it would be downright trivial for malware to hose my system. If somebody in the Linux world were evil enough to package some into a program I downloaded, I probably wouldn't notice until too late. Yes Linux comes out of the box more secure, and I wouldn't doubt can be made more secure than Windows. However, stupidity/ignorance is an amazingly powerful force =D Besides, I can run most windows applications anyway under Linux. Not the other way around. I don't know how much you use Windows (and thus how much it'd be of any use to you), but you may want to check out Cygwin. Most anything you can compile from source should be installable under it (slight modifications may be required on some apps to get the config script to recognize Cygwin as a legit environment though). I've managed to get XFCE installed under it, and can now plop myself down into a linux desktop without ever havign to reboot. JigPu |
|
5)
Message boards :
Number crunching :
I'm a Volunteer Tester?
(Message 231872)
Posted 16 Jan 2006 by JigPu
Post: I was in the first beta test, :( Ditto... Must haven't gotten around to the old DB or something. |
|
6)
Message boards :
Number crunching :
Consuming all my CPU cycles even when I'm working
(Message 230968)
Posted 14 Jan 2006 by JigPu
Post: BOINC will "slow your system down" if your computer has less than 1gb of ram, even if you set it to run only when the computer is completely idle. ...that depends on how much RAM you're using. I have SETI running with zero problems on my parents machine, which is an XP box with a mere 256MB of RAM. The reason it dosen't bog down? There aren't 20 zillion apps running in the tray, and 80 useless services consuming memory. The machine is kept well-pruned and normally consumes from 150-200MB of RAM with SETI running. |
|
7)
Message boards :
Number crunching :
Optimized SETI Client /w Graphics?
(Message 219347)
Posted 21 Dec 2005 by JigPu
Post: I agree with genes, it dosen't have to be all or nothing. That said, I do see where you're coming from by trying to provide everybody with the absolute fastest client possible. I've been tweaking a program of my own for a few years now, sacrificing nothing for the maximum speed (I must have tried 5 different ways of writing a single loop to shave off a few hundredths of a second :D). I haven't a clue how long it takes (or difficult it is) to compile the SETI source, but perhaps it would be possible to compile a version with graphics enabled in addition to your graphics-less client? The solution you mention is inelegant at best, though certianly is a possiblity should none of you on the optimizing team want to go through the trouble of making two versions (or even sacrificing a bit of performance). |
|
8)
Message boards :
Number crunching :
Optimized SETI Client /w Graphics?
(Message 218940)
Posted 20 Dec 2005 by JigPu
Post: Even if the application does not display any graphics, if you want to have it there, it must be compiled in the code. It means redundant unnecessary parts of the code are being parsed many billions times at each WU. Hence, when keeping the code, you have no more optimized application - that's why I wrote it is oxymoron. And it indeed is. ...and what part of the code would that be? Admittedly I haven't studied the code as well as you or the other optimizers (its a huge maze I can't get my head around -- mad props to you all who can understand its structure :)) but from what I understand, the SETI client requires BOINC to call it's graphics routine in order for anything to be shown. The various science bits of code never call even an IF statement (let alone a huge block of graphics code) repeatedly to see if graphics should be shown. Rather, the graphics code when called observes the data the science code produces. If the former were the case, the SETI client would require extensive modification to take out the graphics instead of the lack of a switch at compile time. Furthermore, the optimizations won't magically disappear when the graphics is compiled in. The compiler switches will still affect the science code in the same way, and modifications to the code (such as the cached trig I remember hearing about a while ago...) will remain to reduce the work required for processing. The only thing that would be unoptimized would be the graphics code, but seeing how it uses so little CPU time I wouldn't be so rude as to demand that it is optimized as well :D. Screensaver is worthless and good only for trade shows. The best what you can do for you, for your computer, for BOINC, and for your power bill, is having the OS shut down the monitor after several minutes of inactivity. And have it shut down I do :) During those minutes of inactivity though I'd be nice for something other than a black screen to show up. You may consider it worthess, yet I know lots of people who like to see them (admittedly very few who ALSO demand the most performance from their clients though...). JigPu |
|
9)
Message boards :
Number crunching :
Optimized SETI Client /w Graphics?
(Message 218892)
Posted 20 Dec 2005 by JigPu
Post: It is true that I don't sit for hours on end watching the graphics. However, I think that the graphics are a wonderful feature and I've always hated how the optmized clients didn't include them. I really don't think it's as oxymoronic as people first believe. 1) The screensaver does not "need to be parsed all the rest of the day" as it already can turn itself off after X seconds. If I'm asleep or at school it won't be wasting CPU time. 2) The screensaver does not take up much CPU time at all. I loose about 60 seconds on an otherwise 3 hour WU by displaying them continously. Count in the time that it isn't displaying, and I may end up only 20 seconds behind. At 0.2% CPU load (averaged over a WU) it's not much worse than having an extra two or three processes running, and "costs" me a mere 1 WU out of every 540. 3) The screensaver makes a great recruitment device, and the 0.2% CPU time it consumes uses is well worth (in my opinion) the extra computers I get to join the project. A years worth of crunching (at 20 seconds "lost" per 3 hour WU) ends up costing me 60,000 seconds of CPU time -- easily recouped in a day with a recruited member. Besides, all those running the optimized client on standalone/headless boxes likely have the screensaver set to "none", so compiling with graphics enabled would make no difference if CPU time on a box is absolutely paramount. JigPu |
|
10)
Message boards :
Number crunching :
Optimized SETI Client /w Graphics?
(Message 218878)
Posted 20 Dec 2005 by JigPu
Post: I was wondering if anybody has compiled an optimized SETI client with the graphics enabled. I've been using various optimized clients for a while now, but miss seeing the graphics (and the new crunchers I get when people ask what the graphics are :D). Puffy |
|
11)
Message boards :
Number crunching :
Suggestion: Create bittorrent stream for BOINC core client d/l's
(Message 205290)
Posted 7 Dec 2005 by JigPu
Post: Less of a waste than you think, actually. Firstly, BOINC and SETI tend to share servers since they're run by the exact same guys in the exact same place in Berkeley. Actually, according to the Technical News, you'll see that they recently moved the BOINC client downloads to "Penguin" -- listed under the SETI servers as being the transitioner server. Secondly, it's not just a tiny fraction of bandwidth we're talking about. BOINC/SETI has a 100Mbit Cogent link at their disposal which all their traffic runs across. In the Technical News, they mention that they moved the BOINC client downloads to a different server (located on the UC Berkeley campus network), causing an increase of about 20Mbits/second of traffic. Basically, BOINC client downloads are apparently the cause of 20% of the traffic. I'm all for a bittorrent setup -- not everybody will make use of it, but it should reduce the load somewhat. |
|
12)
Message boards :
Number crunching :
apple "quad" core G5
(Message 185642)
Posted 4 Nov 2005 by JigPu
Post: Personally, my dream machine has always been powered by this board: Tyan Thunder K8QSD Pro S4882UG2N-D - $1372 Nothing like support for quad dual-core (meaning 8 cores total) :D Of course, there's nothing like the price either :eek: :eek: |
|
13)
Message boards :
Number crunching :
Slowly Uploading
(Message 161200)
Posted 1 Sep 2005 by JigPu
Post: Now THAT'S a tweak! I've just uploaded over 20WUs in less than probably 30 minutes :) Can't complain about that!! Puffy |
|
14)
Message boards :
Number crunching :
Cookies being set within SETI message boards!
(Message 151970)
Posted 15 Aug 2005 by JigPu
Post: I've got the cookie you've mentioned as well, and after viewing the source of the thread, there are two images (from the original poster's sig) which use the notlong.com domain. notlong.com is a URL redirection service, so I'm betting that they're the ones setting the cookie whenever you access "fil.notlong.com", "fil3.notlong.com", or "fil4.notlong.com". Puffy |
|
15)
Message boards :
Number crunching :
Wishlist - What is the status of it today?
(Message 148700)
Posted 8 Aug 2005 by JigPu
Post: <font>Wish:</font> To either allow network access while on batteries, or to include an option in the global prefs to allow such (since uploading/downloading new work does NOT eat the batteries). |
|
16)
Message boards :
Number crunching :
this system bites
(Message 131530)
Posted 2 Jul 2005 by JigPu
Post: Randy has my point exactly. The credit granting process is just screwed up. Yes it does happen, and yes it is annoying. However, the credit situation IS being worked on from what I can tell. Initially the big credit bug was non-Windows clients claiming substantially lower credits. As with most things in BOINC, it seemed for a long time as though the Devs weren't doing anything about it. However, eventually "fixed" clients sprang out seemingly out of nowhere. The Devs aren't extrordinarily vocal about what is going on here in the S@H forums, though there's supposedly quite a bit of work always going on in their mailing list. Nowdays incorrect credits have once again reared its ugly head and people are rightfully complaining about the issue. Again, it dosen't really seem as though much is being done to fix the problem, yet there have been hints from a few members as to what's going on in the dev list, and it seems as though they honestly are working toward some kind of real fix to the situation. Either give BOINC a chance for now, or go back to Classic and wait it out. The problem WILL be fixed, you just have to be patient (though more of these nagging threads about the problem certianly help highlight it as a very important issue :)), wether that means being patient while polishing off a milestone in Classic or BOINC. Puffy |
|
17)
Message boards :
Number crunching :
Severe priority bug in 4.18 (Windows)
(Message 129020)
Posted 27 Jun 2005 by JigPu
Post: >>> What about making priority level settings user-adjustable? The only problem with this is that the priority setting will be "lost" every time the science client closes. If you don't have the "keep applications in memory" option, then it will happen every hour (or however long you have it set to switch). If you have the applicaitons kept in memory, it might work, but I think that the application will re-open itself every WU (meaning you'll have to re set the priority every time a WU finishes). Puffy |
|
18)
Message boards :
Number crunching :
Estimated finish time 4 hours actual 2
(Message 127222)
Posted 24 Jun 2005 by JigPu
Post: It's nothing but a kludge as the developers seems to admit that they can't determine a valid (or close to valid) completion time. The new scheduler brought this to the forefront, as panic mode happens when it shouldn't! I'm not saying it's the perfect fix, but if it helps, why not? I'm all for fixing the root cause (more realistic benchmarking), but apparently that's taking a while for the developers to push through. Better to at least partially "fix" the problem now than wait forever for a more comprehensive solution IMHO. /me is a programmer and knows perfectly well how undesirable hacks/kludges are. However, I also know that a hack is far better than no solution at all (provided you spend time after implementing the hack to actually put in a real fix). Puffy |
|
19)
Message boards :
Number crunching :
Estimated finish time 4 hours actual 2
(Message 127208)
Posted 24 Jun 2005 by JigPu
Post: 4.46 will have code in it that will slowly self correct toward lower actual crunch times. It will very quickly correct for higher actual crunch times. It maintains a correction factor per project that is used for initial estimates. The estimate es re-calculated after every WU complete. The reason for lowering the estimate slowly is caution about S@H noise WUs. Is this revised time estimation also used by BOINC when determining how much work to download? What with some clients only downloading 1/2 or 1/3 of their "connect every" value because of the poor estimations, it would certianly be useful :) Puffy |
|
20)
Message boards :
Number crunching :
Topping off the cache - Idea
(Message 117988)
Posted 3 Jun 2005 by JigPu
Post: The download scheduler attempts to keep enough work in the cache to ride out being disconnected for the size of the queue. I'm not 100% sure how this works (I haven't found a good explination, and the source code is too hard to navigate for a C++ newbie of my caliber), though it seems as though at least one or two modem users are managing to not have enough data in their caches. From what I've read, it sounds as if the problem is BOINC downloading X days of work (where X is the "connect to network about every..." setting), and then downloading new work once the cache is depleted. A modem user may very well be offline when the cache depletes though, leaving them idle until they can reconnect. If they have only 1 WU remaining in the cache, they would either need to remain connected until the WU finishes (so the cache can refill), or disconnect and allow the idle time. This could be fixed obviously through the use of a button as I suggested, though yet more tweaks to BOINC itself could also do it. One possible solution would be to keep track of how often the user has a net connection (would this be the already existing "% of time host is connected"?), and then kick in the download scheduler once CONNECT_TO_NET_EVERY_X_DAYS * NET_CONNECTED_% has passed (and keep attempting to connect every 30 minutes or so). For example, if a host is set to connect to the net every 3 days, and is connected 50% of the time, begin attempting to download new work (to fill the whole 3 day cache once more) once 1.5 days of work has been processed. This may cause connections quite a bit earlier than set in the preferences, and will likely throw in a lot more errors into the Messages while it can't find the projects due to disconnection. However, it should allow connection attempts early enough that the host will likely reconnect before depleting the cache, which is a must for them modem users. Just throwing out ideas :) Puffy |
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.