8th Annual BOINC Pentathlon

[StefanR5R]

Maybe that accelerator of theirs isn't as well shielded as it should be?

 

[crashtech]

Well I agree that this ought to be a case of user error. Here's a screenshot of my settings:

I did change number of CPUs from "1" to "No limit" today, but nothing else was altered because nothing else was wrong. Both machines are Skylakes, and both had VBox installed. Once Vbox was removed, the problem went away. None of the other machines running LHC have experienced this problem.

 

[TennesseeTony]

Nooo! All my downloaded Cosmo disappeared with the reporting of the tasks! Got more coming in now, pretty sure the 'old' ones weren't due until the 19th. Odd. I freaked at first before I remembered they were quorum of one. Out of work for a bit though.

Ah, 20 minutes after GPU shutdown and it's already 5F cooler.

 

[crashtech]

Might we catch OcUK yet in the overall standings?

https://www.seti-germany.de/boinc_pentathlon/statistiken/pentathlon.php

 

[TennesseeTony]

Well that is certainly the plan. Then pass them. The hopeful plan at any rate.

I just understood your joke Stefan, about the accelerator. Lol!

 

[uallas5]

I just checked the stats page and we're tied with OcUK at 231 points each!

 

[Ken g6]

Well, we may not be great at swimming, but it looks like it enabled us to pull off The Italian Job. (One of my favorite movies. )

I just checked the stats page and we're tied with OcUK at 231 points each!

And since we've beaten them in 3 projects (assuming we keep our lead in the Sprint), a tie is a win for us.

 

[TennesseeTony]

Thanks to Stefan's incredible bunkering ability, we are able to most likely only worry about LHC for the remainder, while others still have to juggle Cosmo into the mix.

 

[StefanR5R]

@Ken g6, because we are not great at swimming, we are allowed to take the speedboat instead?

 

[crashtech]

My new 1700X is cranking out LHC for all it's worth! It's tough to say how well anything is doing, is it not? Looks like wild variations between WUs.

 

[TennesseeTony]

Wild variations in LHC SixTrack? What are your talking about? My tasks are all taking exactly somewhere between 10 seconds and 14 hours. Very consistent.

I mean, really though, 10s, 2m, 6m 10m, 12m, 28m, 32m, 38m, 41m, 48m, 54m, 1h10m, 1h50m, 2h, 3h, 3.5h, 4h, 4h20m, 6h, 7h, 9h, 10h, and on and on. LHC must have the people who designed Einstein's website creating the tasks for them.

 

[TennesseeTony]

Other teams are looking around, baffled. Their MP3 player of choice is just fine. So where is TAAT sound coming from?

 

[crashtech]

I think my new Ryzen 1700X has suddenly made my contributions much more substantial. It's a beast!

 

[StefanR5R]

One of my boxes is not having a lot success at LHC: It received long stretches of those 10-seconds tasks, and there is also quite a high rate of computational errors. The former means that the queue of "ready to start" tasks goes barely deeper than a few minutes work, or often runs dry. The latter means that there are sometimes dozens of error'ed tasks sitting there to be reported, which somehow causes the boinc client to request new work less frequently. Or rather, the LHC server likely takes note of the error rate and replies with "No tasks are available" more often then not, and the client increases its intervals in which it asks for new work. If not monitored closely, these backoff periods soon become hours, or a day.

(Remember: "No tasks are available" at LHC does not mean that LHC doesn't have any work ready. They have plenty. It only means that LHC denies that particular client any new work for whatever reasons, for whatever duration.)

LHC's strategy is to send out alpha-quality WUs, and to limit the ensuing damage by keeping clients' task queues shallower than shallow.

 

[Kiska]

One of my boxes is not having a lot success at LHC: It received long stretches of those 10-seconds tasks, and there is also quite a high rate of computational errors. The former means that the queue of "ready to start" tasks goes barely deeper than a few minutes work, or often runs dry. The latter means that there are sometimes dozens of error'ed tasks sitting there to be reported, which somehow causes the boinc client to request new work less frequently. Or rather, the LHC server likely takes note of the error rate and replies with "No tasks are available" more often then not, and the client increases its intervals in which it asks for new work. If not monitored closely, these backoff periods soon become hours, or a day.
Or rather, the LHC server likely takes note of the error rate and replies with "No tasks are available" more often then not, and the client increases its intervals in which it asks for new work. If not monitored closely, these backoff periods soon become hours, or a day.

I am not sure what is causing that since all of mine validate fine: https://pastebin.com/nuLa84bQ
Its a defence mechanism, against faulty computers. I would recommend looking into the issue. Then if the server sees valid work it will slowly increase work limits

 

[StefanR5R]

I would recommend looking into the issue.

Those are likely application bugs, not a host-side issue. The box had been doing fine at the other projects so far.

 

[StefanR5R]

Glad to read that the "That company" pseudonym found some appreciation at [H].

 

[Kiska]

Those are likely application bugs, not a host-side issue. The box had been doing fine at the other projects so far.

Because here are my task stats:
State: All (1230) · In progress (378) · Validation pending (115) · Validation inconclusive (7) · Valid (716) · Invalid (0) · Error (14)

I would love to look at your task list so I can see any issues, but you have your computers set to hidden...

 

[StefanR5R]

[LHC SixTrack]

My machine with the high error rate is the only one which sets the estimated remaining time of newly downloaded tasks to something on the order of 10 seconds, even though it had been working at 8-hour units lately. The estimation is obviously still trained badly from the first few downloads which were mostly few-seconds tasks.

I wonder if the watchdog timer which kills a task when elapsed time exceeds this timer, is influenced by the initial estimated runtime of a WU.

I deinstalled VirtualBox and rebooted now, although presence of VirtualBox should have no influence on SixTrack. Next I will let the current tasks finish, then detach the machine from LHC, then reattach, and hope that the very first batch of downloaded WUs is of a reasonable sort.

Erroring machine:

OpenSuse
Validation pending (378) · Validation inconclusive (17) · Valid (839) · Invalid (0) · Error (486)
total credit = 18,000​

Successful machine with same hardware but different OS:

Gentoo
Validation pending (83) · Validation inconclusive (9) · Valid (542) · Invalid (0) · Error (0)
total credit = 46,000​

Both machines have been doing LHC/SixTrack for about the same time now; actually the good one started a bit earlier. The large difference of total number of tasks (1720 : 634) shows how the former machine had been abused for many of those few-seconds WUs. The latter machine got its share of short WUs too, but evidently not as many.

 

[Orange Kid]

I have one box that has errors also. All of the bad tasks have 5/16 for a date. both received and returned. I am guessing a bad batch of work got out?

 

[Orange Kid]

all the bad work was..
SixTrack v451.07 (pni)
windows_intelx86

 

[StefanR5R]

Almost all errors which I had, i.e. hundreds, were from

SixTrack v451.07 (pni) i686-pc-linux-gnu
SixTrack v451.07 (pni) x86_64-pc-linux-gnu​

Only a few (just 4) were from

SixTrack v451.07 (sse2) x86_64-pc-linux-gnu​

Removing and re-adding the project did not help.
Adding LHC to a different client instance on the same box may have helped. I will know more in a few hours, or tomorrow.

 

[TennesseeTony]

There you go buddy, a little trophy for you to hang on your wall! (Yoyo)

 

[StefanR5R]

Yummy!

 

[Ken g6]

Now getting:

Tue 16 May 2017 04:23:20 PM MDT | LHC@home | No tasks are available for SixTrack