Linux GPU3 (fermi) Corestatus = 63 (99)

Moderators: slegrand, Site Moderators, PandeGroup

Linux GPU3 (fermi) Corestatus = 63 (99)

Postby Xaero » Sun Mar 06, 2011 10:39 pm

Okay, so I've spent a lot of time troubleshooting this on my own, heres my journey so far:
At first after I installed everything "per the headless install guide" like I usually do, (not my first time setting it up, just my first fermi/gpu3 setup) I got a corestatus = 00000C135 which I found to be NOT related to improper links but lack of a few newer dlls that I was able to just toss into the GPU3 folder and then removed all of the working files and it fetched a new core15 and initialized it... but to my dismay it now gives the following output:
Code: Select all
--- Opening Log file [March 4 22:23:21 UTC]


# Windows GPU Console Edition #################################################
###############################################################################

                       Folding@Home Client Version 6.30r1

                          http://folding.stanford.edu

###############################################################################
###############################################################################

Launch directory: Z:\opt\fah-gpu\alpha
Executable: Z:\opt\fah-gpu\Folding@home-Win32-GPU.exe
Arguments: -forcegpu nvidia_fermi -gpu 1 -verbosity 9

[22:23:21] - Ask before connecting: No
[22:23:21] - User name: zero-x[49036] (Team 86565)
[22:23:21] - User ID: 39C7C7E6317C1AB7
[22:23:21] - Machine ID: 2
[22:23:21]
[22:23:21] Gpu species not recognized.
[22:23:21] Work directory not found. Creating...
[22:23:21] Could not open work queue, generating new queue...
[22:23:21] - Preparing to get new work unit...
[22:23:21] Cleaning up work directory
[22:23:21] - Autosending finished units... [March 4 22:23:21 UTC]
[22:23:21] Trying to send all finished work units
[22:23:21] + No unsent completed units remaining.
[22:23:21] - Autosend completed
[22:23:21] - Will indicate memory of 3821 MB
[22:23:21] Gpu species not recognized.
[22:23:21] - Detect CPU. Vendor: GenuineIntel, Family: 6, Model: 10, Stepping: 5
[22:23:21] - Connecting to assignment server
[22:23:21] Connecting to http://assign-GPU.stanford.edu:8080/
[22:23:21] Posted data.
[22:23:21] Initial: 40AB; - Successful: assigned to (171.64.65.64).
[22:23:21] + News From Folding@Home: Welcome to Folding@Home
[22:23:21] Loaded queue successfully.
[22:23:21] Gpu species not recognized.
[22:23:21] Sent data
[22:23:21] Connecting to http://171.64.65.64:8080/
[22:23:21] Posted data.
[22:23:21] Initial: 0000; - Receiving payload (expected size: 43807)
[22:23:21] Conversation time very short, giving reduced weight in bandwidth avg
[22:23:21] - Downloaded at ~85 kB/s
[22:23:21] - Averaged speed for that direction ~85 kB/s
[22:23:21] + Received work.
[22:23:21] + Closed connections
[22:23:21]
[22:23:21] + Processing work unit
[22:23:21] Core required: FahCore_15.exe
[22:23:21] Core not found.
[22:23:21] - Core is not present or corrupted.
[22:23:21] - Attempting to download new core...
[22:23:21] + Downloading new core: FahCore_15.exe
[22:23:21] Downloading core (/~pande/Win32/x86/NVIDIA/Fermi/Core_15.fah from www.stanford.edu)
[22:23:21] Initial: AFDE; + 10240 bytes downloaded
[22:23:22] Initial: 4A9F; + 20480 bytes downloaded
[22:23:22] Initial: 02DB; + 30720 bytes downloaded
[22:23:22] Initial: 32D2; + 40960 bytes downloaded
[22:23:22] Initial: 0664; + 51200 bytes downloaded
[22:23:22] Initial: 0400; + 61440 bytes downloaded
[22:23:22] Initial: 3AB8; + 71680 bytes downloaded
[22:23:22] Initial: F8D2; + 81920 bytes downloaded
[22:23:22] Initial: F4EE; + 92160 bytes downloaded
[22:23:22] Initial: ECE1; + 102400 bytes downloaded
[22:23:22] Initial: 9A21; + 112640 bytes downloaded
[22:23:22] Initial: 4572; + 122880 bytes downloaded
[22:23:22] Initial: A5AF; + 133120 bytes downloaded
[22:23:22] Initial: AE73; + 143360 bytes downloaded
[22:23:22] Initial: 324F; + 153600 bytes downloaded
[22:23:22] Initial: 6A97; + 163840 bytes downloaded
[22:23:22] Initial: E123; + 174080 bytes downloaded
[22:23:22] Initial: 5426; + 184320 bytes downloaded
[22:23:22] Initial: 9D76; + 194560 bytes downloaded
[22:23:22] Initial: 2226; + 204800 bytes downloaded
[22:23:22] Initial: FE64; + 215040 bytes downloaded
[22:23:22] Initial: F9F2; + 225280 bytes downloaded
[22:23:22] Initial: 4F35; + 235520 bytes downloaded
[22:23:22] Initial: D07D; + 245760 bytes downloaded
[22:23:22] Initial: 9E40; + 256000 bytes downloaded
[22:23:22] Initial: 38A2; + 266240 bytes downloaded
[22:23:22] Initial: BD94; + 276480 bytes downloaded
[22:23:22] Initial: 4BAC; + 286720 bytes downloaded
[22:23:22] Initial: D740; + 296960 bytes downloaded
[22:23:22] Initial: B43A; + 307200 bytes downloaded
[22:23:22] Initial: 4B3F; + 317440 bytes downloaded
[22:23:22] Initial: BDD0; + 327680 bytes downloaded
[22:23:22] Initial: 18EB; + 337920 bytes downloaded
[22:23:22] Initial: E612; + 348160 bytes downloaded
[22:23:22] Initial: BD4D; + 358400 bytes downloaded
[22:23:22] Initial: D804; + 368640 bytes downloaded
[22:23:22] Initial: B7D0; + 378880 bytes downloaded
[22:23:22] Initial: 6492; + 389120 bytes downloaded
[22:23:22] Initial: B390; + 399360 bytes downloaded
[22:23:22] Initial: 2ADA; + 409600 bytes downloaded
[22:23:22] Initial: BAB5; + 419840 bytes downloaded
[22:23:22] Initial: BC78; + 430080 bytes downloaded
[22:23:22] Initial: 1119; + 440320 bytes downloaded
[22:23:22] Initial: 27B1; + 450560 bytes downloaded
[22:23:22] Initial: 8A2A; + 460800 bytes downloaded
[22:23:22] Initial: 6F27; + 471040 bytes downloaded
[22:23:22] Initial: FFFF; + 481280 bytes downloaded
[22:23:22] Initial: D0B6; + 491520 bytes downloaded
[22:23:22] Initial: 0702; + 501760 bytes downloaded
[22:23:22] Initial: 08C1; + 512000 bytes downloaded
[22:23:22] Initial: E64B; + 522240 bytes downloaded
[22:23:22] Initial: F5F0; + 532480 bytes downloaded
[22:23:22] Initial: 98CB; + 542720 bytes downloaded
[22:23:22] Initial: 2477; + 552960 bytes downloaded
[22:23:22] Initial: 494C; + 563200 bytes downloaded
[22:23:22] Initial: 4D49; + 573440 bytes downloaded
[22:23:22] Initial: C6C8; + 583680 bytes downloaded
[22:23:22] Initial: 2D13; + 593920 bytes downloaded
[22:23:22] Initial: 03F9; + 604160 bytes downloaded
[22:23:22] Initial: 1315; + 614400 bytes downloaded
[22:23:22] Initial: 0887; + 624640 bytes downloaded
[22:23:22] Initial: 5BA1; + 634880 bytes downloaded
[22:23:22] Initial: E140; + 645120 bytes downloaded
[22:23:22] Initial: 1E9D; + 655360 bytes downloaded
[22:23:22] Initial: 6C1A; + 665600 bytes downloaded
[22:23:22] Initial: 8A4A; + 675840 bytes downloaded
[22:23:22] Initial: 57FD; + 686080 bytes downloaded
[22:23:23] Initial: F8E0; + 696320 bytes downloaded
[22:23:23] Initial: 0CD1; + 706560 bytes downloaded
[22:23:23] Initial: D1E2; + 716800 bytes downloaded
[22:23:23] Initial: 9CA8; + 727040 bytes downloaded
[22:23:23] Initial: 7F13; + 737280 bytes downloaded
[22:23:23] Initial: 3231; + 747520 bytes downloaded
[22:23:23] Initial: 5F16; + 757760 bytes downloaded
[22:23:23] Initial: BF95; + 768000 bytes downloaded
[22:23:23] Initial: 70A4; + 778240 bytes downloaded
[22:23:23] Initial: 6D26; + 788480 bytes downloaded
[22:23:23] Initial: 13C7; + 798720 bytes downloaded
[22:23:23] Initial: 9F26; + 808960 bytes downloaded
[22:23:23] Initial: C7B5; + 819200 bytes downloaded
[22:23:23] Initial: D5A9; + 829440 bytes downloaded
[22:23:23] Initial: F796; + 839680 bytes downloaded
[22:23:23] Initial: A004; + 849920 bytes downloaded
[22:23:23] Initial: 1011; + 860160 bytes downloaded
[22:23:23] Initial: 3F6F; + 870400 bytes downloaded
[22:23:23] Initial: B01C; + 880640 bytes downloaded
[22:23:23] Initial: E903; + 890880 bytes downloaded
[22:23:23] Initial: 29D0; + 901120 bytes downloaded
[22:23:23] Initial: 3DD6; + 911360 bytes downloaded
[22:23:23] Initial: D5BF; + 921600 bytes downloaded
[22:23:23] Initial: EC69; + 931840 bytes downloaded
[22:23:23] Initial: 1A1D; + 942080 bytes downloaded
[22:23:23] Initial: 7BC0; + 952320 bytes downloaded
[22:23:23] Initial: 9C4E; + 962560 bytes downloaded
[22:23:23] Initial: 9C59; + 972800 bytes downloaded
[22:23:23] Initial: 7BBD; + 983040 bytes downloaded
[22:23:23] Initial: D395; + 993280 bytes downloaded
[22:23:23] Initial: 5239; + 1003520 bytes downloaded
[22:23:23] Initial: BE83; + 1013760 bytes downloaded
[22:23:23] Initial: 428D; + 1024000 bytes downloaded
[22:23:23] Initial: E2EE; + 1034240 bytes downloaded
[22:23:23] Initial: 64BB; + 1044480 bytes downloaded
[22:23:23] Initial: 7200; + 1054720 bytes downloaded
[22:23:23] Initial: 71BB; + 1064960 bytes downloaded
[22:23:23] Initial: 9A20; + 1075200 bytes downloaded
[22:23:23] Initial: 1D08; + 1085440 bytes downloaded
[22:23:23] Initial: B1BD; + 1095680 bytes downloaded
[22:23:23] Initial: 4946; + 1105920 bytes downloaded
[22:23:23] Initial: 5297; + 1116160 bytes downloaded
[22:23:23] Initial: 201F; + 1126400 bytes downloaded
[22:23:23] Initial: A318; + 1136640 bytes downloaded
[22:23:23] Initial: 3ED5; + 1146880 bytes downloaded
[22:23:23] Initial: 8473; + 1157120 bytes downloaded
[22:23:23] Initial: D9B9; + 1167360 bytes downloaded
[22:23:23] Initial: 2D15; + 1177600 bytes downloaded
[22:23:23] Initial: F6A1; + 1187840 bytes downloaded
[22:23:23] Initial: 1850; + 1198080 bytes downloaded
[22:23:23] Initial: 3D3E; + 1208320 bytes downloaded
[22:23:23] Initial: 2ADB; + 1218560 bytes downloaded
[22:23:23] Initial: FF21; + 1228800 bytes downloaded
[22:23:23] Initial: 1708; + 1239040 bytes downloaded
[22:23:23] Initial: ADA8; + 1249280 bytes downloaded
[22:23:23] Initial: 8E4E; + 1259520 bytes downloaded
[22:23:23] Initial: 63C7; + 1269760 bytes downloaded
[22:23:23] Initial: 7316; + 1280000 bytes downloaded
[22:23:23] Initial: B3D8; + 1290240 bytes downloaded
[22:23:23] Initial: 2693; + 1300480 bytes downloaded
[22:23:23] Initial: 1B77; + 1310720 bytes downloaded
[22:23:23] Initial: F16F; + 1320960 bytes downloaded
[22:23:23] Initial: 45F0; + 1331200 bytes downloaded
[22:23:23] Initial: 289C; + 1341440 bytes downloaded
[22:23:23] Initial: 83F2; + 1351680 bytes downloaded
[22:23:23] Initial: 1459; + 1361920 bytes downloaded
[22:23:23] Initial: 1A62; + 1372160 bytes downloaded
[22:23:23] Initial: C408; + 1382400 bytes downloaded
[22:23:23] Initial: C561; + 1392640 bytes downloaded
[22:23:24] Initial: 8827; + 1402880 bytes downloaded
[22:23:24] Initial: 3F18; + 1413120 bytes downloaded
[22:23:24] Initial: 212C; + 1422551 bytes downloaded
[22:23:24] Verifying core Core_15.fah...
[22:23:24] Signature is VALID
[22:23:24]
[22:23:24] Trying to unzip core FahCore_15.exe
[22:23:24] Decompressed FahCore_15.exe (3903488 bytes) successfully
[22:23:29] + Core successfully engaged
[22:23:34]
[22:23:34] + Processing work unit
[22:23:34] Core required: FahCore_15.exe
[22:23:34] Core found.
[22:23:34] Working on queue slot 01 [March 4 22:23:34 UTC]
[22:23:34] + Working ...
[22:23:34] - Calling '.\FahCore_15.exe -dir work/ -suffix 01 -nice 19 -checkpoint 15 -verbose -lifeline 8 -version 630'

