( edit ) Here's an example ( thanks to archae86 ) of where the analysis wobbles off, by the points straying from ~ sinusoidal pattern :
....
What happened there? You may well ask .... :-)
I haven't plotted the points but I can see exactly what you are referring to :).
Something happened probably during or around seq# 40 which gave a step improvement of close to 10% in crunching performance. Could it have been an app change to a faster app or could it have been hardware improvements like upping the overclock a bit :). Maybe Peter might have some thoughts on this.
It appears to be the version 4.07 to 4.11 upgrade. I no longer recall whether that was seen as a speed upgrade at the time or not, but the files show that the very next results after the ones Mike shows are labelled as 4.11, and these as 4.07.
I maintain a bit of a queue, and the data I sent to Mike are collected by BoincLogX, which uses the "branding" at download time, not the more sophisticated scanning of stderr out used by methods posted here recently.
So, in my raw data, not only are "mixed" results right at the conversion boundary mislabelled, but also any results already downloaded at conversion time.
As noted in the "Power Users" thread (Windows), I'm dedicating host 1001562 to a timing run with 4.32 - all tasks at 0909.15Hz will be crunched exclusively with 4.32: host is a Q6600 at stock 2.4GHz, other projects will be suspended for the duration. I'm starting at sequence number 502 - let's see how far this one will go! Feel free to use this as a data source for Gary's script - I'll have to do the data collection manually, not having a Linux box to hand. Just got three sub-800 Einsteins to finish off first, and some SETI, but we should be in full flow by the morning.
I'll have to do the data collection manually, not having a Linux box to hand.
If you like, I'll collect it for you and email it to you. Just as an example, this is what the data for that machine currently looks like on the website:-
What do you think? Does it all look OK? I'm sure Mike will be interested in this string of results anyway :-).
Yep & it's a nice curve fit! I think I might relax about having to jazz up the algorithm [ to a least squares fit using a Taylor polynomial approximation of sine ] - whew! :-)
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
Number of point pairs used = 10
Minimum runtime in data = 26242.63
Maximum runtime in data = 27318.17
Estimated peak runtime = 27968
Estimated average runtime = 24727
Estimated trough runtime = 22877
Estimated runtime variance = 0.182
Estimated error = 2.6 %
That's looking much lumpier than my previous graph - we'll have to see how it develops over time. Even at under 7 hr 30 min per task, I'm not quite keeping up with the competition, so the downloads have skipped a couple of sequence numbers - but I've got to 475 in cache at the same frequency.
If you like, I'll collect it for you and email it to you.
Thanks. At about 13 or 14 tasks per day, I should be able to keep up with it manually, but it would be good if you could monitor it as a backup.
I'll try to post a daily update in case you get sick of doing it manually and also for the benefit of anyone else interested in your progress.
Quote:
The first ten results are through:
Mike's RR6A renders that as:
Number of point pairs used = 10
Minimum runtime in data = 26242.63
Maximum runtime in data = 27318.17
Estimated peak runtime = 27968
Estimated average runtime = 24727
Estimated trough runtime = 22877
Estimated runtime variance = 0.182
Estimated error = 2.6 %
That's looking much lumpier than my previous graph - we'll have to see how it develops over time...
I'm sure you realise that your range of seq#s is very small compared to the period of the cycle so you are really taxing the ability of RR and because it only chose to use 10 point pairs, it obviously threw away as unusable, many others. Once you get to seq#s that are 100 or more below what you started at you will see much better output from RR.
I'm sure you realise that your range of seq#s is very small compared to the period of the cycle so you are really taxing the ability of RR and because it only chose to use 10 point pairs, it obviously threw away as unusable, many others. Once you get to seq#s that are 100 or more below what you started at you will see much better output from RR.
This is one of the first I've tried for RR over 900 Hz. I think I'll bite the bullet and do the least squares route, have a play and see whether it is superior to the simpler algorithm presently used. It ought be much less sensitive to problems of close sequence numbers ( phase ). So far, with people's data ( thank you all! ) certainly task groups in narrow bands of phase/sequence seem to be routinely allocated for a given host - so it will be a common question to solve. Also with the least squares methodology one can choose/apply 'weightings' in a fashion that can limit 'the close phase effect' on sine curve matching .... make the weighting inversely proportional to phase difference say and hence suppress that difficulty without having to cull data completely.
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
RE: RE: ( edit ) Here's
)
It appears to be the version 4.07 to 4.11 upgrade. I no longer recall whether that was seen as a speed upgrade at the time or not, but the files show that the very next results after the ones Mike shows are labelled as 4.11, and these as 4.07.
I maintain a bit of a queue, and the data I sent to Mike are collected by BoincLogX, which uses the "branding" at download time, not the more sophisticated scanning of stderr out used by methods posted here recently.
So, in my raw data, not only are "mixed" results right at the conversion boundary mislabelled, but also any results already downloaded at conversion time.
As noted in the "Power Users"
)
As noted in the "Power Users" thread (Windows), I'm dedicating host 1001562 to a timing run with 4.32 - all tasks at 0909.15Hz will be crunched exclusively with 4.32: host is a Q6600 at stock 2.4GHz, other projects will be suspended for the duration. I'm starting at sequence number 502 - let's see how far this one will go! Feel free to use this as a data source for Gary's script - I'll have to do the data collection manually, not having a Linux box to hand. Just got three sub-800 Einsteins to finish off first, and some SETI, but we should be in full flow by the morning.
RE: I'll have to do the
)
If you like, I'll collect it for you and email it to you. Just as an example, this is what the data for that machine currently looks like on the website:-
The top 2 entries in the above list are the ones that were started with 4.26 and finished with 4.32.
What do you think? Does it all look OK?
I'm sure Mike will be interested in this string of results anyway :-).
Cheers,
Gary.
RE: What do you think?
)
Yep & it's a nice curve fit! I think I might relax about having to jazz up the algorithm [ to a least squares fit using a Taylor polynomial approximation of sine ] - whew! :-)
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
RE: As promised, here are
)
Thanks to both Gary and Bikeman. I've been slowly learning shell scripting (I'm in my infancy) and the more examples I can see, the better.
Kathryn :o)
Einstein@Home Moderator
Tried somebody to fit the
)
Tried somebody to fit the curve of the runtimes with Origin? Wich function can I use for fiting? I used the "Sine" function and it looks quite good.
RE: Tried somebody to fit
)
Check the discussion in this thread
RE: RE: I'll have to do
)
Thanks. At about 13 or 14 tasks per day, I should be able to keep up with it manually, but it would be good if you could monitor it as a backup.
The first ten results are through:
Mike's RR6A renders that as:
Number of point pairs used = 10
Minimum runtime in data = 26242.63
Maximum runtime in data = 27318.17
Estimated peak runtime = 27968
Estimated average runtime = 24727
Estimated trough runtime = 22877
Estimated runtime variance = 0.182
Estimated error = 2.6 %
That's looking much lumpier than my previous graph - we'll have to see how it develops over time. Even at under 7 hr 30 min per task, I'm not quite keeping up with the competition, so the downloads have skipped a couple of sequence numbers - but I've got to 475 in cache at the same frequency.
RE: RE: If you like, I'll
)
I'll try to post a daily update in case you get sick of doing it manually and also for the benefit of anyone else interested in your progress.
I'm sure you realise that your range of seq#s is very small compared to the period of the cycle so you are really taxing the ability of RR and because it only chose to use 10 point pairs, it obviously threw away as unusable, many others. Once you get to seq#s that are 100 or more below what you started at you will see much better output from RR.
Cheers,
Gary.
RE: I'm sure you realise
)
This is one of the first I've tried for RR over 900 Hz. I think I'll bite the bullet and do the least squares route, have a play and see whether it is superior to the simpler algorithm presently used. It ought be much less sensitive to problems of close sequence numbers ( phase ). So far, with people's data ( thank you all! ) certainly task groups in narrow bands of phase/sequence seem to be routinely allocated for a given host - so it will be a common question to solve. Also with the least squares methodology one can choose/apply 'weightings' in a fashion that can limit 'the close phase effect' on sine curve matching .... make the weighting inversely proportional to phase difference say and hence suppress that difficulty without having to cull data completely.
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