Questions and stuff - Page 6

Brucifer · 2009-09-07, 17:07

@Gary/Max -- I fired off a couple of systems on the small primes last night. It looked to run normal on one machine on 3 of 4 cores. On the 4th core the count-up display was looking all screwed up, and running like a rocket ship. The time per itteration was like .02ms on the other 3 cores, so those things were running fast. So I tried it on a second system to see what it was like, and that one acted like the 4th core on the first system. So I shut the stuff off. I don't have a slow system to run the stuff on to see if it's going normal or not. But anyway you need to check your last night's results from "bruce".

mdettweiler · 2009-09-07, 18:00

Quote:

Originally Posted by Brucifer

@Gary/Max -- I fired off a couple of systems on the small primes last night. It looked to run normal on one machine on 3 of 4 cores. On the 4th core the count-up display was looking all screwed up, and running like a rocket ship. The time per itteration was like .02ms on the other 3 cores, so those things were running fast. So I tried it on a second system to see what it was like, and that one acted like the 4th core on the first system. So I shut the stuff off. I don't have a slow system to run the stuff on to see if it's going normal or not. But anyway you need to check your last night's results from "bruce".

What exactly do you mean by the count-up display "running like a rocket ship" on the 4th core? If the machines are Core 2 Quads, then the 4th core can be expected to have a little bit slower iteration time than the other three due to memory bottlenecking inherent in the design of the C2Q. Of course, if you meant something different, then that doesn't apply.

Brucifer · 2009-09-07, 23:11

you could watch the first three cores counting up through the .00 section of the count, but the 4th core didn't show the .00 count, it just counted up li 10.00%, 20.00%, 30.00% etc. Just accelerating through the tests way too fast compared to the first three cores.

mdettweiler · 2009-09-07, 23:18

Quote:

Originally Posted by Brucifer

you could watch the first three cores counting up through the .00 section of the count, but the 4th core didn't show the .00 count, it just counted up li 10.00%, 20.00%, 30.00% etc. Just accelerating through the tests way too fast compared to the first three cores.

Hmm...strange, indeed. However, I just thought of something: it might simply be that the first three cores were still doing work from the latter end of one k (near n=425K, where tests would take a while), whereas the last one was doing stuff near the beginning of the next k, near n=50K, which would be very small tests. For tests that small, I can easily see how things would be going so fast that the client doesn't even try to keep up with each and every 1% increment but rather updates in 10% increments.

kar_bon · 2009-09-08, 06:09

LLR(net) doing a test in 10000 iterations per screen output by default.

so for port GB8000 (where n~1M) every 10000 it. will display in about 1% steps.

at n~100k this would be 10% per step.

check the n-range for every core (see lresults.txt).

gd_barnes · 2009-09-08, 09:33

Quote:

Originally Posted by mdettweiler

Hmm...strange, indeed. However, I just thought of something: it might simply be that the first three cores were still doing work from the latter end of one k (near n=425K, where tests would take a while), whereas the last one was doing stuff near the beginning of the next k, near n=50K, which would be very small tests. For tests that small, I can easily see how things would be going so fast that the client doesn't even try to keep up with each and every 1% increment but rather updates in 10% increments.

It would be near n=250K not n=425K.

gd_barnes · 2009-09-08, 09:36

Quote:

Originally Posted by Brucifer

you could watch the first three cores counting up through the .00 section of the count, but the 4th core didn't show the .00 count, it just counted up li 10.00%, 20.00%, 30.00% etc. Just accelerating through the tests way too fast compared to the first three cores.

As Max implied, I'm sure this is OK. The timing difference between the smallest and largest exponent for the 12th drive (port G7000) is fairly extreme. A test at the high end of the range should take about 25 times as long as a test at the low end of the range. I'm fairly certain that you just happened to encounter a change in k-value amongst the cores.

Give it another shot. If the same thing happens, wait about half an hour and check it again. All cores should have about the same timings at that point.

Gary

vaughan · 2009-10-12, 03:11

Can anyone explain what happened to the stats yesterday?

Over the last few days bok's stats have shown my results:
Oct 11. . . .Oct 10. . . .Oct 9. . . . .Oct 8. . . . .Oct 7. . . . .Oct 6. . . .Oct 5
21,470. . . .12,276. . . .16,889. . . .16,001. . . .16,464. . . .16,809. . . .17,454

Why was Oct 10 so low and Oct 11 hasn't even finished yet?

kar_bon · 2009-10-12, 04:12

those stats from FreeDC project NPLB will not updated constantly every full hour and the timezone is different to the NPLB-stats page.

so when that page updates at say 03:00 AM but not for the last 5 hours, the points from 2 hours will be shown at the new day!

AMDave · 2009-10-14, 11:52

Because sometimes another errant non-BOINC project causes the non-BOINC updater to get stuck and Bok has to kick it hard in butt with a steel capped boot.

