Posts by 6dj72cn8

1) Message boards : Number crunching : Updating Server Daemons Tonight (Message 28191) Posted 22 Jul 2009 by 6dj72cn8 Post: Haven't touched the awarded credit yet. Making sure the server is running smoothly first :) Oh, OK. Must be natural variation between different searches. Thanks.
2) Message boards : Number crunching : Updating Server Daemons Tonight (Message 28187) Posted 22 Jul 2009 by 6dj72cn8 Post: First one crunched (CPU) and a credit drop of about 4 or 5 per cent. That about what you were aiming for Travis?
3) Message boards : Number crunching : Zero credit (Message 27499) Posted 11 Jul 2009 by 6dj72cn8 Post: Another two hours and twenty minutes down the drain with zero credit. But it just means that a parameter is off and it is is an edge case; it isn't a problem. Yeah, right! Guess what Milky Way? From now on all 210F5_3s tasks are gonna get manually aborted before they get a chance to waste two hours of my electricity!
4) Message boards : Number crunching : More Invalid wu's (Message 26895) Posted 2 Jul 2009 by 6dj72cn8 Post: Of course they give about a third more credits than the 2s WUs! With an exclamation mark, no less. OK, scratch that. Correct to read: 'Some 3s, while not invalidating, run 20–40% longer than others'. On my CPU, since The Great Credit Adjustment of February (or whenever it was), I get about 50cr/hr. Except for quite a few of the recent 3s which seem to run over time and deliver 35-40cr/hr. Not that I am getting all bent out of shape over it. It was just the 'there is no problem' assertion earlier in this thread that I felt like swatting.
5) Message boards : Number crunching : More Invalid wu's (Message 26878) Posted 2 Jul 2009 by 6dj72cn8 Post: I dispute Cluster Physik's 'you shouldn't worry about this'. I only crunch during the eight-hour working day and these invalid tasks can run for almost two hours. It peeves me mightily when 25% of my crunch time is discarded for zero credit. It might not be a worry for those with GPU where only a few minutes worth of crunch is discarded but we don't all have that option. And another thing. All of these 3s tasks run 20-40% longer than 2s tasks. For no extra credit.
6) Message boards : Number crunching : More Invalid wu's (Message 26204) Posted 22 Jun 2009 by 6dj72cn8 Post: Still happening. ps_sgr_210F5_3s_hiw_3234578_1245635997
7) Message boards : Number crunching : ps_sgr_*F_2s_1 (Message 25368) Posted 14 Jun 2009 by 6dj72cn8 Post: Yeah, it's Jedirock's app I'm using.
8) Message boards : Number crunching : ps_sgr_*F_2s_1 (Message 25366) Posted 14 Jun 2009 by 6dj72cn8 Post: But you could try one of the optimized apps to speed it up quite a bit by the use of the SSSE3 version for your Core2. It should finish such a WU within an hour. But nothing there for Mac. From what I remember of the last time we had this discussion, the problem is that no one - volunteers or project admin - is willing to pay $600-odd for the Intel compiler. Still the same?
9) Message boards : Number crunching : Just HAD to say Hi to the Moderator here :-) (Message 24216) Posted 5 Jun 2009 by 6dj72cn8 Post: Get another one. Problem solved. :) -jim Have you ever tried retrofitting a double precision abacus into an iMac? Problem insoluble. :(
10) Message boards : Number crunching : Just HAD to say Hi to the Moderator here :-) (Message 24120) Posted 4 Jun 2009 by 6dj72cn8 Post: Can we believe what Dave Przybylo tells us? Last summer he said he was working at General Electric but when he got back and we asked him for workunits he habitually replied, 'Do you want fries with those?'
11) Message boards : Number crunching : Is milkyway@home dead? (Message 19293) Posted 18 Apr 2009 by 6dj72cn8 Post: I have never seen the ready units level below 400, and I've checked many, many, many, many times. If it ever fell to zero, then 10 minutes later (or whenever the refresh happened), it would have shown as zero (or very, very low). It never has for me. More than enough total work can be created. The bottleneck is that our requests for WUs hammer the scheduler queue so fast that available WUs drain to zero before than the feeder can get the next batch of work in from the work generator. So while the server internally requests for another batch of jobs is generated once the queue drops to about 400-500 (and hence the server status never shows below 400-500) the scheduler actually runs out before the feeder can get the next batch in.
12) Message boards : Number crunching : Optimized OS X Applications (Message 14886) Posted 11 Mar 2009 by 6dj72cn8 Post: That's odd. My 2.8GHz C2D (E8235) has reduced the longer tasks from 35.49 (2149 sec) to 34.20 (2060 sec), a reduction of about 4%. The shorter tasks have gone from 22.05 (1325 sec) to 21.23 (1283 sec), a reduction of about 3%. Maybe my C2D is newer than yours and the stock app was already making use of instructions not available on an older chip?
13) Message boards : Number crunching : Optimized OS X Applications (Message 14882) Posted 11 Mar 2009 by 6dj72cn8 Post: 3 to 4 per cent faster on a C2D.
14) Message boards : Number crunching : Core i7 and Optimized App (Message 12477) Posted 23 Feb 2009 by 6dj72cn8 Post: Whenever the available workunits drops below 400 our assimilator automatically generates 500 new ones. I could tweak these numbers if it's making some of your work requests not go through. I'd suggest you tweak away. It's not unusual to have to ask more than once to get a task sent down the pipe. As it only causes a one or two minute delay at the client end it isn't a problem for us but the repeated requests must be giving the server more to do than is necessary. Mon 23 Feb 10:33:01 \|Sending scheduler request: To fetch work. Requesting 62 seconds of work, reporting 1 Mon 23 Feb 10:33:06 \|Scheduler request succeeded: got 0 new tasks Mon 23 Feb 10:34:07 \|Sending scheduler request: To fetch work. Requesting 224 seconds of work, reporting 0 Mon 23 Feb 10:34:12 \|Scheduler request succeeded: got 0 new tasks Mon 23 Feb 10:35:13 \|Sending scheduler request: To fetch work. Requesting 385 seconds of work, reporting 0 Mon 23 Feb 10:35:18 \|Scheduler request succeeded: got 1 new tasks
15) Message boards : Number crunching : 3rd.in - optimized apps (Message 11576) Posted 19 Feb 2009 by 6dj72cn8 Post: I'm sure there is some logic in there somewhere, but I fail to see it. You say the stock mac app is about half the speed of the optimised Windows app like it's a bad thing. Surely that's good, if the stock Windows app is less than half the speed of the optimised Windows app? Does it not mean the stock mac app is already faster than the stock Windows app? Yes, the stock Mac app might be faster than the stock Windows app, but that isn't the question I am addressing. I am hoping for an optimised app for Mac that will match the optimised apps for Windows and/or Linux. The speed of the stock Windows app is irrelevant.
16) Message boards : Number crunching : 3rd.in - optimized apps (Message 11567) Posted 19 Feb 2009 by 6dj72cn8 Post: Site looks nice now. It would look nicer with some Mac apps on it. I believe Travis has done all he can with the GCC compiler. Too bad that the project can't afford to buy the Intel compiler. From what I can see, the stock Mac app is about half the speed of optimised Windows apps on a Core 2 Duo. Maybe Jedirock can help out at the end of the month. And Crunch3r has occasionally done a Mac app. Heck, anybody!
17) Message boards : Number crunching : Little help for those using opti apps. (Message 10362) Posted 12 Feb 2009 by 6dj72cn8 Post: iMac, May 2008 build, intel E8235, 2.8GHz Mac OS X reports: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM SSE3 MON DSCPL VMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1
18) Message boards : Number crunching : Jan 24 credit change complaints/comments here (Message 9076) Posted 25 Jan 2009 by 6dj72cn8 Post: But it's always good if people compare things without having a clue. Well, from my request for Travis to increase credits by a factor of twenty I thought you might have worked out that my whole post was tongue-in-cheek rather than serious. But perhaps you haven't a clue.
19) Message boards : Number crunching : Jan 24 credit change complaints/comments here (Message 9071) Posted 25 Jan 2009 by 6dj72cn8 Post: Hello. I've just wandered back in here are a stroll through SETI territory. I was checking my tasks and noticed that I had been paired against CUDA on a few. Most of the CUDA results were invalid (which is amusing enough in itself) but a few were passed by the validator. One CUDA was granted 53.81 credit for crunch time of 205 seconds, which equates to a credit grant of 945 per hour. Now given that DA's apparent aim is for all projects to match credit to SETI, I hereby call on Travis to immediately increase granted credit on all MW tasks by a factor of about twenty.
20) Message boards : Number crunching : App v0.10 (Message 8708) Posted 20 Jan 2009 by 6dj72cn8 Post: OS X still takes about twice as long on Intel Mac as it did before. Then it must depend which Intel Mac you have. 0.7, 0.8, 0.9 and 0.10 have all been pretty much the same speed for me. I have two core duo mini's runing Tiger and one core 2 duo MacBook running Leopard. What are you running? I have an iMac Core 2 duo 2.8 (E8235) running 10.5.6. Tasks have been taking the same time as they did last week. (Which is 10-15% slower than they were a month ago but I think that is due to different search parameters.) I certainly have not seen a sudden doubling of crunch time in any of the recent apps. No appreciable difference from 0.7 to 0.12.

Next 20