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

[mdettweiler]

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

I see where you're coming from--however, I beg to differ in regard to the internet connections. I, for instance, only have two broadband choices where I live: DSL or satellite. (My road doesn't have cable TV lines, so no cable internet.) Satellite is the pits, both in speed and reliability, not to mention in price, so that's ruled out. Thus, DSL is the only option--and unfortunately, within the last few months, my DSL has started to cut in and out quite a lot. The only solution is either to wait for it to come back online, or to manually reboot the router (rebooting the router will usually get it on a bit quicker, but it requires me to be actually at the computer and browsing the internet to even notice that the connection has dropped out).

For me, the problem is mostly alleviated by using the batching LLRnet client, and setting it to a WUCacheSize of 20 and a refill of 5 (essentially, talk to the server after every 15 k/n pairs processed). This keeps the times when it actually does have to connect down to a mininum, which hopefully misses the "bad" times when the router is down. It still hits the bad times occasionally, though, sometimes causing a freeze-up of the LLRnet client.

Long story short: okay, I agree, it probably isn't such a good idea to include any manual results whatsoever in the rally, since as Gary said, that's not in keeping with the "spirit" of the rally. However, for users with shaky connections like me, I recommend using the PrimeGrid batching version of LLRnet with a WUCacheSize of 20 and a refill of 5 (not so little that it hits all the downtimes, but not so much that it waits too long between sending in results--though if you have a slower computer than my Core 2 Duo, you may wish to choose slightly smaller values). IMO, using this client is still in keeping with the spirit of the rally, since it's still dealing with the server normally, and the worst that can happen is a few results that may come in near the beginning of the rally that were crunched right before the rally, or some results crunched near the end of the rally being sent in right after it. However, that would probably even out pretty well overall.

(Just to clarify: I'm not insinuating that anyone said or implied anything about the batching LLRnet client being against the "spirit" of the rally, but I figured I'd mention that aspect of it in case it came up. )

[mdettweiler]

Originally Posted by Flatlander

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

LOL--actually, most of that is probably due to the fact that it's the only 400<k<1001 server that's received much of any "business" lately. But, yeah, you're right, the range it's currently working in (and is almost done with) has had a lot of primes.

[Lennart]

About 40 core on L6

/Lennart

[gd_barnes]

Originally Posted by Anonymous

LOL--actually, most of that is probably due to the fact that it's the only 400<k<1001 server that's received much of any "business" lately. But, yeah, you're right, the range it's currently working in (and is almost done with) has had a lot of primes.

I've had 4 quads plus 2 cores on port 300 for the last 10-12 days because that's where the lowest gap was. That's why all the primes are there. But Anon is right that it has been a prolific range. By the end of today when it has reached n=516K, I'll switch them all off to port 400 since that is where the next lowest gap is.

I will run them all on port 400 for the rally if my cores combined with others cores won't overload that one server. Otherwise I'll divide them up between port 300 and 400 and/or Carlos port 400 if needed.


Gary

[gd_barnes]

Originally Posted by Anonymous

I see where you're coming from--however, I beg to differ in regard to the internet connections. I, for instance, only have two broadband choices where I live: DSL or satellite. (My road doesn't have cable TV lines, so no cable internet.) Satellite is the pits, both in speed and reliability, not to mention in price, so that's ruled out. Thus, DSL is the only option--and unfortunately, within the last few months, my DSL has started to cut in and out quite a lot. The only solution is either to wait for it to come back online, or to manually reboot the router (rebooting the router will usually get it on a bit quicker, but it requires me to be actually at the computer and browsing the internet to even notice that the connection has dropped out).

For me, the problem is mostly alleviated by using the batching LLRnet client, and setting it to a WUCacheSize of 20 and a refill of 5 (essentially, talk to the server after every 15 k/n pairs processed). This keeps the times when it actually does have to connect down to a mininum, which hopefully misses the "bad" times when the router is down. It still hits the bad times occasionally, though, sometimes causing a freeze-up of the LLRnet client.

Long story short: okay, I agree, it probably isn't such a good idea to include any manual results whatsoever in the rally, since as Gary said, that's not in keeping with the "spirit" of the rally. However, for users with shaky connections like me, I recommend using the PrimeGrid batching version of LLRnet with a WUCacheSize of 20 and a refill of 5 (not so little that it hits all the downtimes, but not so much that it waits too long between sending in results--though if you have a slower computer than my Core 2 Duo, you may wish to choose slightly smaller values). IMO, using this client is still in keeping with the spirit of the rally, since it's still dealing with the server normally, and the worst that can happen is a few results that may come in near the beginning of the rally that were crunched right before the rally, or some results crunched near the end of the rally being sent in right after it. However, that would probably even out pretty well overall.

