1) Message boards : ATLAS application : Credit V2.0 vs, V1.01 (Message 40337)
Posted 30 Oct 2019 by bronco
Post:
Nothing against a joke, irony or another opinion.
But as soon as a post's only purpose is to insult other volunteers it is no longer in accordance with the forum rules:


Agreed. Remarks like " and with the exception of rather dumm replies from a certain member there was never ever a logic explanation." are in violation of forum rules
2) Message boards : ATLAS application : Credit V2.0 vs, V1.01 (Message 40334)
Posted 30 Oct 2019 by bronco
Post:
How do you assign credits?
this is a question that no one could ever answer. I have brought up this topic a few times, and with the exception of rather dumm replies from a certain member there was never ever a logic explanation.
In short words: no one knows how the credit points are assigned :-(


Actually the replies given were very logical to anybody with average intelligence and a little understanding of how computers work. Apparently they were too complicated for certain dumm members who think bitching and whining about things they refuse to understand can make the impossible become possible.
3) Message boards : Sixtrack Application : unlogical differences in credit points (Message 40009)
Posted 23 Sep 2019 by bronco
Post:
everything is fine, calm down.
No idea why you are getting all that excited :-(


And I have no idea why you're getting all that excited over a "problem" that has no good solution as has been explained to you many times. Something to do with that yellow hat and vest you wear?
4) Message boards : Sixtrack Application : unlogical differences in credit points (Message 39993)
Posted 21 Sep 2019 by bronco
Post:
You don't seem to understand that explanation or perhaps you just don't like it so I won't bother repeating it because chances are you still won't buy it.
thanks for your nice and friendly reply, anyway. Was very helpful :-(


Your attempt at sarcasm is noted. The irony is that my reply is actually the very reply you need to hear, think about and take to heart which makes it friendly even if you don't like it. The reasons for illogical credit awards have been explained several times but it seems you just brush them aside in your never ending mission to be the sqeeaky wheel who motivates the devs (BOINC and LHC) to solve the crazy credits problem. But there is no good solution and devs (BOINC and LHC) know it. Accept that fact and squeak instead about a problem that does have a solution.
5) Message boards : Sixtrack Application : unlogical differences in credit points (Message 39988)
Posted 21 Sep 2019 by bronco
Post:
Yes, I do have an explanation but unfortunately it's the same explanation you've been given for the general credit weirdness you've been complaining about for over a year. You don't seem to understand that explanation or perhaps you just don't like it so I won't bother repeating it because chances are you still won't buy it.
6) Message boards : Number crunching : Weird Statistics (Message 39909)
Posted 12 Sep 2019 by bronco
Post:
This is the point
Deleted accounts must be ignored at the statistics pages.
If they appear the statistics degrade to - nonsense.


The credits are nonsense the second they are awarded.
What does it matter If they degrade and become even more nonsensical later?
The only purpose they serve is to give bored people something to discuss.
The more ridiculous credits become the more there is to discuss.
7) Questions and Answers : Windows : Utterly confused in terms of projects to run - some questions (Message 39830)
Posted 5 Sep 2019 by bronco
Post:
correction:
... then you can easily install the 3 Linux native apps following the somewhat tidy procedures given in other threads here. Well worth the effort, imho.


Actually the server will send your Linux box the native Sixtrack app automatically if Sixtrack is selected in your prefs. To run Linux native Theory and ATLAS follow the somewhat tidy procedures given in other threads here and of course select "native" in project prefs.
8) Questions and Answers : Windows : Utterly confused in terms of projects to run - some questions (Message 39829)
Posted 5 Sep 2019 by bronco
Post:
From what I gather, theory is Linux specific. Anything else to keep in mind on that front - is VB still required for Linux, too?

You can use VB on Linux if you want to but it's not recommended. It works well enough (some say) but it's very inefficient.
LHC@home has 3 native apps for Linux: Theory, Sixtrack and ATLAS. Since they are native they don't require VB (which can be a real PITA sometimes) but the best part is the much more efficient use of memory and other precious system resources.

