LHC@home

It sems WUs with names beginning w-.... are creating a bit
much I/O for Windows. Under investigation, but the results
are good and are required. Thanks. Eric.

---

Is that why there are sixtracktest works right now?

No, those were an attempt to try a MacOS executable.
I am testing w- stuff on my own machines.

---

Eric,

FYI, I have run a number of the "w-" Tasks and while they take a lot of CPU cycles I have had no problems. I was initially concerned about the long run times but since you calmed me down I don't worry anymore and just let thing crunch away. Also, I do shut the system down for a few hours overnight and then on occasion during the day.

Since the machine I'm using was one configured for a lot of graphics and documentation work it has a large RAM (16GB) and I have allocated 100GB of HDD to BOINC. Now its use is just casual surfing and BOINC. The largest user BOINC of HDD is vLHC @ 5.2GB, 2nd largest is SETI. These two are fairly consistent in their disk usage.

System configuration is:
windows7 Professional x64 - SP1, INTEL i7-2600 3.40GHz, 16GB RAM, NVIDIA GeForce GTS 450, 1TB HDD (c:)

My system is 9955583

Also running SETI, vLHC, & Enigma on the system.

I was running vLHC 4.3.10 until last night and just updated it to 4.3.12.

Tom

I just happened to take a look at the amount of disk space being used by LHC Tasks I have currently running. It is 485+ MB.

Currently 5 Tasks are running.

Thanks Tom; I too am running on Windows 7. I'll try and figure
out some kind of limit to maybe allow deselect of w-.
However we have a lot of work and maybe it is better to just let users with problems to deselect LHC@home......I have to catch a plane in two
hours and with 85.000 WUs active and over 200,000 queued I
don't want to mess up. Eric-

---

Hi Eric,

I'm not complaining. Just thought you would find the info helpful.

Tom

Yes indeed, very helpful. I am now trying some w- on
my own Windows 7 laptop....................we shall see.
Thanks a lot. Eric.

---

Eric
FYI - plenty of my machines started freezing recently, quite random.
Not sure is it affected by new tasks structure and heavy I/O operations. Wasn't that bad before.
I run different versions of BOINC for identification purposes usually, in case of some issues it helps identify and isolate problem, but this seems pretty random.
Anyway as example 2 frozen right now run 7.2.42 version which assumed as most recent workable as I remember, so it might or might not be a point.

Thanks for that; can you give me a taskid or something?
If I am right the task(s) should now finish, successfully......
Injvestigation continues, I think it is WU case dependent
no the BOINC version. We shall see. Eric.

---

I think I may be seeing the same "w-" thing here. Not entirely convinced its LHC code to blame here though - neither am I sure its the high IO rate to blame. No need for a direct response to this unless something jumps out at you... Hopefully the following may help:

Me: ID: 332140 Win 7 box, i7-2600K CPU @ 3.40GHz, NVIDIA Quadro FX 580 512MB. BOINC 7.2.42 Running SETI@, COSMOLOGY@, EINSTEIN@, MILKYWAY@ and LHC@home 1.0.

Symptom is BOINC throws multiple ERROR windows and CLOSE PROGRAM windows after a few minutes. New behavior that I "think" is associated with LHC - I can't definitively prove that statement though. Seems to be associated with these recent LHC work units is the best I can say.

FYI - your IO reads are running around 800 in the file manager - compare to 14 for a Cosmology@ app and 2000 plus for a Seti Astropulse app as each cycles through processing.

Memory usage is 23.5k for the LHC App - compare to a mighty 100k thru 370k for a typical Cosmology@ executable. Nothing obviously out of line in your resource usage from where I sit then.

Only thing that looks at all funky is that both Sixtrack and Cosmology@ stay resident in memory when the screen saver exits - something I have told BOINC not to do in my preferences... That may or may not be related to the error I am seeing here of course. Bottom line if the units are coming in good at your end then I can deal with the error windows - system appears to continue working through the multiple error windows anyway. Thanks for your efforts.

---

I'm having the same problem. I finally found who was the responsible of the 100% of the hard disk usage and was the LHC tasks.
After a BSOD I suspended temporally the project. Should I continue?

My user ID is: 213953 and... I don't know how to find my taskID in BOINC. I currently have in progress three of the following tasks on LHC: 49714392, 49714344, 49714090, 49714062, 49714058.

