Thoughts about upcoming LLRnet rallies

[mdettweiler]

Originally Posted by gd_barnes

With Flatlander not having internet for 2 weeks and with May 24th-25th being the Memorial Day weekend, that might be a better weekend to run a 48-hour rally. Anon and Karsten, will you be around that weekend?

Will other people be around over the Memorial Day weekend? Pardon my ignorance of holidays in other countries but I don't know if most of Europe celebrates the U.S. Memorial Day, which is the last Monday in May, where most of us are off work (not that others being off work matters for me, lol). A calendar that I have shows "Memorial Day (U.S.)" so I'm thinking that may be specific to the U.S.


Gary

Yep, I'll be around the weekend of the 24th-25th.

As for Memorial Day--no, I don't think it's celebrated in other countries.

[mdettweiler]

Originally Posted by Flatlander

I will be taking the kids' Athlon PC on holiday to the coast for the fortnight. As we will be overlooking the sea I will be hooking up my new camera to it to do some time-lapse photography. I also need the PC to download astronomy photos from my new telescope.
I will leave the Quad here running at stock speed. (With internet access.) Like I said above, if I have two LLRNET clients running on each core then if one stalls the other will, hopefully, get 100% of that core.

In other words my Quad should be on port 300 until at least May 23rd.

Can someone remind me how to set the WUCacheSize > 100 please. (I read it somewhere.)

Open llrnet.lua in a text editor, and near the beginning of the file you'll see something like "MaxWUCacheSize = 100" (or something along those lines). Changing that to something enormously big like 100000 will remove the limit for all practical purposes.

[Flatlander]

Originally Posted by Anonymous

Open llrnet.lua in a text editor, and near the beginning of the file you'll see something like "MaxWUCacheSize = 100" (or something along those lines). Changing that to something enormously big like 100000 will remove the limit for all practical purposes.

Great, thanks!

[em99010pepe]

Originally Posted by Flatlander

....but 3 or 4 times I have found an LLRNET Client stuck on 99% so I would rather do manual work.

I notice that too on my quad-core...what cache settings at the time were you using?

[Flatlander]

Originally Posted by em99010pepe

I notice that too on my quad-core...what cache settings at the time were you using?

I can't remember. This was a couple of months ago on my dual core. Do you know if it still hogs the CPU core if it freezes?

[em99010pepe]

Originally Posted by Flatlander

I can't remember. This was a couple of months ago on my dual core. Do you know if it still hogs the CPU core if it freezes?

Last rally I had one freeze llrnet instance and I had the wu cache of 2 instead of the usual 5. Maybe a server issue?! I don't know..

[mdettweiler]

Using the Linux version of LLRnet, I've never encountered a freeze (for that matter, I haven't in the Windows version either, but I have logged a lot less hours running the Windows LLRnet than the Linux one, so that probably isn't indicative of the problem). Maybe it's a problem specific to the Windows client?

[Brucifer]

Another thought to keep in mind about a rally is that if you hold them too often you start to burn people out on them, both present crunchers, and also prospective ones that aren't regulars. Like they are supposed to be "special" efforts. Just one old man's thoughts.

Another item, consider it from the "unwashed" dumb $h*T as I'm not into the know here much. But why can't you just load up a server with all this different stuff, and people take pot luck on what is handed out to their crunchers when they connect up. That way you could alter the "mix" as you see fit depending on what the priorities are. ??? Way off base here???

edit: Undoubtedly some obvious reason why you can't or you'd probably have already been doing it.

[mdettweiler]

Originally Posted by Brucifer

Another thought to keep in mind about a rally is that if you hold them too often you start to burn people out on them, both present crunchers, and also prospective ones that aren't regulars. Like they are supposed to be "special" efforts. Just one old man's thoughts.

You do have a point--in fact, that's exactly why we're going to aim for one rally every month or so now, though we are making an exception for the next one and doing it only two or three weeks after the last one because of all the new members we've had lately.

Another item, consider it from the "unwashed" dumb $h*T as I'm not into the know here much. But why can't you just load up a server with all this different stuff, and people take pot luck on what is handed out to their crunchers when they connect up. That way you could alter the "mix" as you see fit depending on what the priorities are. ??? Way off base here???

edit: Undoubtedly some obvious reason why you can't or you'd probably have already been doing it.

LLRnet doesn't have the ability to do that, you'd need a more advanced system like BOINC in order for that to work. However, running a BOINC server is no small ordeal, and I doubt there's anyone on this project who would be ready to take on such a responsibility.

Also, even if we could mix worktypes in LLRnet, it's still kinda nice to have them separately--that way users have more choices, and thus it's more fun. Not to mention that it would probably be a BIG pain in the butt for me to sort out all the results files under a system like that.

It would be interesting, though, if somebody could put together a fancy version of the LLRnet proxy server that can pull work from multiple different servers and hand them out to clients, keeping track of what server each number goes to of course so that when the client returns the result it goes to the right place. This would essentially accomplish what you're describing for users who would want it (though I'm not quite sure if it would work with the LLRnet client, that might need to be modified to work with something like this).

[Brucifer]

Originally Posted by Anonymous

LLRnet doesn't have the ability to do that, you'd need a more advanced system like BOINC in order for that to work. However, running a BOINC server is no small ordeal, and I doubt there's anyone on this project who would be ready to take on such a responsibility.

boinc is a whole other animal. Of course you would pick up a bunch of new people crunching. And then you'd probably lose some of your old ones too as the boinc world is a whole different world. It's nice to have some non-boinc projects around as there's people that won't crunch the boinc stuff. Half dozen one the other I guess.

I'm not familiar with the internal workings of llrnet so didn't have any idea of whether or not you could do any "mix and match stuff" with it. And like I said in my note, I was pretty sure that there was some relatively obvious reason why you weren't doing it. :)

And it's good to keep some manual stuff going to cause their are people that prefer working on things that way. :)

[mdettweiler]

Originally Posted by Brucifer

boinc is a whole other animal. Of course you would pick up a bunch of new people crunching. And then you'd probably lose some of your old ones too as the boinc world is a whole different world. It's nice to have some non-boinc projects around as there's people that won't crunch the boinc stuff. Half dozen one the other I guess.

I'm not familiar with the internal workings of llrnet so didn't have any idea of whether or not you could do any "mix and match stuff" with it. And like I said in my note, I was pretty sure that there was some relatively obvious reason why you weren't doing it. :)

And it's good to keep some manual stuff going to cause their are people that prefer working on things that way. :)

Yes, I agree--if we ever did get a BOINC server (not likely at all in the near future, but definitely a possibility a few years or so down the road), it would be like LLRnet in that it wouldn't replace the manual reservations--or even LLRnet for that matter--but just supplement them. However as I was saying that is neither here nor now anyway.