LHC@home

I am getting a completely new experience with many of the new work units. They run to about 0.030% completion in 14 seconds on my computer, and then go back to zero %. The elapsed time in all those cases, as displayed in BOINC manager, also jumps back from around 14 to 4 seconds. Something I did not know was possible. In other words, elapsed time is jumping backwards.

I'm aborting those jobs now, because they just seem to be completely stuck without progress. Because it's my bed time I will suspend LHC for now. Please let me know if and when it is safe to resume LHC again.

we have looked at the workload in question. The results coming back are good.
The only thing is that this workload is for very steep amplitudes, which may be lost very quickly.
The jobs may be running very short and put more pressure on the network, then on the processor.

Also, now we have a new executable in production, which contains new physics.

In conclusion, please continue crunching and report back again if you discover new problems.

---

I too had 4 WUs thoroughly stuck at 0% for over 10 hours. They were consuming 0% CPU despite the fact that BOINC claimed that they were running. I aborted these units. There definitely is a problem with the new client. I successfully ran sixtrack units before. This is on openSUSE 12.3 with BOINC 7.0.65.

I got more WUs that all show the same problem. This is in the logs (repeated a zillion times):

2013-09-04T21:01:57 CEST | LHC@home 1.0 | Restarting task sd_sixt5_890_1.6_4D_err__26__s__62.31_60.32__8_10__6__15_1_sixvf_boinc2180_0 using sixtrack version 44603 (pni) in slot 30
2013-09-04T21:01:59 CEST | LHC@home 1.0 | Task sd_sixt5_890_1.6_4D_err__26__s__62.31_60.32__2_4__6__65_1_sixvf_boinc2139_0 exited with zero status but no 'finished' file
2013-09-04T21:01:59 CEST | LHC@home 1.0 | If this happens repeatedly you may need to reset the project.

Each WU crashes as soon as it starts and then gets restarted indefinitely (I have never seen anything good come out of that policy, especially the indefinite part, but that is a different discussion...). This problem is 100% reproducible. Needless to say that resetting the project didn't help (does it ever?). I am disabling this project until I see a message here that this is solved or that we have reverted to a different client.

I am getting a completely new experience with many of the new work units. They run to about 0.030% completion in 14 seconds on my computer, and then go back to zero %. The elapsed time in all those cases, as displayed in BOINC manager, also jumps back from around 14 to 4 seconds. Something I did not know was possible. In other words, elapsed time is jumping backwards.

I'm aborting those jobs now, because they just seem to be completely stuck without progress. Because it's my bed time I will suspend LHC for now. Please let me know if and when it is safe to resume LHC again.

I am getting the same problem. I look into the log file and see "No Heartbeat from client in 30 seconds, restarting..."

Major symptom is Elapsed Times keeps jumping backward...

As of an hour or so ago, all the new WU's failing...

I aborted the bad WU's and kept the good... NNT for now until I see the uploads proceed properly.

:)

PS: This problem only show up on my Linux machines so far... forgot to mention that...

Good morning from New Zealand.
I just came into office where my office computer crunches LHC too overnight. All of the recent tasks had crashed out with computation error or were stuck in the same (almost endless) loops.

Example is Task: 19624429

You will see it crashed out with a computation error after too many exits.

I have now seen this problem on 4 different computers at 2 different locations, so I don't think it's just me.

I run Xubuntu Linux on all my machines, versions 12.04 on 3 of them and 12.10 on 1.

Please do let me know when this problem is fixed, because I'm suspending LHC for now.

All systems are go on my Linux box, SuSE Linux 12.3, BOINC client 6.10.58. No problem so far.
Tullio

I tried a few new WU's again... same problem... I run Linux Mint 64b on my systems with BOINC CLIENT 7.0.65.

Oh well...

:D

Same here. I tried again this morning on my office computer, after Ubuntu pushed out a network manager update and I had rebooted the computer.

Results from the log file are:
Fri 06 Sep 2013 08:50:17 NZST | LHC@home 1.0 | Task W0w20cbb_w30cbb63__36__s__64.31_59.32__13_13.5__6__3_1_sixvf_boinc16640_1 exited with zero status but no 'finished' file

