And yet, having just reported my first S5R4 result with host 889490, the real-world WU timing is much longer than S5R3.
I'm comparing Windows 4.36 on Intel (between 23 and 25.5 Ksec) with 6.04 - which should be a functionally equivalent Einstein app, but registered over 48 Ksec.
It strikes me that with the DCF re-adjustment, fast hosts will over-cache when they first latch on to S5R4, but will then go quiet as soon as they return their first task and find out what they've let themselves in for. But the initial loading is likely to be nice and consecutive, as this one was.
Anyone like me to try for a 'wiggle and swoop' run with one of my standard quaddies, like we did last time?
No quaddie here :-(, but that should be instructive.
As to CPU time per Workunit: the WUs seem to contain "more science" per unit. As I understand this, the stretch of observation time (a segment of the S5 LIGO science run) that is covered in S5R4 is longer than in S5R3, and basically every workunit looks at the complete stretch of time, but only for a small frequency window.
CU
Bikeman
OK, I'll start prepping up host 1001562 - the one we used last time. Got a bit of a cache to flush off first - not least, an Astropulse task which has only just started and has still got ~40 hours to run. So it'll be Friday before you see me start grabbing for S5R4.
But if we're doing that much more science (almost double, according to that single datum), doesn't it make a mockery of the credit adjustment?
Edit - meant to report that that first S5R4 result upped the host's RDCF from 0.216881 to 1.586961
I got a few S5R3 resends, but I sent them to the back of the class while we focus on S5R4.
The timing run is on frequency 0256.50 - I've got consecutive tasks from __16 to __0 inclusive. Haven't checked yet how far from the minimum I'm starting, but at least we have a definite maximum to pin the results to.
Charts will appear in HostID 1001562 - Richard Haselgrove's Q6600 Quad Core - please use that thread for discussion too. I've reset DCF to 1.000000, and I'm showing 6:40 estimated time - expect the first results on Sunday afternoon/evening, UK time.
If you prefer "pencil and paper" to check whether a certain WU is a "fast" or "slow" one, the following PDF file I created might be useful to print out:
It works like this:
The WU name (e.g. h1_0220.25_S5R4__55_S5R4a) indicates a certain frequency and jobnumber, here: 220.25 Hz and job # 55
You just have to lookup the line in the linked file where this frequency lies between the values in the first and second column. The value in the third column will then give you a pretty good approximation of the "period" of the runtime variation.
In this case, the matching line is
219.90 229.85 16
So the period is 16. Now divide the jobnumber by this period and look at the fractional part :
55 / 16 = 3.4375
Values near 0.5 indicate a runtime minimum, where values near 0 and 1.0 indicate runtime maxima.
If you prefer "pencil and paper" to check whether a certain WU is a "fast" or "slow" one ................ So in this example the WU should be pretty fast.
Now that's what I call a true Ready Reckoner! :-)
It nicely summarises the effects discussed, particularly the 10Hz step thingy. One could envision that in a "wheel" format too! [ It's the period varying from 1 to 300 across the WU's that has confounded my analysis of the "wiggles" near the minima. Having a 'discrete' transform on a 'smooth' curve doesn't help either .... ]
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Quick update ;
Add of Windows apps compiled with gcc (6.06).
Note : Slight glitch as the system switched from XP SP1 to XP SP3 before adding 6.06. When comparing to previous results on 6.04, SP3 runs seems to be around 1% faster than SP1 ones.
Will re-run everything ASAP under the exact same conditions.
Cheers,
Alex.
God created a few good looking guys.. and for the rest he put hairs on top..
RE: RE: And yet, having
)
OK, I'll start prepping up host 1001562 - the one we used last time. Got a bit of a cache to flush off first - not least, an Astropulse task which has only just started and has still got ~40 hours to run. So it'll be Friday before you see me start grabbing for S5R4.
But if we're doing that much more science (almost double, according to that single datum), doesn't it make a mockery of the credit adjustment?
Edit - meant to report that that first S5R4 result upped the host's RDCF from 0.216881 to 1.586961
OK, timing run is under way
)
OK, timing run is under way on host 1001562.
I got a few S5R3 resends, but I sent them to the back of the class while we focus on S5R4.
The timing run is on frequency 0256.50 - I've got consecutive tasks from __16 to __0 inclusive. Haven't checked yet how far from the minimum I'm starting, but at least we have a definite maximum to pin the results to.
Charts will appear in HostID 1001562 - Richard Haselgrove's Q6600 Quad Core - please use that thread for discussion too. I've reset DCF to 1.000000, and I'm showing 6:40 estimated time - expect the first results on Sunday afternoon/evening, UK time.
Hi! If you prefer "pencil
)
Hi!
If you prefer "pencil and paper" to check whether a certain WU is a "fast" or "slow" one, the following PDF file I created might be useful to print out:
Freq_to_period.pdf.
It works like this:
The WU name (e.g. h1_0220.25_S5R4__55_S5R4a) indicates a certain frequency and jobnumber, here: 220.25 Hz and job # 55
You just have to lookup the line in the linked file where this frequency lies between the values in the first and second column. The value in the third column will then give you a pretty good approximation of the "period" of the runtime variation.
In this case, the matching line is
219.90 229.85 16
So the period is 16. Now divide the jobnumber by this period and look at the fractional part :
55 / 16 = 3.4375
Values near 0.5 indicate a runtime minimum, where values near 0 and 1.0 indicate runtime maxima.
So in this example the WU should be pretty fast.
CU
Bikeman
RE: If you prefer "pencil
)
Now that's what I call a true Ready Reckoner! :-)
It nicely summarises the effects discussed, particularly the 10Hz step thingy. One could envision that in a "wheel" format too! [ It's the period varying from 1 to 300 across the WU's that has confounded my analysis of the "wiggles" near the minima. Having a 'discrete' transform on a 'smooth' curve doesn't help either .... ]
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Thanks Bikeman, That
)
Thanks Bikeman,
That "pencil and paper" ready reckoner does the job very well.
Andy
Quick update ; Add of
)
Quick update ;
Add of Windows apps compiled with gcc (6.06).
Note : Slight glitch as the system switched from XP SP1 to XP SP3 before adding 6.06. When comparing to previous results on 6.04, SP3 runs seems to be around 1% faster than SP1 ones.
Will re-run everything ASAP under the exact same conditions.
Cheers,
Alex.
God created a few good looking guys.. and for the rest he put hairs on top..