PrimeNet 5.0 Upgrade

[retina]

See attached.

[retina]

Originally Posted by S485122

Just look at the time on your display. You ran the query on the hour while the server was updating the files...

Nope, I accessed that page only ~5 minutes before posting it here. And I refreshed it a few times to make sure it was not a fluke. It stayed exactly like that each time so I reported it here.

[edit]
I tried it again just now and it is still messed up, although a little bit differently than before, but still not correct.

Hey, what happened to the post I quoted? Now it looks like I replied to a ghost.

[S485122]

I had posted without verifying. You were right. I was wrong. But I only realised that afterwards. So I deleted my post (this is possible during edit time.) But not quickly enough to prevent you from catching me :-(
Jacob

[starrynte]

Originally Posted by starrynte

Members Most Recent Activity Least Recently Activity 5 2008-10-25 20:09 2008-12-25 06:24

To clarify, 2008-10-25 is the "Most Recent Activity" and 2008-12-25 is the "Least Recently Activity"?

[Uncwilly]

I have noticed a problem with my user account report.
I have a machine with quite a few LMH numbers up in the 100Mdigit range. My report showed them as being assigned LL. I checked the worktodo.txt, there were no such LL's. I unreserved them from the webpage, now a different CPU's TF's are showing as LL's!

current example:

spudboy2 1 332198689  LL 0.00% 2008-10-05 16:08 82 2008-12-17 17:21 2009-01-14 17:21 2009-01-17 05:43 22 
spudboy2 1 332198809  LL 0.00% 2008-10-05 16:08 82 2008-12-17 17:21 2009-01-14 17:21 2009-01-17 20:19 22

[petrw1]

I have a Q9550: 3 cores doing LL and 1 core doing P-1.

When I click Test / Status... it literally takes 15 seconds to respond.
If I change it to running LL only Status... responds instantly.

On a related note the estimated completion dates for the LL tests change quite a bit when I stop the P-1 running and have all 4 cores on LL. About a day is ADDED (from Jan 1 to Jan 2 ... same hour) even though the per-iteration times actually drop slightly. The estimates are MORE accurate when P-1 is running on 1 core.

[starrynte]

Originally Posted by petrw1

When I click Test / Status... it literally takes 15 seconds to respond.
If I change it to running LL only Status... responds instantly.

Same here, though only about 8 seconds on my computer

[Prime95]

Originally Posted by petrw1

I have a Q9550: 3 cores doing LL and 1 core doing P-1.

When I click Test / Status... it literally takes 15 seconds to respond..

I presume P-1 is doing stage 2. I'd reduce the amount of memory prime95 is allowed to use. I'd guess its taking 15 seconds to page in a lot of stuff (both prime95 code as well as OS code and data).

[James Heinrich]

I have also seen something of this sluggishness on a couple of my systems. On my AMD X2 (currently a dedicated Prime95 rig for the rest of 2008) I've got it running P-1 in 1800MB of 2GB installed memory, so the entire OS is paged; any attempt to open menus or windows or such results in a churning of the HDD. That's easily understood. On my Q6600, if I structure my work assignments such that CPU usage stays at 100% then the system is sluggish, programs take a long time to load, videos don't play back smoothly, etc). If I stop a worker then everything is lightning fast (hooray for PauseWhileRunning!). If I structure the workload so it's somewhat inefficient and runs at 95% CPU load then responsiveness is pretty good.

I think your (petrw1) problem is probably a combination of both paging (if it's more of a problem in stage2 of P-1, and/or you're using a significant portion of your RAM for P-1), and memory bandwidth saturation. I believe (someone will doubtlessly correct me) in terms of bandwidth use, worktypes would rank P-1 (high), ECM (high), LL (medium), TF (low).

[ckdo]

Originally Posted by Prime95

I presume P-1 is doing stage 2. I'd reduce the amount of memory prime95 is allowed to use. I'd guess its taking 15 seconds to page in a lot of stuff (both prime95 code as well as OS code and data).

That's unlikely.

I have a Q6600 running mprime 25.8.4 (-m switch) which currently has 3000+ assignments, including 100+ P-1 ones.

I have that machine on manual communication. If I select to get the expected completion dates it takes a whopping 6 minutes, even right after startup (i.e. before any worker has been started). If comment out the P-1 assignments in worktodo.txt, it only takes a few seconds. qed.

What makes the situation worse is that with automatic communication the expected completion dates are recalculated whenever an assignment finishes, which is usually more often than those 6 minutes. That means the comm thread runs into an infinite loop - the "Done communicating with server" line does not appear for hours or even days unless you stop all workers, in which case it will appear said 6 minutes later.

This entire recalculation issue happens even with NoMoreWork=1. What's the point of calculating expected completion dates time and again unless you want to send them to the server, display them, or request more work?

To cut a long story short... had I not set ManualComm=1 the machine would recompute expected completion dates more or less 24/7, wasting half a core of crunching power in the process.

Some effort should be made to either speed up the calculation or at least make it happen less often. E.g. with DaysOfWork=90 there's no particular need to check whether more work needs to be reserved, every few minutes. Once a day should be more than enough, IMHO.

[petrw1]

Originally Posted by Prime95

I presume P-1 is doing stage 2. I'd reduce the amount of memory prime95 is allowed to use. I'd guess its taking 15 seconds to page in a lot of stuff (both prime95 code as well as OS code and data).

I'm pretty sure it is either stage but I could double check.
I have 2G allocated