Fri 06 Sep 2013 08:50:17 NZST | LHC@home 1.0 | If this happens repeatedly you may need to reset the project.

Fri 06 Sep 2013 08:50:17 NZST | LHC@home 1.0 | Restarting task W0w20cbb_w30cbb63__36__s__64.31_59.32__13_13.5__6__3_1_sixvf_boinc16640_1 using sixtrack version 44603 (pni) in slot 1

This repeats endlessly.

I'm running Xubuntu 12.04 (precise) 64-bit.
Linux Kernel 3.2.0-52-generic
BOINC version 7.0.65(x64)

As a side note, one of my home computers was still able to successfully complete an old LHC task this morning. Therefore, the problem is definitely caused by the new version.

With a couple of 13hr WUs just about to finish, 446.03 is running fine on Win7.
Obviously that's no help to you guys running Linux but at least Eric & co won't need to look for a global issue as the problem with the new version seems to be isolated just to Linux. Hopefully that means they will be able to resolve it sooner or revert to 444 while they fix it.

With a couple of 13hr WUs just about to finish, 446.03 is running fine on Win7.
Obviously that's no help to you guys running Linux but at least Eric & co won't need to look for a global issue as the problem with the new version seems to be isolated just to Linux. Hopefully that means they will be able to resolve it sooner or revert to 444 while they fix it.

Did you try suspending your task (remove from memory), and starting it again?

The problem could be in the 'restart from checkpoint' area, which means it could still be cross-platform.

I have 3 tasks completed and validated on my Linux box, another is running and is at 66% after 14 hours. No problems here with the new version.
Tullio

Looking a bit more at what is happening. The executable file that gets downloaded on my Linux machine is:
sixtrack_lin64_4463_pni.exe

This is identified as a DOS/Windows executable by the file manager. It that is indeed what it is, then it's not surprising that Linux cannot execute it. It might conceivably be executable if I had WINE installed, but I do not, and I have not tried that. Perhaps other Linux users do have WINE installed and therefore get to execute it anyway, but that is just speculation.

I also note that the executable attribute bit is not set for the .exe file after the download.

Yes, it looks like a DOS/Windows executable but it runs OK on my Linux box. I don't have WINE installed. The executable bit is set.
Tullio

Thanks for all the (detailed) feedback.l Looks like a Linux problem on
"some" Linux systems. We tested on basically RedHat 6. All this compounded
by a series of unusually short WUs. Top priority to resolve soonest.
Don't want to go back because of an urgent need for the new physics.
(We do not yet have a MAC executable.) Famous last words, but it should
not be too difficult to resolve. Sorry for the hassle. Eric.

---

I saw this on win7 and ubuntu. I aborted tasks.

I tried to do a ldd on the executable, but it is not a dynamic executable. Must be a static one.
Tullio

Out of curiosity, I installed WINE and tried if that made a difference. Unfortunately, it doesn't. Behaviour remains as before: tasks keep looping.

With a couple of 13hr WUs just about to finish, 446.03 is running fine on Win7.
Obviously that's no help to you guys running Linux but at least Eric & co won't need to look for a global issue as the problem with the new version seems to be isolated just to Linux. Hopefully that means they will be able to resolve it sooner or revert to 444 while they fix it.

Did you try suspending your task (remove from memory), and starting it again?

The problem could be in the 'restart from checkpoint' area, which means it could still be cross-platform.

Running OK here on Ubuntu 8.04, it's Mint version, Ubuntu 10.04 and 10.10 (W2K and XP, too). All restart correctly from host power cycle so presumably the checkpoint mechanism is working.

John.

There are problems with the Linux version 4463 and this is not related to naming.
I have verified, that even so the executables have .exe extension they are Linux.
Therefore, you don't need Wine to run them, it is all very standard.
By the way, I have corrected the scripts to name them differently next time.

There seems to be a correlation with Boinc Client version 7.x under Linux.
I'm not suggesting to go back in Client version, we must have a clean executable.

We are looking at the compilation of time accounting routines under Linux,
since there is evidence pointing to the mktime routine.

Probably will take until monday to resolve. Sorry for the inconvenience.

Igor.

---

skype id: igor-zacharov