All is working ok here...

More than 24h running V8 with no problems...

Running fine here too for almost 36hrs on the Media PC, and 12hrs on the david-quad-core PC's. Installed it yesterday on the T7100 laptop and gave it a workout last night as well - it goes pretty well, as does the E6300 dual core PC in the shed

No problems at all so far, and the RAC's are slowly increasing on the 2 PC's.

---

No further problems to report since yesterdays unexplained crash of the quad. RAC slowly climbing on each machine, up ~80 RAC on each in 24 hours.

---

No further problems to report since yesterdays unexplained crash of the quad. RAC slowly climbing on each machine, up ~80 RAC on each in 24 hours.

My MediaPC has jumped to above 4000 now, and I was going to say 80 is way lower than I am getting, but when I look at it, you are pretty right. In 36 hrs my RAC has jumped from 3900 to 4050 on that PC, and I expect it to top out roughly about the 5,000 mark with a little luck

One thing I noted was that on my E6300 if I got a few WU's with similar AR's then they would crunch within 10 to 15% of the same time. When I gave the T7100 laptop a run last night, all the crunching of the same AR was within probably 90 to 120 seconds - a lot tighter than the old code. Because I have been using the other PC's I cant compare times for the same AR ranges yet

Dave

---

No further problems to report since yesterdays unexplained crash of the quad. RAC slowly climbing on each machine, up ~80 RAC on each in 24 hours.

Mine dropped BOINC again during today while I was not here to monitor it, and, this time, without a message in the WinXP Event Log.

Guess I'll have to reduce the overclock a tad to see if that stabilises things. Thought I had it OK since I did 8 hours + of Prime95 without an error before I let it loose on SETI.

F.

---

No further problems to report since yesterdays unexplained crash of the quad. RAC slowly climbing on each machine, up ~80 RAC on each in 24 hours.

Mine dropped BOINC again during today while I was not here to monitor it, and, this time, without a message in the WinXP Event Log.

Guess I'll have to reduce the overclock a tad to see if that stabilises things. Thought I had it OK since I did 8 hours + of Prime95 without an error before I let it loose on SETI.

F.

The new app works great! on my box temp on core 1 is 62c the rest are cooler. My times have gone from 3 hours to a little over 1 hrs on the WU's no over clocking and running 5.10.45 boinic.

---

Have been keeping up with the AK V8 threads & d/l'ed app as soon as it was available (SSE3 32x3 & SSE3 64x1).

I see that several people have noticed it processing 2 secs for every 1. My 9500 Phemon is doing a funny cycle - 5, 3, 3, 5 secs etc.

Running 5.10.45 & no O/C'ing.

---

.... My 9500 Phemon is doing a funny cycle - 5, 3, 3, 5 secs etc.....

Aaah yes, that kindof symptom is a form of oscillation. It comes from using fixed integer numbers to represent something analog like time. Until your Result Duration Correction Factor (RDCF) adjusts, more than likely the 'proper amount to count down would be something like 4.6secs for every one sec, So it might do 5 twice, then even things out by doing 3 twice.

I suspect, without looking, you were running stock application before which is why the huge steps. Most people count ~2secs/sec are transferring from a previous Opt app, so the jump is less obvious.

Jason

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Can anyone tell me what happened on this WU? I caught my computer coming up from a reboot that was not requested and found this WU next to upload.

Thanks

In fact I am getting random restarts on this computer 5 or 6 times per day now. Have backed off the OC but still happening.

Can anyone tell me what happened on this WU? I caught my computer coming up from a reboot that was not requested and found this WU next to upload.

Thanks

actually yes.. i could do, but you won't like to hear what i will tell you about that one ...

let's just say that someone got confused and compiled/linked it to a very broken boinc version ...

---

Join BOINC United now!

Hi Geek@Pay,
Nice detailed debug output in there, I'm not much good at reading those things, but I notice a couple of things in this output that might be clues:

