Posts by ivan

Upward and onward goes the Seti search.

Meows and thanks to all who made this happen.

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.

And it looks like we have twice the link capacity now, unless the scale goes higher.

Getting rid of the heat in a controlled manner is a bit more fun - there's at least one data centre that exports its waste heat to other buildings in the area - great in the winter, but a bit on the warm side in the summer (if we ever get one that is)

This Lenovo laptop has 2 video cards, the Nvidia GTX 660M for gaming and the Intel Graphics HD 4000 for everday use, so it may be that the Nvidia card is just no longer running for SETI now with that variable set.

I am not certain, but I am guessing that the Intel is an onboard GPU and you may have to disable it to get the 660m to work properly for crunching.

Blue line is sunk

Edit: looks like it just went down for a byte ( LOL ) and came back up for air again...

Wiggo, I can appreciate your point of view however I only run this one project (as do others), hence our slightly differing views I suppose. All I am asking is that they consider it as a stop gap measure for the period of the outage which in turn would help people like myself keep putting the work through even though the project is down.

The download link is already maxxed out. Even if they rushed around like mad things changing stable configurations, how are you going to download 14 (I make it 15) hours of work in the next 64 minutes?

I don't know where this myth comes from -- it seems it might be necessary with some AMD/ATI co-processors, but I've never seen the need with my Nvidia rigs.

It's not a myth, but it's not a requirement either. At least not on Intel/nVidia rigs.
Leaving a processor idle can slightly improve GPU output by reducing the preprocessing and loading of WUs into the card, especially on rigs that have several GPU cores running.
I am not sure it would provide much benefit on a rig with only a single GPU.

on monday my video card will arrive. before that happens i would like to know a few things. i hear that you can crunch more then one wu on the card at the same time, how is this achieved?

also i have been reading that if you use a gpu to crunch you need to leave 1 core free if so is this just done by changing use at most x processors in muti processor systems to equal in my case 2 less then what my system shows since i have hyperthreading? and if i do crunch more then 1 wu on the card do i have to free up one core per wu running?

Yep! ... My Rig just needed a Good Swift Kick in The Rear Tyre ...LOL :-)

Cheers.

Hello,

Workunit #1 <checkpoint_fraction_done> shows 0.667525
Workunit #1 GUI shows 77% done

The fraction shown should be 67% done, no? I'm at a loss trying to figure out what's causing the discrepancy. Perhaps getting the % done is not as easy as reading the value stored in the xml file?

Any ideas?

OK, so it looks like "something" happened around the time I shut down for the night, that put the display in a funny state and throttled back the computing. Then my switching resolutions fixed the problem (as GPU-Z then reported full power) but one job was so close to its time limit that it ran over, while the second managed to just scrape in.
So it might be worthwhile in future to try changing resolutions down and back to see if that's sufficient to reset the GPU engine, rather than power cycling.
There haven't been any more problems yet.

Yes, sounds like a one off glitch so far. If a soft error occurs at any level (Application host code, GPU code, driver(s), OS-Kernel, hardware) then there's no ECC or other fault tolerant mechanisms to handle that & nVidia opt to enter failsafe operating modes. That in the case of your own glitch, a resolution reset was sufficient to recover normal operation is interesting. It could be effective in some special cases if Boinc or some other tool provided that capability automatically, though I'd certainly be hesitant to implement anything
like a 'catch all safety pin puller', as a failsafe was usually entered for some intentional reason, not always video driver stack or GPU issues.

Hi all.
I'm from Denmark, and our pricing on elektricity is properly the most expensive in the world. 0,352 US$/KWh.

The hardware overhere is also expensive, but the powerbill is just as high a faktor to incalc when you get new hardware.

I wish there was a easy way on this site to quiqly see what produkt/GPU/CPU i could get the most numbercrunching per $ spent on elektricity.

maby there is such a website allready, in that case, please post it here in this post - Thanks in adv.

regards Kim.

My home machine (Athlon 64X2 + GTX 560) has just shown some weirdness. When I sat down to it this morning the display was in a funny state -- not showing the full display but panning around in it when I moved the mouse to the edge of the screen. The display setup still showed 1440x900, so I changed it to a lower resolution and back again and all was well.
Then I looked at boincmgr and realised that the two GPU jobs were taking much longer than normal, well over an hour.

The 11 errored tasks are all

Exit status 197 (0xc5) EXIT_TIME_LIMIT_EXCEEDED

BOINC has killed them, because they ran slow - taking more than 10 times longer than expected. So, an effect, rather than a cause.

It's a known design feature of newer nVidia cards that they enter a protective low-power and low-speed state when "something funny happens", and can only be brought back to full speed by a power cycle (computer reboot).

The trouble is, "something funny" covers a multitude of potential sins - Jason probably has the fullest list, but I doubt even that is exhaustive. Searching for the cause is probably more trouble than it's worth for a single event, but if you start experiencing this frequently, you'll be looking at heat, power, PCIe bus stability, RAM timings, and a whole lot more.

In HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters you need to change Tcp123Opts to the value 3, or add it if its not already there.

Mkay. The Tcp123Opts isnt actually there. Do I need to add it as a new DWORD?

Ill try some regediting on win 8 if you want as tcp optimizer definitely doesnt work. It does have regedit and command prompt (although i think command prompt has been stripped of a lot of useful things if i remember correctly). Might been babystepping on what to input in reg edit though as it has been a loooong while

Now to go see if this can be tweaked on Linux...

We think Linux has it enabled by default, but an actual observation would be interesting.