Message boards :
Number crunching :
"Laggy" GUI and Processor Scheduling: Win32PrioritySeparation
Message board moderation
Author | Message |
---|---|
cov_route Send message Joined: 13 Sep 12 Posts: 342 Credit: 10,270,618 RAC: 0 |
Win7/64, Phenom II 945, Radeon HD 6670 1GB, running MB GPU 2-up From time to time my machine gets "sticky", the GUI becomes poorly responsive. It isn't a function of %cpu utilization, it can often run at 100% utilization and be responsive. During periods of stickiness, the Resource Monitor shows the "modified" memory as somewhat larger than other times, and varying. Definitely a different behaviour than normal. It makes me suspect some sort of soft-fault cache-trashing issue. There is plenty of memory in the system. It's not hard faulting. What I tried is changing the processor scheduling from "Programs" to "Background Services". The theory being that if the background (seti) jobs get hold of the caches for longer there will be less trashing, less coherency traffic and better overall memory functionality. At the registry level that changes Win32PrioritySeparation to decimal 28 or 011101. Technet. It seems to have worked for now, but this is the sort of thing that's notoriously hard to nail down. Sometimes seemingly random changes can fix it for a while only to re-emerge later. I realize it seems backwards, giving higher priority to background jobs to make the GUI run smoother but I can't argue with the results. For now. Edit: fixed the link. |
Gundolf Jahn Send message Joined: 19 Sep 00 Posts: 3184 Credit: 446,358 RAC: 0 |
At the registry level that changes Win32PrioritySeparation to decimal 28 or 011101. Technet. 28 is an even number and 011101 is not (last didit non-zero). If my memories of my octal era (Pr1mos) don't fail me, 011 101 (yes, I take groups of 3 :-) is 29 (24 + 5). Gruß, Gundolf |
Ulrich Metzner Send message Joined: 3 Jul 02 Posts: 1256 Credit: 13,565,513 RAC: 13 |
I think, this is application dependent. See here: http://setiathome.berkeley.edu/forum_thread.php?id=72379 I'm also not happy with ATI and *some* MB tasks... Aloha, Uli |
Mike Send message Joined: 17 Feb 01 Posts: 34258 Credit: 79,922,639 RAC: 80 |
@Uli In your case its simply a weak GPU. cove_route increase period_iterations_num to 50. This should help. With each crime and every kindness we birth our future. |
Ulrich Metzner Send message Joined: 3 Jul 02 Posts: 1256 Credit: 13,565,513 RAC: 13 |
@Uli I don't think it's *only* related to the weak GPU. He also describes some points, where the computer is very, very laggy, in other times, it's just fine. It was the same in my case. But ok, let's see, if increasing the iterations will help in his case. :? Good luck! *thumbsup* Aloha, Uli |
cov_route Send message Joined: 13 Sep 12 Posts: 342 Credit: 10,270,618 RAC: 0 |
I am not sure about period_iteration_num because this problem can come and go even with the same work unit. It definitely appears to be a condition that arises in the processor related to memory access. |
Mike Send message Joined: 17 Feb 01 Posts: 34258 Credit: 79,922,639 RAC: 80 |
I am not sure about period_iteration_num because this problem can come and go even with the same work unit. I had to increase it on my HD 5850 running V7 so it doesn`t hurt if you try. With each crime and every kindness we birth our future. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
I am not sure about period_iteration_num because this problem can come and go even with the same work unit. I'm still getting 'stuttering' ever so often with my 6850. I've raised the period_iteration_num to 64. Everything is fine for a while, then the stutter.. It does seem to have increased after I went from using 2 CPU cores to using 3 cores for v7 CPU MBs. |
cov_route Send message Joined: 13 Sep 12 Posts: 342 Credit: 10,270,618 RAC: 0 |
@Gundolf Yes you are correct. As it says in the Technet entry the registry value for the background case is dec 24 or 011000. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
In general this change can't be ultimate solution (my host configured for background services and still has GUI lags time to time) (also, it can be done via usual Windows settings GUI, no need to edit registry keys directly), but can add some to understanding the roots of issue. Could you post screenshot with counter that strange behavior you observed at GUI lags moments, please ? SETI apps news We're not gonna fight them. We're gonna transcend them. |
cov_route Send message Joined: 13 Sep 12 Posts: 342 Credit: 10,270,618 RAC: 0 |
I'll do that next time I see it, Raistmer. It doesn't happen that often and since I made the change to background priority I haven't seen it at all. On another matter, I started using -cpu_lock with -instances_per_device and -gpu_lock to run with single assigned cores. It works, so I have been able to stop using my custom script. To remind you, that enables me to run with no cores idled. Some time ago you mentioned that -gpu_lock shouldn't be needed, but I find it doesn't work without it. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
Thanks, will check logic of interaction between switches once more. SETI apps news We're not gonna fight them. We're gonna transcend them. |
cov_route Send message Joined: 13 Sep 12 Posts: 342 Credit: 10,270,618 RAC: 0 |
Raistmer: The first graph is the system running "sticky". The second graph is after a logoff/logon when it is running "smoothly". You can see the faults are almost all transition (soft) faults. I don't know if transition faults include cache misses or just page repositioning. I suspect they dont. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
thanks. I suspect that driver swaps data between system and device memories for some reason in first graph... EDIT: while you in these observations, could you please record what tasks experienced laggy behavior and look into their stderrs after completion. Info to check - if they also show excessive "misses" (any kind) in counters fields vs non-laggy tasks ? EDIT2: examples of such fields in bold: class Gaussian_transfer_not_needed: total=96555, N=96555, <>=1, min=1 max=1 class Gaussian_transfer_needed: total=19, N=19, <>=1, min=1 max=1 class Gaussian_skip1_no_peak: total=0, N=0, <>=0, min=0 max=0 class Gaussian_skip2_bad_group_peak: total=0, N=0, <>=0, min=0 max=0 class Gaussian_skip3_too_weak_peak: total=0, N=0, <>=0, min=0 max=0 class Gaussian_skip4_too_big_ChiSq: total=0, N=50, <>=0, min=0 max=0 class Gaussian_skip6_low_power: total=25, N=50, <>=0.5, min=0 max=1 class Gaussian_new_best: total=32, N=32, <>=1, min=1 max=1 class Gaussian_report: total=0, N=0, <>=0, min=0 max=0 class Gaussian_miss: total=18, N=18, <>=1, min=1 max=1 class PC_triplet_find_hit: total=23938, N=23938, <>=1, min=1 max=1 class PC_triplet_find_miss: total=187, N=187, <>=1, min=1 max=1 class PC_pulse_find_hit: total=12050, N=12050, <>=1, min=1 max=1 class PC_pulse_find_miss: total=11, N=11, <>=1, min=1 max=1 class PC_pulse_find_early_miss: total=1, N=1, <>=1, min=1 max=1 class PC_pulse_find_2CPU: total=1, N=1, <>=1, min=1 max=1 class PoT_transfer_not_needed: total=23927, N=23927, <>=1, min=1 max=1 class PoT_transfer_needed: total=199, N=199, <>=1, min=1 max=1 SETI apps news We're not gonna fight them. We're gonna transcend them. |
cov_route Send message Joined: 13 Sep 12 Posts: 342 Credit: 10,270,618 RAC: 0 |
The slowdown happened again, here is the performance monitor: Heavy lines are overall page faults, fine lines are for the two MB jobs running. Conclusion, all the faults are coming from the two jobs, and they are all transition faults. You can see where the default behaviour spontaneously stops by itself at the 7:21PM mark. The two results: http://setiathome.berkeley.edu/result.php?resultid=3110887969 http://setiathome.berkeley.edu/result.php?resultid=3110887697 *** class Gaussian_transfer_not_needed: total=32966, N=32966, <>=1, min=1 max=1 class Gaussian_transfer_needed: total=2, N=2, <>=1, min=1 max=1 class Gaussian_skip1_no_peak: total=0, N=0, <>=0, min=0 max=0 class Gaussian_skip2_bad_group_peak: total=0, N=0, <>=0, min=0 max=0 class Gaussian_skip3_too_weak_peak: total=0, N=0, <>=0, min=0 max=0 class Gaussian_skip4_too_big_ChiSq: total=0, N=2, <>=0, min=0 max=0 class Gaussian_skip6_low_power: total=0, N=2, <>=0, min=0 max=0 class Gaussian_new_best: total=2, N=2, <>=1, min=1 max=1 class Gaussian_report: total=0, N=0, <>=0, min=0 max=0 class Gaussian_miss: total=0, N=0, <>=0, min=0 max=0 class PC_triplet_find_hit: total=8150, N=8150, <>=1, min=1 max=1 class PC_triplet_find_miss: total=84, N=84, <>=1, min=1 max=1 class PC_pulse_find_hit: total=4114, N=4114, <>=1, min=1 max=1 class PC_pulse_find_miss: total=2, N=2, <>=1, min=1 max=1 class PC_pulse_find_early_miss: total=0, N=0, <>=0, min=0 max=0 class PC_pulse_find_2CPU: total=0, N=0, <>=0, min=0 max=0 class PoT_transfer_not_needed: total=8149, N=8149, <>=1, min=1 max=1 class PoT_transfer_needed: total=85, N=85, <>=1, min=1 max=1 ***** class Gaussian_transfer_not_needed: total=84782, N=84782, <>=1, min=1 max=1 class Gaussian_transfer_needed: total=1, N=1, <>=1, min=1 max=1 class Gaussian_skip1_no_peak: total=0, N=0, <>=0, min=0 max=0 class Gaussian_skip2_bad_group_peak: total=0, N=0, <>=0, min=0 max=0 class Gaussian_skip3_too_weak_peak: total=0, N=0, <>=0, min=0 max=0 class Gaussian_skip4_too_big_ChiSq: total=0, N=2, <>=0, min=0 max=0 class Gaussian_skip6_low_power: total=0, N=2, <>=0, min=0 max=0 class Gaussian_new_best: total=1, N=1, <>=1, min=1 max=1 class Gaussian_report: total=0, N=0, <>=0, min=0 max=0 class Gaussian_miss: total=1, N=1, <>=1, min=1 max=1 class PC_triplet_find_hit: total=21043, N=21043, <>=1, min=1 max=1 class PC_triplet_find_miss: total=139, N=139, <>=1, min=1 max=1 class PC_pulse_find_hit: total=10587, N=10587, <>=1, min=1 max=1 class PC_pulse_find_miss: total=5, N=5, <>=1, min=1 max=1 class PC_pulse_find_early_miss: total=3, N=3, <>=1, min=1 max=1 class PC_pulse_find_2CPU: total=0, N=0, <>=0, min=0 max=0 class PoT_transfer_not_needed: total=21039, N=21039, <>=1, min=1 max=1 class PoT_transfer_needed: total=143, N=143, <>=1, min=1 max=1 |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
I would not say there is big overall rise in those counters. The only possibility to link those events is to assume that all those PoT transfers are happened very locally in WU processing. Unfortunately, it can't be proved with counters. Can you monitor data transfers over PCIe bus somehow? Some NV cards (in GPU-Z) have "memory controller load" counter. But I didn't see something like that for ATi GPUs. It would be interesting to correlate thosee increase in page faults counter with PCIe transfers increases if any. Any ideas how to monitor PCIe transfers? Any tools ? SETI apps news We're not gonna fight them. We're gonna transcend them. |
cov_route Send message Joined: 13 Sep 12 Posts: 342 Credit: 10,270,618 RAC: 0 |
Any ideas how to monitor PCIe transfers? Any tools ? No ideas. I downloaded the NV sys tools (NV chipset) but no PCI-E info except frequency. I need more instrumentation!!! |
TimK Send message Joined: 19 Sep 08 Posts: 10 Credit: 6,079,103 RAC: 0 |
For the past couple of weeks my machine has also been "laggy". I checked a few things in performance monitor and found about 20,000 average page faults per second, hardly any hard faults. I thought this was high, until I saw the graph below showing nearly 500,000 per second. What is the consensus on any possible fix? As I said, it's only started in the past few weeks and nothing has changed in my pc (as far as I know). |
cov_route Send message Joined: 13 Sep 12 Posts: 342 Credit: 10,270,618 RAC: 0 |
I don't know that there is a surefire fix. It is something that has been observed intermittently for a long time by many people. One thing that is suggested is to increase the argument -period_iterations_num from the default value of 20. I've tried very high numbers like 100 without seeing a difference but it might work for some. The other thing to do, if you are running more than one instance per gpu, is to decrease that to 1. I'm pretty sure that does help if it applies. If all else fails and it's really interfering with computer use, you can always set BOINC to not allow computing when the computer is active. |
Mike Send message Joined: 17 Feb 01 Posts: 34258 Credit: 79,922,639 RAC: 80 |
Add the following to your appinfo.xml or mb_cmdline*.txt -peroiod_iterations_num 40 -sbs 256 This should fix it for you. I experienced the 7700 sometimes need lower values on single buffer size. So you can try -sbs 192 or -sbs 156. With each crime and every kindness we birth our future. |
©2024 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.