- There is a "Reason: Access Violation (0xc0000005) at address 0x00430497 read attempt to address 0x00002D6E", which can be memory related, might want to run memtest.

and, the highlighted line on the bottom of the call stack is part of Windows:

- Callstack -
ChildEBP RetAddr Args to Child
0012f264 00405206 034f0040 00004000 41a5df6b 00000000 AK_v8_win_SSSE3x!+0x0
0012f4b8 00403595 00485d35 02710040 00000100 00000040 AK_v8_win_SSSE3x!+0x0
0012fbac 004744fb 004ef780 0012fc78 00477eef 7c919ba0 AK_v8_win_SSSE3x!+0x0
0012fc78 0040d1ac 00000002 006c4160 004b0359 00000002 AK_v8_win_SSSE3x!+0x0
0012fd84 0040d03c 00000001 0012fd9c 001423c0 0012fd9c AK_v8_win_SSSE3x!+0x0
0012ffc0 7c816fd7 005f0038 00690077 7ffd5000 c0000005 AK_v8_win_SSSE3x!+0x0
0012fff0 00000000 0048b897 00000000 78746341 00000020 kernel32!RegisterWaitForInputIdle+0x0

shows that the crash is occurring in the Kernel.(If i'm not reading the thing upside down that is! Murphy says I am ;D)

If not memory, I suspect, for some reason, a funky device driver. Perhaps one went south during a High O/C related attempt. I suggest to back of further and check/reinstall/update chipset and video drivers.

That failing, we'll have to look deeper with the aid of someone more experienced with reading the boinc debugger output dumps.

Hope that Helps,

Jason

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Thanks for the help Jason..........

Have just reinstalled chipset drivers, video driver (new download ATI version) and backed off the OC even more. Will see how it behaves tonight and keep you advised.

[edit]
I have caught it rebooting on it's own many times. When Windows starts up again I always have 1 or more work units complete and ready to upload and 1 or more new work unit just started. I only got the error on that one work unit so far but it's unerving to see so many random restarts.

Good let us know, If it still does weird things don't forget to test that RAM with MemTest86+, just to eliminate one possible cause. It may be the OC for the CPU was fine but a RAM stick or NB chip is either pushed to hard, or broken.

Jason

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Maybe it is too soon to speculate about isues like tis one... I do not want to break out any premature panic :-) what will be the possible grace period, until Eric will incorporate any/most of the inventions, hidden in AK code, into the stock SETI application, and lower its credit per CPU time accordingly?

(If any credit flame war should begin, feel free to move this question somewhere into Cafe/Politics...)

Peter

Pepo, your not he only wondering how long it takes.

---

Well, the sooner he can find the time to do so (and I'm sure it's not top of his priority list) the more science gets done. And that's what this is all about, right?

F.

---

Maybe it is too soon to speculate about isues like tis one... I do not want to break out any premature panic :-) what will be the possible grace period, until Eric will incorporate any/most of the inventions, hidden in AK code, into the stock SETI application, and lower its credit per CPU time accordingly?

(If any credit flame war should begin, feel free to move this question somewhere into Cafe/Politics...)

Peter

Dunno.......maybe Alex, Jason or JD could provide some more insight into the code itself and whether or not portions of it could be added to the stock code. Much of the porting work was platform-specific, and as such, could not be added to the stock code, but there might be some subroutines that would work on all computers regardless of their architecture, perhaps not.

I personally have always considered it a great success story when the contributions of the many folks doing optimizing work resulted in something that could be added to the stock app, thereby increasing the amount of work that the user base could add to the project as a whole.

Having an advantage over the stock app for the users that wish to take the time and effort to install optimized and manually update it when necessary is a fine thing......and adds to the 'fun' side of crunching Seti....

But in the end, if some snippets of code that help us optimizers crunch faster can be added to the stock code to increase the power of the vastly larger number of users who do not optimize, it is a far better thing for the project.....

---

