Posts by Karsten Vinding

1) Message boards : Number crunching : Lunatics Windows Installer v0.41 Release Notes (Message 1376574)
Posted 4 Jun 2013 by Profile Karsten Vinding
I was just a bit tweaked when someone simply waved off SSE3 when we (AMD K10 users) had an excellent one once. Seeing how many of the super crunchers who helped test during the V7 beta are overwhelmingly Intel/Cuda, I just wanted to stand up and remind everyone that not all crunchers are Intel/Cuda.

It was partially me that waved off the SSE3 app.

I'm one of the Alfa testers on Lunatics, and though I havent been very active on their forums this time (many personal things have taken precedence), I have tested the various versions.

My rigs are all AMD, and my second cruncher is a Phenom II. On this machine the difference between SSE2 and SSE3 versions of the new app was small, SSE2 sometimes fastest, SSE3 other times. This could probably change.

Therefore I see no problem with the team concentrating on a few major versions to get it out fast. There are also no SSE4 versions, because the gains were small compared to SSSE3, and it was prioritized to get the installer out fast.

You must understand they where under some time pressure, because of the short windows between release on main, and promised release on Lunatics.

I havent tested the final version (of SSE3) yet, so cant tell how big the difference is, but I guess it will be small.

But of course every little bit counts :)

Regarding the old AKV8B_SSE3_AMD, I was actually one of the testers (as I remember we were only 2 or 3 testers), who in cooperation with Jason Gee tested an app that turned out to be faster on all the CPU's I had at the time.
If I remember correctly (Jason can correct me if I have the facts wrong), the app was mainly faster because it left out a (IPP?) library, that handicaped AMD, and used another instead. The actual amount of SSE3 code was not very great it was basically the SSE3 app tweaked a little, with some parts replaced (some of it by SSE2 code). The app did require SSE3 to run, it didn't use it all that much.
2) Message boards : Number crunching : Lunatics Windows Installer v0.41 Release Notes (Message 1375997)
Posted 3 Jun 2013 by Profile Karsten Vinding
There is a readme for the AKv8c apps in the docs folder.

AFAIK the only command line argument has to do with verbosity. No parameters are available that would speed up crunching.
The apps do some testing themselves and choose optimum settings for each cruncher, between a lot of different options.
3) Message boards : Number crunching : Lunatics Windows Installer v0.41 Release Notes (Message 1375992)
Posted 3 Jun 2013 by Profile Karsten Vinding
Currently there is no SSE3 app.

Due to time constraints, the team decided to focus on SSE2, SSSE3 and AVX development.
The gain from going from SSE2 to SSE3 has been very small on many never architectures, so it was decided to skip SSE3 for know and perhaps include it in a later installer.

So your installer is working as it should.

The AVX ought to be the fastest on hardware that supports it.
4) Message boards : Number crunching : SETI Hardware Fundraisers: 2013 The Year of the Servers (Message 1355437)
Posted 10 Apr 2013 by Profile Karsten Vinding
I think its a little disturbing that the last time his computer reported anything was about a month ago.
5) Message boards : Number crunching : WE'RE UP !!!! (Message 1352971)
Posted 3 Apr 2013 by Profile Karsten Vinding
Thats because of the way the jobs are being transferred between splitters/upload queue/upload servers.

Files are going out, and at more than twice the speed at which they did before the server relocation.

I bet that with more tweaking, the speeds will be even better, and work will be more constantly available.
6) Message boards : Number crunching : Don't forget about the Server Relocation on 1st of April ! (Message 1352967)
Posted 3 Apr 2013 by Profile Karsten Vinding
The link just passed 200Mbit:

Cur: 203.20 Mbits/sec
7) Message boards : Number crunching : Panic Mode On (82) Server Problems? (Message 1352961)
Posted 3 Apr 2013 by Profile Karsten Vinding
I just got 3 AP WU's on main, at 250kB pr second.

Very good :)
8) Message boards : Number crunching : Script for Affinity & Priority Management (Message 1346865)
Posted 15 Mar 2013 by Profile Karsten Vinding