So, you are seeing several updates during the day on Oct 10, then the errant project hangs the updater ... until it feels the pain of the size 12 1/2 steel capped boot in the butt. In the mean time, the stats roll-over occurred so any new updates are recorded against the next day, 11 Oct. So the next time the stats updater picks up you NPLB stats, it doesn't play a game of catch-up but goes straight for the win and grabs your latest total (as it does for every observation). The increase gets recorded against the date of 11 Oct and so do the rest of your updates for 11 Oct which results in a higher than average score, but is the exact offset of the increases that were missed on the previous day.

so...it is a time based observation with a frequency greater than once per 24 hours. Hence the drop and the spike when the updater gets stuck and 'punted' either side of the rollover.

Hope that helps.

MyDogBuster · 2009-10-29, 08:24

Anyone happen to know where Geoff Reynolds and SR2Sieve are hanging out now?

This link is no longer valid.

http://www.geocities.com/g_w_reynolds/sr2sieve/

2009-10-12, 03:11	#63
vaughan Jan 2005 Sydney, Australia 517₈ Posts	Can anyone explain what happened to the stats yesterday? Over the last few days bok's stats have shown my results: Oct 11. . . .Oct 10. . . .Oct 9. . . . .Oct 8. . . . .Oct 7. . . . .Oct 6. . . .Oct 5 21,470. . . .12,276. . . .16,889. . . .16,001. . . .16,464. . . .16,809. . . .17,454 Why was Oct 10 so low and Oct 11 hasn't even finished yet? Last fiddled with by vaughan on 2009-10-12 at 03:15 Reason: spacing

2009-10-12, 04:12	#64
kar_bon Mar 2006 Germany 2,999 Posts	those stats from FreeDC project NPLB will not updated constantly every full hour and the timezone is different to the NPLB-stats page. so when that page updates at say 03:00 AM but not for the last 5 hours, the points from 2 hours will be shown at the new day! Last fiddled with by kar_bon on 2009-10-12 at 04:13

2009-10-14, 11:52	#65
AMDave Jan 2006 deep in a while-loop 2²·167 Posts	Because sometimes another errant non-BOINC project causes the non-BOINC updater to get stuck and Bok has to kick it hard in butt with a steel capped boot. So, you are seeing several updates during the day on Oct 10, then the errant project hangs the updater ... until it feels the pain of the size 12 1/2 steel capped boot in the butt. In the mean time, the stats roll-over occurred so any new updates are recorded against the next day, 11 Oct. So the next time the stats updater picks up you NPLB stats, it doesn't play a game of catch-up but goes straight for the win and grabs your latest total (as it does for every observation). The increase gets recorded against the date of 11 Oct and so do the rest of your updates for 11 Oct which results in a higher than average score, but is the exact offset of the increases that were missed on the previous day. so...it is a time based observation with a frequency greater than once per 24 hours. Hence the drop and the spike when the updater gets stuck and 'punted' either side of the rollover. Hope that helps. Last fiddled with by AMDave on 2009-10-14 at 11:54

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Some old stuff	Batalov	Miscellaneous Math	1	2017-01-27 04:56
Stuff for sale	fivemack	Lounge	12	2011-06-12 11:28
useful stuff	paulunderwood	Linux	3	2005-12-05 22:18
Free stuff...	Xyzzy	Software	6	2004-10-06 13:35
Extra Stuff...	Xyzzy	Lounge	11	2003-09-15 23:22

2009-09-07, 17:07	#56
Brucifer Dec 2005 313 Posts	@Gary/Max -- I fired off a couple of systems on the small primes last night. It looked to run normal on one machine on 3 of 4 cores. On the 4th core the count-up display was looking all screwed up, and running like a rocket ship. The time per itteration was like .02ms on the other 3 cores, so those things were running fast. So I tried it on a second system to see what it was like, and that one acted like the 4th core on the first system. So I shut the stuff off. I don't have a slow system to run the stuff on to see if it's going normal or not. But anyway you need to check your last night's results from "bruce".

2009-09-07, 23:11	#58
Brucifer Dec 2005 100111001₂ Posts	you could watch the first three cores counting up through the .00 section of the count, but the 4th core didn't show the .00 count, it just counted up li 10.00%, 20.00%, 30.00% etc. Just accelerating through the tests way too fast compared to the first three cores.

2009-09-08, 06:09	#60
kar_bon Mar 2006 Germany 2,999 Posts	LLR(net) doing a test in 10000 iterations per screen output by default. so for port GB8000 (where n~1M) every 10000 it. will display in about 1% steps. at n~100k this would be 10% per step. check the n-range for every core (see lresults.txt).

2009-10-29, 08:24	#66
MyDogBuster May 2008 Wilmington, DE 2²×23×31 Posts	Anyone happen to know where Geoff Reynolds and SR2Sieve are hanging out now? This link is no longer valid. http://www.geocities.com/g_w_reynolds/sr2sieve/