LLRnet server rally 400<k<1001 August 8-10

[kar_bon]

Originally Posted by Anonymous

Ah, Karsten beat me to the punch. One thing, though: could you please clarify that you mean by "workspace=1"?

oh, sorry, wrong term.
should be "WUCacheSize = 1", so only one pair per core at once reserved!

[Mini-Geek]

Originally Posted by kar_bon

only my opinion:

to make a range/pairs manually and count them for the ralley is against the 'spirit' of the ralley itself!
the purpose of a ralley is to compete against under the same conditions for all:
so originally there should a workspace=1 (no bigger reservations before/while/after ralley), same llrnetclient for all, no personal server for one, etc...

perhaps there're other opinions.

Karsten

Is the spirit of the rally to
1 get people that might otherwise be putting resources on other projects (or even, :surprised, having them idle) in those 24/48 hours to crunch with NPLB as a fun community project thing, or
2 a counting of how much we can do in 24/48 hours, or is it
3 a competition to see who can crunch the most in 24/48 hours?

I've always thought of it as the first.

The second doesn't make too much sense.

You apparently think it's the third. I don't think the competition interpretation makes much sense, since it's basically just saying who has the most cores. If it makes you feel better, feel free to take out 5%, or whatever the manual LLR gain gives me when you rank the stats. It probably won't move me anyway, and I'll probably be near the bottom of the list anyway, with my 2 "slower" cores.

Maybe it's some combination of the three...a fun competition that counts how much we can do in 24/48 hours.


All that aside, if people are against this, or if it would be too much work, I'll crunch on LLRnet instead.


How does having more than one number reserved give any sort of advantage, other than that your computer won't have to pause up to a few seconds between numbers?

[mdettweiler]

Originally Posted by kar_bon

oh, sorry, wrong term.
should be "WUCacheSize = 1", so only one pair per core at once reserved!

Ooh...I'm not so sure about that. Considering the way LLRnet returns results, the size of the cache should be irrelevant, since results are still returned right after they're finished crunching anyway. Not to mention that if we limited users to a cache size of 1, there are numerous disadvantages of that: first and foremost, the fact that even the slightest network problem will cause a client to be idle or even freeze up; secondly, if you only have a cache size of 1, there is a slight idle delay between k/n pairs since the client has to wait until it can fetch a new one before starting the next. Long story short, I recommend that everyone, no matter how reliable or fast their connection, use a cache size of 2 as a minimum, possibly more if they've got a shak connection. (Especially considering that, if you think about it, it causes no detrimental effects on rallies.)

The only possible problem I can think of would be the PrimeGrid batching client, which stores up results and then sends them in at once--that would run the risk of getting some k/n pairs that were actually crunched right before the rally counted as in-rally. However, IMO the effects of this are small enough, and the potential for decreasing server load (not to mention alleviating connection instability) are large enough, that use of the batching client should still be tolerated.

[mdettweiler]

Originally Posted by Mini-Geek

All that aside, if people are against this, or if it would be too much work, I'll crunch on LLRnet instead.


How does having more than one number reserved give any sort of advantage, other than that your computer won't have to pause up to a few seconds between numbers?

None that I can think of, as detailed in my previous post.

[gd_barnes]

Originally Posted by Anonymous

Yeah, I know, I agree that it is a bit convoluted. However, based on some shaky experiences I've had lately with my own internet connection, I fully understand Mini-Geek's desire to have an offline solution. So, if Gary and Karsten are OK with it, we may as well go ahead with it, though I should probably warn everybody that we won't necessarily do this for everybody, or else it will get really hairy.

I disagree completely with this and as Karsten says, it's against the spirit of the rally. I almost lean as strong against it as Carlos does. I won't call it ridiculous but I will say that it is well out of line with what a rally is supposed to be.

IMHO, if your internet connection is poor, then you need a better provider or a better connection or something. I'm sorry to seem unsympathetic to people's circumstances but steps can be taken to improve internet connections albeit at some cost.

Mine rarely drops...perhaps once every 2-3 months. My issues have been small intermittent power outages in the neighborhood that I live in that shut my machines down while I'm out of town. Unfortunately they can't turn themselves back on. lol Another time, it was the server itself being brought down and back up 2-3 times that put all of my LLRnet machines in sleep mode.


Gary

[gd_barnes]

Does anyone know if Lennart will participate in the rally?

I'd like to let him know he could stop sieving to participate in the rally. We need a good boost on drive 1 REALLY bad right now!


Gary

[gd_barnes]

Originally Posted by Anonymous

Ooh...I'm not so sure about that. Considering the way LLRnet returns results, the size of the cache should be irrelevant, since results are still returned right after they're finished crunching anyway. Not to mention that if we limited users to a cache size of 1, there are numerous disadvantages of that: first and foremost, the fact that even the slightest network problem will cause a client to be idle or even freeze up; secondly, if you only have a cache size of 1, there is a slight idle delay between k/n pairs since the client has to wait until it can fetch a new one before starting the next. Long story short, I recommend that everyone, no matter how reliable or fast their connection, use a cache size of 2 as a minimum, possibly more if they've got a shak connection. (Especially considering that, if you think about it, it causes no detrimental effects on rallies.)

The only possible problem I can think of would be the PrimeGrid batching client, which stores up results and then sends them in at once--that would run the risk of getting some k/n pairs that were actually crunched right before the rally counted as in-rally. However, IMO the effects of this are small enough, and the potential for decreasing server load (not to mention alleviating connection instability) are large enough, that use of the batching client should still be tolerated.

I always use a cache size of 2 on all of my machines. I don't like to use larger because I don't want to have to wait a long time to clear them out when I'm ready to move the machine to something different. Not clearing them out is a problem for us admin folks, causing us to have to wait until the pairs get returned to the server and then handed out to someone else for processing.

[gd_barnes]

Originally Posted by kar_bon

i can't bring any core this time for this ralley now. sorry!

but i'll follow the race if i can and will make the stats after finishing.
hope not to let all of you wait so long for the results.

good luck then to all!

Karsten

Where are your cores at? Did you lose them? lol

[Mini-Geek]

Originally Posted by gd_barnes

I disagree completely with this and as Karsten says, it's against the spirit of the rally. I almost lean as strong against it as Carlos does. I won't call it ridiculous but I will say that it is well out of line with what a rally is supposed to be.

IMHO, if your internet connection is poor, then you need a better provider or a better connection or something. I'm sorry to seem unsympathetic to people's circumstances but steps can be taken to improve internet connections albeit at some cost.

Mine rarely drops...perhaps once every 2-3 months. My issues have been small intermittent power outages in the neighborhood that I live in that shut my machines down while I'm out of town. Unfortunately they can't turn themselves back on. lol Another time, it was the server itself being brought down and back up 2-3 times that put all of my LLRnet machines in sleep mode.


Gary

Okay, I'll use LLRnet for the rally. It's not that my internet connection is terrible, just that I hate the idea that I could stop crunching (especially for something timed like the rally) while my computer is still on (there's many more points of failure with LLRnet that LLR, and one of them is especially vulnerable during a rally, i.e. the server). I'll run LLR in the background just in case LLRnet stops so at least my computer won't idle.

BTW, you know you can edit and/or quote multiple posts in one large post instead of posting four times, right Gary?

[Flatlander]

I'll bring four fast cores to AES300. (The server with all the primes. )

[em99010pepe]

I am not sure if I will be here on August 8 at 7 pm GMT but I can start my server at 7 am GMT. Just let me know. Please change the port to 443 instead of 400. Thanks.