(Just to clarify: I'm not insinuating that anyone said or implied anything about the batching LLRnet client being against the "spirit" of the rally, but I figured I'd mention that aspect of it in case it came up. )

Wow; no cable. You must live out in the boonies! lol

I see your issue and it sounds like you've done a good job of coming up with the best way around it.

Using the batching process is still in the spirit of the rally. The only way it wouldn't be is if someone abused it and did a bunch of pairs before the rally started and then "submitted" them shortly after it started. That's clearly not a problem here so it's all good!


Gary

[gd_barnes]

Originally Posted by Anonymous

(@Gary: How about I send an n=2.5K range to each of the C400 and L6 servers? I'm thinking that should be good enough to hold both servers for the duration of the rally, yet without making too much mess for us to clean up after the rally.)

As suggested in a PM, go ahead and send n=2K to those two servers. That should be sufficient. We'll monitor it after the first day of the rally.

[mdettweiler]

Originally Posted by gd_barnes

Wow; no cable. You must live out in the boonies! lol

I see your issue and it sounds like you've done a good job of coming up with the best way around it.

Now you see why I always do manual work whenever I'm out of town.

Using the batching process is still in the spirit of the rally. The only way it wouldn't be is if someone abused it and did a bunch of pairs before the rally started and then "submitted" them shortly after it started. That's clearly not a problem here so it's all good!


Gary

Another benefit of the batching clients: they reduce load on the servers by quite a reasonable amount. That's because instead of connecting to the server every 5 minutes or so (for my computer, at least), like the regular client, they connect only after every x workunits, so for my setup, that means once every 75 minutes.

Anyone who's interested in the batching clients can go here to see the PrimeGrid forum thread containing both the links to the clients for both Windows and Linux, as well as documentation on how the batching clients differ from the stock ones. (Also available are just the standalone LUA files that you can replace in a stock LLRnet setup to turn it into a batching client.)

[gd_barnes]

With no one committed specifically to IB400 for the rally, I'll put all 22 cores on that one late tonight after port 300 is complete to n=516K. If a heavy-hitter comes along and wants to put a lot of cores on it, I'll divide mine up or move them as needed.

[gd_barnes]

Based on the discussion here, I thought I'd comment on the intent of having NPLB rallies here.

First and most important is FUN FUN FUN!! Just to challenge yourself to see how much you can crunch with most of your resources dedicated to one effort is fun.

Second is to accomplish project goals. This is close to #1 in importance but without #1, we couldn't have #2. That's why it's #2.

Third and IMHO, the least important is the overall k/n pairs processed competition aspect. But it can add to the fun aspect a little bit if you have someone you're close to in # of cores.


On the 3rd reason for me, Carlos was a good incentive for me in the early rallies as for # of pairs processed. He had more firepower on the rallies than me but not a tremendous amount more. For the first rally, I had 4-5 connected work machines (out of 20 available) and 3-4 home cores for rallies. I upped it to 7 connected work machines (my max comfort level to stay under the radar at work) and was still a bit behind. I think after that he didn't bring quite as much firepower to the rallies and then later I bought the personal quads so it wasn't a reasonable comparison after that. The point of this is that having little mini-competitions amongst various searcher's of close to equal means is part of the fun.

Perhaps Anon, Flatlander, and Mini-Geek could compete in this rally. Do any of you have some old crappy slower machines you could add? Or is there a friend's machine you could use on it for a day or two? See who can do the most since all of you are bringing a 'base' of 2 cores.

[gd_barnes]

Originally Posted by Mini-Geek

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

Yep, I knew that. It's faster to post multiple times instead of multi-quote.

Someday we'll clean these threads up.

[mdettweiler]

Originally Posted by gd_barnes

Perhaps Anon, Flatlander, and Mini-Geek could compete in this rally. Do any of you have some old crappy slower machines you could add? Or is there a friend's machine you could use on it for a day or two? See who can do the most since all of you are bringing a 'base' of 2 cores.

Hmm...interesting idea. Of course, both Flatlander and I have 2 fast cores, whereas Mini-Geek has 2 somewhat slower cores, so that might make for a bit of an "unfair" advantage for Flatlander and I. I guess that might be somewhat compensated for, though, by the fact that my two primary cores are the full extent of what I can bring to the rally this time around. I don't know what Flatlander or Mini-Geek's situations are in regard to this.

Anon