[22:23:38] CoreStatus = C0000135 (-1073741515)
[22:23:38] Client-core communications error: ERROR 0xc0000135
[22:23:38] This is a sign of more serious problems, shutting down.


--- Opening Log file [March 4 22:29:33 UTC]


# Windows GPU Console Edition #################################################
###############################################################################

                       Folding@Home Client Version 6.30r1

                          http://folding.stanford.edu

###############################################################################
###############################################################################

Launch directory: Z:\opt\fah-gpu\alpha
Executable: Z:\opt\fah-gpu\Folding@home-Win32-GPU.exe
Arguments: -forcegpu nvidia_fermi -gpu 1 -verbosity 9

[22:29:33] - Ask before connecting: No
[22:29:33] - User name: zero-x[49036] (Team 86565)
[22:29:33] - User ID: 39C7C7E6317C1AB7
[22:29:33] - Machine ID: 2
[22:29:33]
[22:29:33] Gpu species not recognized.
[22:29:33] Loaded queue successfully.
[22:29:33]
[22:29:33] + Processing work unit
[22:29:33] Core required: FahCore_15.exe
[22:29:33] Core found.
[22:29:33] - Autosending finished units... [March 4 22:29:33 UTC]
[22:29:33] Trying to send all finished work units
[22:29:33] + No unsent completed units remaining.
[22:29:33] - Autosend completed
[22:29:33] Working on queue slot 01 [March 4 22:29:33 UTC]
[22:29:33] + Working ...
[22:29:33] - Calling '.\FahCore_15.exe -dir work/ -suffix 01 -nice 19 -checkpoint 15 -verbose -lifeline 8 -version 630'