"Time is simply the mechanism that keeps everything from happening all at once."

Maybe it is too soon to speculate about isues like tis one... I do not want to break out any premature panic :-) what will be the possible grace period, until Eric will incorporate any/most of the inventions, hidden in AK code, into the stock SETI application, and lower its credit per CPU time accordingly?

(If any credit flame war should begin, feel free to move this question somewhere into Cafe/Politics...)

Peter

Dunno.......maybe Alex, Jason or JD could provide some more insight into the code itself and whether or not portions of it could be added to the stock code. Much of the porting work was platform-specific, and as such, could not be added to the stock code, but there might be some subroutines that would work on all computers regardless of their architecture, perhaps not.

I personally have always considered it a great success story when the contributions of the many folks doing optimizing work resulted in something that could be added to the stock app, thereby increasing the amount of work that the user base could add to the project as a whole.

Having an advantage over the stock app for the users that wish to take the time and effort to install optimized and manually update it when necessary is a fine thing......and adds to the 'fun' side of crunching Seti....

But in the end, if some snippets of code that help us optimizers crunch faster can be added to the stock code to increase the power of the vastly larger number of users who do not optimize, it is a far better thing for the project.....

< hear hear!!! - somebody go for iT eh . . .

> and Yes (Mark) i 'noticed' the difference (Thanks for the Assist Sir!)

< Accolades to each or You that have done an excellent job here for the Project . . .

---

BOINC Wiki . . .

Science Status Page . . .

Let's See (Just some thoughts on these):
- Insight into the code ... hmmm that calls for my analogy again ... "Swiss Watch made from Wet Noodles"

- Could portions of the code be back ported into stock: Yes, it's been done already before with Lunatics code

- Should it ? complex answer: for project efficiency yes definitely IMO, A lot more work than platform specific opt apps, and can never be quite as fast as it has to be fairly generic. The credits will be lowered then, some people just won't live with that.

Upgrading stock too much has risks too. It might cause the loss of many machines, currently productive set & forget types in particular, through overheating and excessive bandwidth-use raising alarm bells.

Also there are people who drive ferraris that do so because they don't want to be average. On the other hand it is positive pressure from below because of the higher performance of the stock app in recent times that partly influenced adaptation of the AK port... i.e for those people you build a better ferarri, now the stock has to try to catch up again. That's the spirit of competition for mutual benefit.

Technology is something that *hopefully* develops and moves forward. If the stock app stayed completely pre-chicken, and the credit multiplier dropped, would there have been quite so much drive to make 2.4 & V8 ? probably not IMO,

If some competition comes along we might be forced to step this up to the next level. Can you handle this? Personally I need a couple of weeks off ;D

Jason

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

.... My 9500 Phemon is doing a funny cycle - 5, 3, 3, 5 secs etc.....

Aaah yes, that kindof symptom is a form of oscillation. It comes from using fixed integer numbers to represent something analog like time. Until your Result Duration Correction Factor (RDCF) adjusts, more than likely the 'proper amount to count down would be something like 4.6secs for every one sec, So it might do 5 twice, then even things out by doing 3 twice.

I suspect, without looking, you were running stock application before which is why the huge steps. Most people count ~2secs/sec are transferring from a previous Opt app, so the jump is less obvious.

Jason

Yes, originally running stock. Thanks for the clear explanation.

Great work on the porting.

Regards

PJ

---

On my C2D E8400 @ stock 3GHz, Alex Kan's AK version 8.0 SSE4.1 optimized SETI client crunches WUs in 0:50-1:00, much faster than stock client (avg 2:20). CPU temperature is hotter, ~132-138F on AKv8 up from ~122F on stock client. Using Boinc Manager v5.10.45.

---

Sabertooth Z77, i7-3770K@4.2GHz, GTX680, W8.1Pro x64
P5N32-E SLI, C2D E8400@3Ghz, GTX580, Win7SP1Pro x64 & PCLinuxOS2015 x64