Do you account for different input data patterns for app itself? It's known fact that not all input data can be processed evenly good with current GPU apps.

I don't and I don't think I can.

It's not a criticism of the apps or the work the developers do.

It's frustration over the fact that you cannot get your crunching up to the _full_ potential, because of some obscure bug or decission made by the driver developers.

I have to run with two cores disabled to have the highest throughput on average. But I'm convinced that if the AMD (and nVidia) developers worked on this, this problem could be removed or at least reduced to a point where we could use all cores, and stil have full GPU utilization.
9) Message boards : Number crunching : Script for Affinity & Priority Management (Message 1346757)
Posted 15 Mar 2013 by Profile Karsten Vinding
Well, sadly today the performance according to GPU-z was down again to between 85 and 92%, and never reached 100%.

Removing one CPU thread helped a little. But to get back to 100% GPU usage I had to go back to crunching on 6 cores, and give GPU 2 free cores. Now I'm at 99-100% again.

Its a little frustrating that the system reacts so differently from day to day, and I dont see any pattern to it.
10) Message boards : Number crunching : Super Slow Downloads (Message 1346247)
Posted 13 Mar 2013 by Profile Karsten Vinding
That is the unfortunate result af a lot of shorties (WU's that crunch very fast) having been sent out, and Seti's upload line being overloaded, so that DL come through very slow.
The TCP fix does solve some of it, but the problem is still there.

And then there is the fact that we are recovering from the weekly outage, which makes the demands on servers and bandwith even larger.

As long as Seti is as bandwith constrained as they are, the problem will persist.
11) Message boards : Number crunching : Script for Affinity & Priority Management (Message 1346218)
Posted 13 Mar 2013 by Profile Karsten Vinding
After looking at Raistmers results I decided to try it with 8 cores active with no affinity, and with GPU affinity set to core 0 (with Prolaso).

I got this:

With 7 cores active, affinity set to cores 1-7, and GPU on 0 I got this.

There is a _small_ difference. Probably 3-4%

This is a much better result than what I saw yesterday, probably because yesterday I locked the GPU to core 1 instead of core 0. Probably because I misunderstood something in the process.

Now I havent seen a heavy blanked WU yet, or seen if the GPU usage bug rears it head again, but if this keeps looking this good, I will probably be crunching on all cylinders again. And be happy doing it :)

It must be said that these are AP WU's being crunched, I dont know how MB will react.
12) Message boards : Number crunching : Script for Affinity & Priority Management (Message 1346212)
Posted 13 Mar 2013 by Profile Karsten Vinding
Don't mind, read my next post.
13) Message boards : Number crunching : Script for Affinity & Priority Management (Message 1345929)
Posted 12 Mar 2013 by Profile Karsten Vinding

That is exactly what I have found. It is consistent and repeatable. I've been running with all cores loaded with CPU jobs and full GPU utilization for months using that technique.

No cores idled. It works even if the CPU processes are at higher priority than the GPU process.

The initial motivation to write the script was so I could vary the core that the GPU process is assigned to instead of it always being forced to the same core with ProLasso. Eventually I added other stuff.

Not to un-validate your findings, but I don't see this on my system.

On my system when I set GPU-tasks affinity to one single core (I run 2 GPU tasks at a time), I emidiatly get a 8-10% drop in GPU utilization as seen by GPU-z.

I tried many settings, GPU app affinity set to 2 cores and to 1 core, with cpu crunching on 6, 7 and 8 cores (affinity set accordingly to this number, and set to avoid the cores assigned to GPU, if possible). Only when the CPU is set to crunch on only 6 cores do I get a steady 100% GPU utilization. Any more than 6 cores, I get the slowdown no matter how I setup GPU-tasks affinity.

As the GPU crunches _much_ faster than my CPU cores, these 8-10% are worth sacrificing 2 cores on the CPU, the end RAC still is higher.