[22:29:33]
[22:29:33] *------------------------------*
[22:29:33] Folding@Home GPU Core
[22:29:33] Version 2.15 (Tue Nov 16 09:05:18 PST 2010)
[22:29:33]
[22:29:33] Build host: SimbiosNvdWin7
[22:29:33] Board Type: NVIDIA/CUDA
[22:29:33] Core      : x=15
[22:29:33]  Window's signal control handler registered.
[22:29:33] Preparing to commence simulation
[22:29:33] - Looking at optimizations...
[22:29:33] DeleteFrameFiles: successfully deleted file=work/wudata_01.ckp
[22:29:33] - Created dyn
[22:29:33] - Files status OK
[22:29:33] sizeof(CORE_PACKET_HDR) = 512 file=<>
[22:29:33] - Expanded 43295 -> 169787 (decompressed 392.1 percent)
[22:29:33] Called DecompressByteArray: compressed_data_size=43295 data_size=169787, decompressed_data_size=169787 diff=0
[22:29:33] - Digital signature verified
[22:29:33]
[22:29:33] Project: 6800 (Run 11525, Clone 0, Gen 18)
[22:29:33]
[22:29:33] Assembly optimizations on if available.
[22:29:33] Entering M.D.
[22:29:35] Tpr hash work/wudata_01.tpr:  4045849536 128922705 927941779 3571254074 3623119669
[22:29:35] Working on PEPTIDE (1-42)
[22:29:35] Client config found, loading data.
[22:29:40] CoreStatus = 63 (99)
[22:29:40] + Error starting Folding@home core.
[22:29:45]
[22:29:45] + Processing work unit
[22:29:45] Core required: FahCore_15.exe
[22:29:45] Core found.
[22:29:45] Working on queue slot 01 [March 4 22:29:45 UTC]
[22:29:45] + Working ...
[22:29:45] - Calling '.\FahCore_15.exe -dir work/ -suffix 01 -nice 19 -checkpoint 15 -verbose -lifeline 8 -version 630'