(BTW... I'm not plugging Linux as a more efficient OS. The same efficiencies could be achieved with native Win apps but unfortunately only Sixtrack has a native Win app, there is no native Theory or ATLAS app for Win. )

My linux box is completely headless so not sure how to go about grabbing the latest vb and extension pack using ssh as I'm still a Linux newbie...

If you can use ssh, cut and paste command lines into a Linux terminal and edit a few config files (as su (superuser)) then you can easily install the 3 Linux native apps following the somewhat tidy procedures given in other threads here. Well worth the effort, imho.
9) Message boards : Theory Application : (Native) Theory - Sherpa looooooong runners (Message 39404)
Posted 20 Jul 2019 by bronco
Post:
Really hard to keep sitting on your hands. Well done, bronco !!

Not so hard with assistance from my watchdog script. I haven't yet found a way to make it query the McPlots database (credentials problem) so I screen scraped it and saved it as a text file which the watchdog searches for the job. From the McPlots report it calculates the job's viability. For that +4 day job the viability was 2 out of 10, not promising.

The script also watches the number of processed events. That task ran for 2 days before processed events rose above 0. As the processed events increases, the script is able to predict completion time with some accuracy (in most cases accurate almost to the minute, so far). Since completion time was well before deadline and the script indicated no warning signs like 'Y out of bounds', it was allowed to continue.

The questions are:

1. With so few tasks failing now that the bad Sherpa jobs are being filtered at the server, is it worth spending CPU cycles on a watchdog script?
2. What will happen when we start a new workflow? Will all jobs in the McPlots database initialize to "0 attempts, 0 success, 0 fail, 0 lost" and if so then how will the server filter out the loopers?
10) Message boards : ATLAS application : ATLAS tasks couldn't run (Message 39396)
Posted 19 Jul 2019 by bronco
Post:
If you unhide your computers it will be much easier to look through your result logs and diagnose the problem.
11) Message boards : Number crunching : most unpolite host of the day (Message 39388)
Posted 18 Jul 2019 by bronco
Post:
Oh, joy. Several/many hours of my time that I'll never get back but luckily I have only used this host for Boinc and hopefully it might even be faster as it should clear out all the rubbish my sister left on it.

All that work so you can run 1 single core Theory VBox and maybe a Sixtrack simultaneously. That's dedication to the cause.
With just a little more work you could put Linux with a small desktop GUI on that machine and run a single core (2 athena threads) ATLAS plus a (Theory or Sixtrack), like I do on my old X2 with 4 GB. Yes, a bit of a learning curve but you could learn enough in a day to get you up and crunching. Anything to get rid of VBox. It's not just the overhead it's the ongoing PITA.
12) Message boards : Theory Application : (Native) Theory - Sherpa looooooong runners (Message 39387)
Posted 18 Jul 2019 by bronco
Post:
4 days 16 hrs to finish this one on my old Athlon X2.
runspec=boinc pp ttbar 7000 - - sherpa 2.1.1 default 4000 78
MCP record: evts: 9000 attempts: 38 success: 6 fail: 5 lost: 27

Had runRivet.log shown crazy integration time remaining or other warnings like "Y out of bounds", I would have cut my losses and aborted it. Glad I didn't. It's easier to have patience with long runners now that the loopers are filtered out.
13) Message boards : ATLAS application : ATLAS native - Configure CVMFS to work with openhtc.io (Message 39317)
Posted 8 Jul 2019 by bronco
Post:
I don't know how to setup a local proxy. I read the SQUID link and it's outside my wheelhouse. I see "openhtc.io" in the title of this thread but don't know how to do it unless the sequence of commands above do it.
I have no complaint about ULing and DLing files from CERN. Depending on how I switch to ATLAS I may have ~240 WUs DLing and each is ~365 MB so it slows down.