If it's "normal" and temporally I will continue computing it.

If you need more info or something don't hesitate to ask me.

Sorry for my poor English.
Regards,
Casaneas.

P.D. My computer specs are: Intel i5-2500k, AMD 6850HD, 16GB RAM, Windows 8.1u1.

I'm not surprised that Windows is seeing a lot of I/O. I was just defraggler'ing my system disk and found 30 LHC fort files that had 73,000+ fragments. (That's 2K+ fragments per file, folks.) I've seen this kind of thing twice. Once, someone had intentionally turned off buffering. The second, someone had decided it might be a "good idea" to do an "fflush()" after every write....

I'm fortunate in two ways, I'm using only six of eight CPUs for BOINC and LHC@home only downloads a limited number of WU per host. If I had a lot of these WUs processing at any one time, I'd run out of extents in a heartbeat....

I'm taking no more LHC@home WUs until this is straightened out.

-- CCW (aka Carolina Calling)
Durham, NC, US

Casaneas, try deactivating Windows' searching and indexing tool. Maybe that works.

Nope. Exactly the same. I deactivated it but when I start LHC tasks the H.D. use go to 100%

I have had to cut back my recent contributions too. I have had a few systems that had noticeable slow downs and delays do to the IO's. So, for the systems that get used for functions other than DC, this project is being set to NNW. Will check in periodically for status updates.

---

Here is a suggestion to try in an effort to eliminate or minimize the impact LHC has on other applications.

Note: This works with applications that the user starts when doing other work on the same computer. I have no way of testing whether it works with applications that start based on other demands.

Make use of the "exclusive applications" tab and insert those specific applications in the list.

Under BOINC Manager, click Tools then click Computing preferences and then select the "exclusive applications" tab. Click Add and then navigate to the application and add it to the list.


I just double checked that this function is still working (using Photoshop) and as far as I can tell, it is. All Projects indicate Suspended under the Tasks tab. I also checked VM (for those running vLHC or other Projects) and the status on those Tasks indicates "Paused"

The advantage of using the "exclusive applications" feature is that you never have to remember to Resume the Projects that you Suspended. They will automatically restart once all designated applications are closed.

Has there been a change in the I/O for generating "fort" files in SixTrack?

I don't know whether to blame the work units or SixTrack for these I/O problems (although I suspect the latter).

As the I/O was adversely effecting my system, I've now aborted all the "w-" work units and continue to get no new work units.

I, for one, have been very pleased to be a small part of LHC SixTrack's work and look forward to being part of it again. I continue to process ATLAS and VirtualLHC work units.

Currently, I'm not accepting any new work units for any project in order to upgrade to the new version of BOINC (7.4.27). I let all projects' work units finish before upgrading to start with a clean slate. I'll see what happening with SixTrack so that I may turn it back on along with everything else.

I hope SixTrack will be fixed in the near future.

Please, let us know if the source of the I/O problem is found.

-- CCW
Durham, NC, US

"w-" work: Your experience may vary, but on my Windows 7 64 bit system with Kaspersky security I had this bad experience.

1. I had 8 LHC "w-" tasks running in High Priority.
2 Two showed 100% complete, Two were 99+% complete, Two where 98% complete, One was 80+% complete and the other was 20+% complete.
3. Windows Resource Monitor showed memory about 50% active, 50% on Standby and Zero free.
4. Windows Resource Monitor CPU show very little to Zero CPU activity, with some processors "Parked".
5. Windows Resource Monitor Disk activity was about 10MB / second.
6. Boincmgr was sluggish to non responsive. Event Log sometimes worked and sometimes it was a blank page. When it worked it did not update.
7. Boincmgr suspend, abort, resume took more than a minute to work, though if you did not give up it would complete.
8. Boincmgr did show time to completion going down on only one or two tasks going down but did not show the completion percentage going up.
9. After Aborting the "w-" work, one none "w-" LHC task plus seven other project tasks started running. CPU on all processors went to 100%, Disk activity when up and Free Memory when back to normal.

Good luck with LHC "w-" work for the rest of you.

---

I finally ended my active tasks and stopped the project. I will visit this forum sometimes for updates and meanwhile I will process in other projects.