Posts by pls

21) Message boards : Number crunching : Priorities? (Message 32504) Posted 23 Sep 2017 by pls Post: That works, thank you. Rather than have to manually keep VirtualBox running and change the priority I created a Powershell script to set the priority on VBoxSVC.exe to Low, then created a task scheduler entry to run the script one an hour. It looks like this is working fine. I'll need to do some experimenting to see how many tasks I can now run before the machine gets bogged down. Again, thanks.
22) Message boards : Number crunching : Priorities? (Message 32480) Posted 21 Sep 2017 by pls Post: After a long delay and a new machine, I'm back running the LHC VitrualBox applications. And they're not working the way I remember them working. The machine has a 4 core Xeon with hyperthreading and 24 GB memory. Traditionally, the whole point of BOINC was that the BOINC tasks run one step above idle priority, so that anything else running on the machine take precedence and the machine can be used for other things while BOINC tasks run in the background. That isn't the way the VirtualBox tasks are working. They are all running at Normal priority. And when 4 or more a running, the machine in mostly unusable even for simple interactive tasks like web browsing. Is there a way to get these tasks to run at Low priority?? If not, is this an LHC problem or a BOINC problem? Thanks
23) Message boards : Number crunching : Windows work units spinning CPU in csrss.exe and conhost.exe (Message 27604) Posted 10 Oct 2015 by pls Post: I'm running LHC@Home on windows 7 on a 4 core cpu. I notice that a lot of recent work units spend a lot of cpu time running csrss.exe and conhost.exe. I suspect that the current Windows sixtrack contains active debugging code that is writing a lot of text to a hidden console window and that this accounts for the extra CPU time. This is worth fixing. Thanks, ++PLS
24) Message boards : Number crunching : Strange performance difference between Windows And Linux. (Message 27603) Posted 10 Oct 2015 by pls Post: You didn't identify a work unit so I can only guess. Lately I've noticed that Windows takes much longer to process work units. Looking it to it I discovered that these work units are spending much CPU time dealing with an invisible console window. I suspect that the windows sixtrack contains active debugging code that is writing a lot of information to this console window. In any case, running 4 tasks on a 4 core system I'm seeing only about 25 % of the CPU time going to computation. The rest is spend mucking around with console windows.
25) Message boards : News : Heavy I/O on Windows WUs (Message 27035) Posted 11 Dec 2014 by pls Post: Maybe I can provide a bit more information. I am running on Windows XP Sp3, running SixTrack 451.07 on a "w-" work unit. As I write this, BOINC shows that the WU has been running for 14:32 and is 93.491% complete. Attaching a monitor to the process shows that it has used the following CPU User time: 00:14:00 Kernel time: 11:22:18 I/O Reads: 1,990 and not increasing Writes: 1,805,531 Write Delta: 82 per 5 secs Write Bytes Delta: 7000 Calculated Write Size: 85 bytes Other: 5,228,924 Other Delta: 241 per 5 secs Other Delta Bytes: 320 It appears that an ioctl is doing a lot of 1 byte writes 1 active thread accounts for almost all of the CPU time. Pulling a stack traces for this thread gives (3 examples) ntkrnlpa.exe!KiUnexpectedInterrupt+0x121 ntdll.dll!KiFastSystemCallRet sixtrack_win32_4517_pni.exe+0x24b141 sixtrack_win32_4517_pni.exe+0x190069 sixtrack_win32_4517_pni.exe+0x1796b4 sixtrack_win32_4517_pni.exe+0x1790e4 sixtrack_win32_4517_pni.exe+0x62c6d sixtrack_win32_4517_pni.exe+0x2cc842 sixtrack_win32_4517_pni.exe+0x295970 kernel32.dll!RegisterWaitForInputIdle+0x49 ntkrnlpa.exe!ZwYieldExecution+0x1d3a sixtrack_win32_4517_pni.exe+0xa12254 ntkrnlpa.exe!IoBuildPartialMdl+0xed fltMgr.sys!FltPerformSynchronousIo+0xb9 fltMgr.sys!FltFlushBuffers+0x314 fltMgr.sys!FltFsControlFile+0x26 fltMgr.sys!FltRequestOperationStatusCallback+0x5bd fltMgr.sys!FltGetIrpName+0x57a fltMgr.sys!FltGetIrpName+0xaa9 fltMgr.sys!FltGetIrpName+0x113b fltMgr.sys!FltGetIrpName+0x12ad ntkrnlpa.exe!IoBuildPartialMdl+0xed ntkrnlpa.exe!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb80 ntdll.dll!KiFastSystemCallRet sixtrack_win32_4517_pni.exe+0x25cb8b Seen this address a lot sixtrack_win32_4517_pni.exe+0x23bece sixtrack_win32_4517_pni.exe+0x19003e sixtrack_win32_4517_pni.exe+0x1796b4 sixtrack_win32_4517_pni.exe+0x1790e4 sixtrack_win32_4517_pni.exe+0x62c6d sixtrack_win32_4517_pni.exe+0x2cc842 sixtrack_win32_4517_pni.exe+0x295970 kernel32.dll!RegisterWaitForInputIdle+0x49 ntkrnlpa.exe!KiUnexpectedInterrupt+0x121 ntkrnlpa.exe!ZwYieldExecution+0x1d3a ntkrnlpa.exe!KiDeliverApc+0x12c ntdll.dll!KiFastSystemCallRet sixtrack_win32_4517_pni.exe+0x24b141 sixtrack_win32_4517_pni.exe+0x190069 sixtrack_win32_4517_pni.exe+0x1796b4 sixtrack_win32_4517_pni.exe+0x1790e4 sixtrack_win32_4517_pni.exe+0x62c6d sixtrack_win32_4517_pni.exe+0x2cc842 sixtrack_win32_4517_pni.exe+0x295970 kernel32.dll!RegisterWaitForInputIdle+0x49 I haven't dug deeper. I can if it's useful but I'll need the program source. To be honest, I think running this is a waste of time. My CPUs are spinning their wheels in a system call, not doing computation. I've set this project to "no new work" until I hear there is a fix. Please let me know if you want me to do more. ++PLS
26) Message boards : Number crunching : Long WU's (Message 24480) Posted 4 Aug 2012 by pls Post: I think you should have extended the deadline time. ++PLS

Previous 20

LHC@home