[22:29:45]
[22:29:45] *------------------------------*
[22:29:45] Folding@Home GPU Core
[22:29:45] Version 2.15 (Tue Nov 16 09:05:18 PST 2010)
[22:29:45]
[22:29:45] Build host: SimbiosNvdWin7
[22:29:45] Board Type: NVIDIA/CUDA
[22:29:45] Core      : x=15
[22:29:45]  Window's signal control handler registered.
[22:29:45] Preparing to commence simulation
[22:29:45] - Ensuring status. Please wait.
[22:29:54] - Looking at optimizations...
[22:29:54] - Working with standard loops on this execution.
[22:29:54] - Previous termination of core was improper.
[22:29:54] - Files status OK
[22:29:54] sizeof(CORE_PACKET_HDR) = 512 file=<>
[22:29:54] - Expanded 43295 -> 169787 (decompressed 392.1 percent)
[22:29:54] Called DecompressByteArray: compressed_data_size=43295 data_size=169787, decompressed_data_size=169787 diff=0
[22:29:54] - Digital signature verified
[22:29:54]
[22:29:54] Project: 6800 (Run 11525, Clone 0, Gen 18)
[22:29:54]
[22:29:54] Entering M.D.
[22:29:56] Tpr hash work/wudata_01.tpr:  4045849536 128922705 927941779 3571254074 3623119669
[22:29:56] Working on PEPTIDE (1-42)
[22:29:56] Client config found, loading data.
[22:29:59] CoreStatus = 63 (99)
[22:29:59] + Error starting Folding@home core.
[22:30:04]