The instructions for Squid are a bit confusing but you've got the CVMFS, the Singularity, you're over the hard part. Ask in the squid thread and I'll give you a working example. With 240 WUs DLing.... I just can't see it working nicely without a Squid. I can't even see it working badly unless you have outrageously fast connection and unlimited data.
14) Questions and Answers : Unix/Linux : How to speed-up elaboration? (Message 39304)
Posted 6 Jul 2019 by bronco
Post:
Ignore the increments, they mean nothing.
You are caching too many tasks, that is the reason you have results with "Not started by deadline - canceled" status.
You need to reduce the number of cached tasks. In your computing preferences what are your settings for "store at least" and "store up to an additional"? Reduce those settings to half of whatever they are now. Then abort any tasks that have not started. Allow at least 24 hours for the new settings to settle out. With a CPU as slow as your Sempron you should never have more than 1 task running plus 1 task waiting to start.
Also, check to see if you have throttled the VM. It should be at least 90%.
15) Message boards : Theory Application : (Native) Theory - Sherpa looooooong runners (Message 39279)
Posted 4 Jul 2019 by bronco
Post:
The filter seems to be be working well. I've caught a few sherpas recently and some have been long runners but they finish successfully. The forever loopers seem to be gone.

That is good enough for me. I don't mind long ones, since my machines run 24/7 anyway. But the age of the universe is probably longer than LHC will run.


The filter has obsoleted major portions of my watchdog script, at least for this workflow. Next workflow maybe not so much.
Toying with the notion of turning my watchdog into "Sherpa hunter" which rejects all the easy jobs and crunches only sherpas with a bad rep from McPlots.
<gloat>
Pythias are like sixtrack. Anybody can do 'em.
</gloat>
16) Message boards : Theory Application : (Native) Theory - Sherpa looooooong runners (Message 39277)
Posted 4 Jul 2019 by bronco
Post:
I have a message back from the Theory team saying that since a few weeks there is a filter which stops sending particular looping jobs. However, I have nevertheless investigated for myself and here are the results:

Over the past week there have been over 14K successful jobs on Native Theory and only ~ 10 have been problematic. I ordered the results by disk usage and elapsed time.
The largest disk usage of a successful job was 44.45 MB. Of the six failures that were higher, 4 were long runners aborted by users and 2 hit the disk exceeded limit (200MB).
Reducing the disk limit to 50MB should catch the problematic jobs.


The filter seems to be be working well. I've caught a few sherpas recently and some have been long runners but they finish successfully. The forever loopers seem to be gone.
Thank you, Laurence :-)
17) Message boards : Theory Application : New version 263.95 (Message 39275)
Posted 4 Jul 2019 by bronco
Post:
... So let's see what happens.

At least ATLAS will also limit the # of tasks you can download.
As mentioned a couple of times this is caused by the fact that ATLAS doesn't correctly respect the #cores parameter (as it was originally introduced).


This is an ongoing problem that can be compensated for but it's confusing for a lot of volunteers. It really needs to be fixed.
Laurence, while we have your attention?
18) Message boards : Theory Application : (Native) Theory - Sherpa looooooong runners (Message 39223)
Posted 28 Jun 2019 by bronco
Post:
I have just added some logging and will try to investigate the issues in more detail. There are three categories:

  1. looping jobs (infinite time)
  2. slow jobs that are reasonable
  3. slow jobs that take too long


Will look at the results after the weekend once we have some data.



Sounds good. Is the additional logging directed to output files on our hosts or to files on the server we cannot access?
19) Message boards : Theory Application : Could not get X509 credentials (Message 39212)
Posted 27 Jun 2019 by bronco
Post:
Interesting. Whatever is wrong with your computer ID: 10555784 has now spread to Penguin's host(s) too. You guys on the same LAN? Exchange files?
20) Message boards : Theory Application : (Native) Theory - Sherpa looooooong runners (Message 39210)
Posted 27 Jun 2019 by bronco
Post:
What if the limits are just a bit too strict?


I assume we're speaking to problems with TheoryN not Theory VBox

1) Set task duration to 4 days (on my hosts it seems 95% finish in < 3 days)
2) Set (deadline + days of grace) = 15
3) Allow users a way to extend the task duration if they wish.
4) Allow graceful shutdown

I realize 4 is tricky and might take some time to implement. It may even be impossible. Do 1, 2 & 3 for now. Maybe 4 later.


Next 20


©2024 CERN