It may be up to something in my setup, I dont know, but I cannot confirm that your method works.
14) Message boards : Number crunching : Windows TCP Settings - Follow up - Help with server communication (Message 1345374)
Posted 11 Mar 2013 by Profile Karsten Vinding
I undertand the reason for this change and that it is not to increase or improve speed. However my problem with speed was outside of BOINC. In fact some sites are just fine I can at normal speed from and if others don't see speed issues it must be something with my corporate firewall or the Dell website. I have two Identical Win7x64 systems here in my office on one I applied the TCP1323 option and on the other the default windows. When I try to download from the Dell support site the pc with this setting changed only gets about 2KBps the system without this setting is connected to the same switch and is getting 100KBps.

Can someone with Win7x64 who applied this try downloading this video driver from the dell site see what kinda of speed you get. I think it is just an isolated to the website?

I got about 850kB/s on my 10Mbit ADSL line, which is about 85% of possible speed.
15) Message boards : Number crunching : Windows TCP Settings - Follow up - Help with server communication (Message 1343495)
Posted 6 Mar 2013 by Profile Karsten Vinding
I have just had the unexplainable pleasure of watching 4 simultaneous AP WU DL's run from start to finish without interruption.

I have done many changes to my settings, more simultaneous DL's, running a program to restart stopped DL's every 15 minutes, changing timeout settings, and many other small things.

To think that this relatively small change (timestamps (scaling was allready turned on)), would do such a difference...

I kept an eye on the DL's, and watched some allmost sure signs of a failed DL (pause for 5-10 seconds), just to see the DL's continue. Fantastic!

Thank you to the guys who found this fix :)
16) Message boards : Number crunching : Whats going on here? (Message 1334112)
Posted 2 Feb 2013 by Profile Karsten Vinding
I have this _old_ WU hanging in my validated list:

It validated months ago, and I got credit (I'm the anonymous platform). But computre 6295561 is still waiting for validation (since the end of september), so the WU still shows up in my list.

When will 6295561 get credit and the WU dissapear from my list?
17) Message boards : Number crunching : AVG just trashed AK_v8b_win_SSSE3x.exe (Message 1327962)
Posted 16 Jan 2013 by Profile Karsten Vinding
Some years ago, I was using Antivir as my primary AV program.

After an update that program decided to quarantine my Boinc installation. This was fixed, but after some time it decided to do it again.

This made me switch to AVG, which I used for a long time with few problems. But then MS made Security Essentials, I uninstalled AVG, installed MSE, and havent looked back.
18) Message boards : Number crunching : What Motherboards are you using? (Message 1281027)
Posted 7 Sep 2012 by Profile Karsten Vinding
All Asus here also (right now).

An _old_ A8R-MVP (socket 939), still going strong 24/7.

An M4A78-E, in an Ubuntu PC, that's basicly a backup, not running at the moment, but runs 24/7 stable, when its on. Its meant to replace the above computer one day, when I get it setup properly.

And a Sabertooth 990FX in my primary computer, rock solid stable, even at a nice OC. Best board I have owned.

I have had Gigabyte, MSI and others and they have been nice too, but I mostly end up with ASUS.
19) Message boards : Number crunching : Strange problem with dual-core machine (Message 1243541)
Posted 8 Jun 2012 by Profile Karsten Vinding
I have had it on my main computer too.

It turned out to be milkyway's nbody multithreaded app, that made boinc do this.

Some times when nbody had been running and using all eight cores, a number of cores would not start to crunch again afterwords.

Boinc would sometimes resume anything from 5 to 8 task (at seldom times even fever), leaving the rest of the cores idle. Most of the times all cores would start again, though

But since the nbody WU's crunched very fast, and I had many in my cache, the system would end up in this state quite often anyhow.

I ended up dropping milkyway/nbody for this reason, and havent tested it with never versions of the boinc client.

If you are running milkyway, this could be what is happening on your system as well.
20) Message boards : Number crunching : Welcome to the 13 year club (Message 1234197)
Posted 20 May 2012 by Profile Karsten Vinding
Well, 13 years and two days.

And 119 posts.

Have been crunching non stop, though not exclusively Seti.

Was even crunching before Seti, but that was at and even earlier projects.

Also a little folding has been done, but mostly on my PS3.

Next 20

©2016 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.