I have since tried reinstalling 5 times, I have checked the linking of the dlls numerous times, I have tried running on both my primary and my secondary GPU (both gtx 460's, stock clocks), I have also tried changing machine ID's and running with no user/passkey.
What am I missing?
Xaero
 
Posts: 11
Joined: Wed Feb 04, 2009 8:15 am

Re: Linux GPU3 (fermi) Corestatus = 63 (99)

Postby HendricksSA » Mon Mar 07, 2011 2:33 am

I'm not running a Linux GPU client right now, but when I have a question I always refer to PantherX's outstanding troubleshooting guide. This may help - see it at viewtopic.php?p=158848#p158848

Good luck - let us know how you are progressing.
HendricksSA
 
Posts: 555
Joined: Fri Jun 26, 2009 4:34 am

Re: Linux GPU3 (fermi) Corestatus = 63 (99)

Postby Xaero » Mon Mar 07, 2011 10:42 am

After a few more hours of fiddling with it I finally got it to work, less than 50s TPF, however now the problem is my X display freezes every few seconds, which would lead me to think core clock instability on my CPU but if that were the case the kernel would panic. I'll mess around with reniceing and such.
In the end I had to download the GPU3 wrapper and link nvcuda.dll from cudart_gpu3.dll.so in the wine system32 directory and then it started working immediately.
Also, I do NOT reccomend actually folding for more than 3 seconds with WINEDEBUG=+cuda, I filled up all the remaining space on my SSD in less than 1 minute.
Xaero
 
Posts: 11
Joined: Wed Feb 04, 2009 8:15 am

Re: Linux GPU3 (fermi) Corestatus = 63 (99)

Postby Sidicas » Mon Mar 07, 2011 5:30 pm

What priority / nice level is X running at?
How much CPU usage is your GPU client using? It should be <10% of a core per GPU client.
Sidicas
 
Posts: 233
Joined: Sun Feb 17, 2008 4:46 pm

Re: Linux GPU3 (fermi) Corestatus = 63 (99)

Postby PantherX » Mon Mar 07, 2011 8:34 pm

Xaero wrote:...Also, I do NOT reccomend actually folding for more than 3 seconds with WINEDEBUG=+cuda, I filled up all the remaining space on my SSD in less than 1 minute.
Can you please elborate? (Not a Linux user) Since the F@H GPU Client uses very little disk space, my guess <10MBs.
ETA:
Now ↞ Very Soon ↔ Soon ↔ Soon-ish ↔ Not Soon ↠ End Of Time

Welcome To The F@H Support Forum Ӂ Chrome Folding App (Beta) Ӂ Troubleshooting "Bad WUs" Ӂ Troubleshooting Server Connectivity Issues
User avatar
PantherX
 
Posts: 6614
Joined: Wed Dec 23, 2009 9:33 am

Re: Linux GPU3 (fermi) Corestatus = 63 (99)

Postby Sidicas » Tue Mar 08, 2011 4:54 am

The folding @ home core makes calls to CUDA thousands of times each second..
With the CUDA debug enabled, Wine will log every time a call is made out to CUDA referencing the exact function name, when it was called, what program called it, etc. etc.

So yes, you're writing thousands of lines of debug log per second and it adds up very very fast.. Further we've never had a need for the CUDA debug mode that I've ever seen so it's all pretty worthless information anyway..
Sidicas
 
Posts: 233
Joined: Sun Feb 17, 2008 4:46 pm

Re: Linux GPU3 (fermi) Corestatus = 63 (99)

Postby Xaero » Tue Mar 08, 2011 7:51 am

X is running at a nice of -1, I have temporarily scaled the GPU clients back to a nice of 15 which has dropped my PPD by 3000 (9xxx->6xxx), a pretty significant performance impact. The SMP client is running a nice of 19 (may soon drop it to a nice of 5 since its eating a little less cpu than I would like.)
FahCore_a3 is using roughly 650% (low, for an 8 threaded processor and smp 8, to be expected its well known that F@H better utilizes resources with two smp 4 clients on an 8 threaded processor, I'm not to worried about pure performance as this is my main computer, I like having a bit of leftover clock cycles for my own computing.)
FahCore_15 are each using between 8 and 15% of a core, favoring 8%, this seems appropriate, I will try fiddling with the wait loop delay value provided by the GPU 3 wrapper linked in the Core15 thread. I'm also going to try dropping the nice value a few more ticks and see what it does to the performance.

Also, here is a scrot of gnome-system-monitor, it seems a little to. sporadic to me:
http://imm.io/media/4c/4cqQ.png
Xaero
 
Posts: 11
Joined: Wed Feb 04, 2009 8:15 am

Re: Linux GPU3 (fermi) Corestatus = 63 (99)

Postby Sidicas » Tue Mar 08, 2011 5:26 pm

I'm thinking it might be more your SMP client that's causing the sluggishness than the GPU clients, but I could be wrong there...

The best results I've gotten were having X as the highest priority (lowest nice).
Below that in priority (higher nice) I had the GPU client...
Then I ran the SMP client at maximum niceness..

Also keep in mind that you really should dedicate one core of your CPU to service both your GPU clients, so if you have a quad-core you want to be running with the -smp 3 flag so your GPU clients aren't starved for CPU time..

If the GPU clients don't get their CPU timeslices, then yes your PPD will quickly drop as your GPUs will go idle..

Also, you mentioned you have an 8-threaded proccessor.. You do realize that Hyperthreading doesn't really help much at all for folding@home, right? Hyperthreading only boosts integer performance and Folding@Home is all floating point. The only time hyperthreading would help is if X or regular integer based apps moved over to the hyperthreads so that folding@home could get more time in the ALUs that do floats (real CPU cores)

If you've got a 4-core CPU with hyperthreading (appears as an 8-core CPU), you should be using -smp 4... Possibly even -smp3 with GPU clients..
If you use -smp 8, you're going to spawn a whole lot of CPU bottlenecked processes that the kernel scheduler is going to try to give equal time slices and that will mean that X gets less time slices because it's got to compete with those other processes for CPU time.. Unless you have a real 8-core CPU, only 4 of those -smp 8 threads can actually execute at the same time because they're floating point ALU bound.. Everything else will end up in a FIFO queue of sorts where X will have to wait it's turn, but when it gets it's turn it will get a slightly bigger slice of CPU time..
Last edited by Sidicas on Tue Mar 08, 2011 5:42 pm, edited 1 time in total.
Sidicas
 
Posts: 233
Joined: Sun Feb 17, 2008 4:46 pm

Re: Linux GPU3 (fermi) Corestatus = 63 (99)

Postby bruce » Tue Mar 08, 2011 5:41 pm

Your priority recommendations fit with what I believe to be true, but why bother. If there are free CPU resources, priority will be almost meaningless.

As you say, FAH is mostly floating point and -smp 4 might be a good setting. The only exception to that is that the GPU client is mostly integer work so it can benefit from HT. Using -smp 4 will do a pretty good job of keeping the FPU busy. Integer resources will be free to run X and the GPU client.

I've never done this but start with -smp 4 and get a good measurement of frame times of both SMP and GPU. Retest with -smp 6 and again with -smp 8. I expect that -smp 6 will be slightly different than -smp 4. When you move to smp 8, then priority will matter.
bruce
Site Admin
 
Posts: 20615
Joined: Thu Nov 29, 2007 10:13 pm
Location: So. Cal.

Re: Linux GPU3 (fermi) Corestatus = 63 (99)

Postby Sidicas » Tue Mar 08, 2011 5:53 pm

bruce wrote:Your priority recommendations fit with what I believe to be true, but why bother. If there are free CPU resources, priority will be almost meaningless.


He's starting at -smp 8 so I don't think there is any free CPU resources available at any time.. Though he didn't say whether he had a 4-core with 4 hyperthreads or a true 8-core..

In Windows by default the presentation graphics to the user runs at real-time / highest priority.. And everything that the user starts runs at much lower priorities than that..

In Linux, that's not always true depending on how the user has their system configured.. Especially if he's running at root or starting X manually as a user application..

If he's got his X running at -1 nice and spawning apps at 0 nice, that's equivalent to starting desktop applications at "real time" priority on Windows and it produces the same sluggishness / screen redraw problems / freezing (as noted above) on Windows as it does on Linux. It doesn't necessarily matter that your nice isn't very low, what matters is the processes are the same priority of your display manager and end up fighting equally with your display manager over CPU time when they really shouldn't be if you want a responsive desktop.
Sidicas
 
Posts: 233
Joined: Sun Feb 17, 2008 4:46 pm

Re: Linux GPU3 (fermi) Corestatus = 63 (99)

Postby Xaero » Wed Mar 09, 2011 6:48 am

Ah, its an 8-threaded 4 core (i7) processor, I've never run into the jerky response under windows with this same hardware configuration - and I think I know why. Its not my processor bottling up or my graphics cards. Its my solid state disks, The correlation between my GPU client working and not working is relavent, I'm running EXT3, which doesn't support mounted, active TRIM, and linux (with logging and whatnot) doesn't allow much time for idle garbage collection. When I got GPU3 working I also simultaneoulsy filled my SSD with garbage by having cuda logging enabled for debugging purposes. I have NOT confirmed this but it is an educated suspicion - The `soft-locks` so to speak occur typically when something would require HDD access to occur - loading a webpage in chromium, opening any of the Gnome-Panel menus, opening an application.
I'm upgrading the system to utilize EXT4 in place of EXT2/3 on both of my solid state disks, since it allows for both manual and automatic (kernel) trim. Hopefully this resolves the issue.
/facepalm

EDIT:
Well, the upgrade from ext2/3 to ext4 went very well, kernel based trim support didn't start working immediately so I forced a manual trim, 99% of the free spaced required trimming. This did not entirely solve the problem, although it has improved the issue significantly, I still get periodic stutters, and its mostly when opening menus/clicking on gui elements. I'll keep playing with stuff... I do use compiz/emerald, so I'll try renicing that stuff as well.
Xaero
 
Posts: 11
Joined: Wed Feb 04, 2009 8:15 am

Re: Linux GPU3 (fermi) Corestatus = 63 (99)

Postby HendricksSA » Wed Mar 09, 2011 7:50 am

I know I had problems with read-write speed with EXT4. There are lots of threads of complaints about it but you sound like you have a good grip on how to fix it so it runs fast (how hard is that on an SSD?). Anyway, the linux gurus that hang out here can help with any issues.
HendricksSA
 
Posts: 555
Joined: Fri Jun 26, 2009 4:34 am

Re: Linux GPU3 (fermi) Corestatus = 63 (99)

Postby Xaero » Wed Mar 09, 2011 8:01 am

Okay, so I'm running without compiz/emerald, disabling it immediately returned me to 100% fluid use of my DE.
Also on the ext4 note, its better to run a journaling filesystem with trim support than to run a filesystem with NO trim support:
On my secondary solid state disk:
Pre-ext4 w/no trim:
170-270mb/s, .1ms seek
Post-ext4 after trim:
216-270mb/s .1ms seek
On my primary (garbage full after my folding escapades)
pre-ext4:
11kb/s-180mb/s .1ms seek
post-ext4:
211-275mb/s .1ms seek

Pretty immense what a lot of garbage buildup can do eh? Newer SSD's shouldn't suffer this bad, since they do a better job at GC during writes/reads and also do them when their access count is low, instead of waiting for the 'spin down' signal from power management.
I'll try and figure out why emerald/compiz is causing such a hitch, its not that intensive and therefore shouldn't cause such issues.

Edit: Okay, I've decided I can just live without eye candy, gtk has enough eyecandy for me, honestly, and a gain of 4k ppd for EACH GPU cleint is well worth living without compiz. 10k PPD/GPU and 12k (no bigadv) on the processor, it should start picking up bigadv soon though, I'll give those wu's a few runs and see if 4ghz with this moderately slow ram (9-9-9-27-2T) is enough to complete them reliably and comfortably within the bigadv windows...
Edit2: BIGADV 6901 running roughly 30m TPF - very nice :D
Last edited by Xaero on Wed Mar 09, 2011 10:26 am, edited 2 times in total.
Xaero
 
Posts: 11
Joined: Wed Feb 04, 2009 8:15 am

Re: Linux GPU3 (fermi) Corestatus = 63 (99)

Postby HendricksSA » Wed Mar 09, 2011 8:07 am

The speed was tremendous! Yes, it is incredible what happens to a disk with stuff scattered everywhere. I'm still amazed at the seek times and the change in transfer rates. Good job!
HendricksSA
 
Posts: 555
Joined: Fri Jun 26, 2009 4:34 am

Re: Linux GPU3 (fermi) Corestatus = 63 (99)

Postby Sidicas » Wed Mar 09, 2011 5:12 pm

Xaero wrote:Also on the ext4 note, its better to run a journaling filesystem with trim support than to run a filesystem with NO trim support:
It's always better with TRIM enabled.. I would disable the journaling if it's on an SSD, you can run EXT2/4 without journaling, it's just not the default option.

To disable the journal on an EXT4 already, unmount it and use:
tune2fs -O ^has_journal /dev/sdaXX

To make an EXT4 without a journal use:
mkfs.ext4 -O ^has_journal /dev/sdaXX

If you want an EXT3 without a journal, use EXT2.
Sidicas
 
Posts: 233
Joined: Sun Feb 17, 2008 4:46 pm

Next

Return to unOfficial Linux GPU (WINE wrapper) (3rd party support)

Who is online

Users browsing this forum: No registered users and 1 guest

cron