![]() |
|
|
#100 |
|
Mar 2006
Germany
22×727 Posts |
i just arrived at home.
the AES-server get stuck two times this early morning on my two machines (a Quad and a P4) and both came back onself. about the stats and rally results: if i got all results then it's no problem to make a stats of all k/n-pairs of all included server. the only problem is the time zones: i think i will not display further the llrnet-pairs per hour. if so i had to recalculate/replace the server-submission-times and that's too much work to handle. perhaps for the rally it's ok then if i got all timezones for any server. preparing the stats-pages but i got today (and tomorrow too) not much time to do so. |
|
|
|
|
#101 | |
|
Mar 2006
Germany
55348 Posts |
Quote:
no problem at all! |
|
|
|
|
|
#102 | |
|
"Lennart"
Jun 2007
25·5·7 Posts |
Quote:
/Lennart |
|
|
|
|
|
#103 | |
|
May 2007
Kansas; USA
32·13·89 Posts |
Quote:
I'm running great with all 22 cores on port 400 now. Is anyone having any problems with port 300 now? Hopefully my pulling mine off of port 300 and Lennart running his personal server will ease the load enough that we will have no more issues there. The good news is that port 5000 (drive 3) got some significant work done this morning! Here is my thinking for future rally's and non-rally situations: Let's have any heavy-hitters, i.e. more than 25 cores, running port 400. All others run port 300. That is, let's have 2 servers on drive 1 at all times. I know it'll be more administrative work for us but I don't want this to happen again. Sometime we may lose searchers permanently if our servers don't work, even for a few hours. Bruce, when you get back, in your situation, I'd just suggest rebooting your machines. Don't fiddle with changing servers, which I know first-hand, takes quite a while for many machines. Port 300 should be fine without Lennart and me on it (and possibly others), which knocks off over 80 cores. To all who may be a little frustrated at the moment: I know it may seem easier to run manual reservation files but in the long run, LLRnet is much more convienient and faster if you have connected machines with a stable connection. We just have to get to the capacity that we need. Having 2 permanent servers, Ironbits of which should be very heavy duty, should resolve that problem now. Gary Last fiddled with by gd_barnes on 2008-05-24 at 20:15 |
|
|
|
|
|
#104 | |
|
A Sunny Moo
Aug 2007
USA (GMT-5)
3·2,083 Posts |
Quote:
So, as far as I'm concerned, if anyone wants to do manual LLR instead of LLRnet (at least during non-rally times), be my guest.
|
|
|
|
|
|
#105 |
|
A Sunny Moo
Aug 2007
USA (GMT-5)
3·2,083 Posts |
@Lennart: do you mind if others crunch on your server? I've got one core on it right now but can move it to IronBits' port 4 if you mind.
If you're OK with this, would you like us to change your reservation to show it as reserved by "LLRnet (L6)" (i.e. using our standard notation for reservations by public LLRnet server)? |
|
|
|
|
#106 |
|
Dec 2005
313 Posts |
300 server rejected results for:
k=927 n=444956 k=983 n=444962 ??? Just running the queues down now from the stuff that was loaded up last night. Still getting some hanging at times in trying to send in results on a few systems. Haven't refilled any queues since the second lockup cycle and do not intend to since I don't have the time to babysit. |
|
|
|
|
#107 | |
|
A Sunny Moo
Aug 2007
USA (GMT-5)
624910 Posts |
Quote:
![]() As for the rejected results: that happens sometimes if the k/n pair expires, gets reassigned, then the original assignee returns it before the reassignee returns it, in which case the reassignee's result will be refused. Nothing to worry about unless you're getting tons and tons of rejected results. Last fiddled with by mdettweiler on 2008-05-24 at 22:19 |
|
|
|
|
|
#108 | |
|
"Lennart"
Jun 2007
46016 Posts |
Quote:
No i have nothing against it just hook up. ![]() /Lennart |
|
|
|
|
|
#109 |
|
A Sunny Moo
Aug 2007
USA (GMT-5)
3×2,083 Posts |
|
|
|
|
|
#110 | |
|
May 2007
Kansas; USA
32·13·89 Posts |
Quote:
The down times in between finishing and starting new manual files always lost more CPU time for me than the slower LLR times for LLRnet. What piles up is idle CPU time. If we have the servers set up to handle the load, there should be zero idle CPU time for all of the people's cores who are connected. I remember before when I went on a trip, I would have to make sure I loaded enough manual work on ALL of ~30 cores. It was a lot of work, several hours worth. Now I just leave on the trip and don't worry about it. Gary |
|
|
|
![]() |
| Thread Tools | |
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Rally Jan. 23rd-25th | gd_barnes | No Prime Left Behind | 89 | 2009-01-25 22:59 |
| LLRnet server rally 400<k<1001 August 8-10 | mdettweiler | No Prime Left Behind | 66 | 2008-08-11 03:00 |
| LLRnet server rally 400<k<1001 June 20-22 | mdettweiler | No Prime Left Behind | 67 | 2008-06-23 15:32 |
| LLRnet server rally port 300 May 3rd-4th | gd_barnes | No Prime Left Behind | 45 | 2008-05-05 19:56 |
| LLRnet server rally March 8th-9th | gd_barnes | No Prime Left Behind | 135 | 2008-03-14 19:52 |