Thanks, here's the data for completed WU's in RR format ( all designated as S5R5a )
[pre]
983.25, 1309, 23211.3
983.25, 1310, 23171.38
983.25, 1311, 23147.78
983.25, 1312, 23026.88
983.25, 1313, 23415.33
983.25, 1314, 23133.11
983.25, 1315, 23241.97
983.25, 1316, 23284.63
983.25, 1317, 20128.34
[/pre]
but thus far are too close in phase ( 0.602 - 0.630 ) to yield an estimate with RR V7G, yet. However I'll watch this machine as it is churning well and has 1301 thru 1308 pending for this frequency ( cycle period 284.5 ).
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
My Windows XP host 1226365 has completed three S5R5 tasks, and is still showing a good selection of S5R4 v6.10 work. More S5R5 will be available for scrutiny in the morning. I'll try and write up some logs tomorrow, but you can start looking at the raw data now (and maybe save me a job!).
I've been pretty busy converting my fleet mid-cache so that they could start receiving R5 before they had completed the on-board R4 work. That was quite an effort that required surgery on every single host's state file. That is all completed but I don't have much R5 work done as yet because many of the hosts have continued to get R4 work. Not so much in the way of first time R4 tasks - they have essentially dried up - but moreso in the way of R4 resends! They have been becoming more prolific as the days have passed. Maybe a lot of people simply aborted their old R4 work so as to get some new R5.
In fact the very last machine I converted was down to its last R4 task and had been getting refused for new R4 work for a couple of days. Immediately the conversion was finished, I expected it to get R5 work straight away but upon restarting BOINC and enabling work fetch, it received a bunch of R4 resends complete with new large data files. It had been working on a 103x.xx frequency band so I knew there would be a complete change in frequency since there are no R5 tasks over 1000Hz at the moment. I was expecting a much lower frequency so was quite surprised when 119x.xx data started arriving with the R4 resend tasks. I was curious to see how much work there was so I increased my cache in stages and ended up with 10 days worth of R4 resends before finally getting an R5 task.
I have noticed on other machines that have been getting R5 new tasks for a while, that quite frequently R4 resends will come along as well.
Now that I've got a bit more time, I've dusted off my data gathering shell script and Bikeman's awk script and tried them out on R5. I needed to edit Bikeman's script for R5 but my shell script seems to be working OK.
So here is the data from Richard's host so far, suitable for feeding into Mike Hewson's RR. The CSV data is Frequency, Sequence#, Crunch time, App Version.
I decided to include this data as well because it shows the two expected features of R5, firstly that crunch times will be a lot less and secondly that there will be larger swings between peaks and troughs. That certainly seems to be the case with this initial set of results.
Thanks Gary - I was away for the weekend, and I've been busy since I got back. Just beginning to think I should start scraping data before it starts to purge, and there is it ready for me. Brilliant.
As this machine is actually used by two people for web browsing and document composition, it is possible that a difference in the state of those activities accounts for this (or maybe I just flubbed graph-making). But it would be interesting if others see such an effect.
Quite useful data, here are graphs for the S5R4 data
Min frequency in data : 748.20
Max frequency in data : 748.50
Min predicted runtime : 22220
Min observed runtime : 21665
Max predicted runtime : 26583
Max observed runtime : 26754
Rel. predicted runtime variation: 1.196
Mean predicted runtime : 23674
and for the S5R5 datapoints
Min frequency in data : 748.70
Max frequency in data : 749.60
Min predicted runtime : 12235
Min observed runtime : 12140
Max predicted runtime : 20138
Max observed runtime : 20518
Rel. predicted runtime variation: 1.646
Mean predicted runtime : 14870
The S5R5 datapoints are far more unregular, not surprising as there are now far fewer skypoints per WU to average out variations in runtime for individual skypoints.
Quite useful data, here are graphs for the S5R4 data ...
and for the S5R5 datapoints ...
As you say, quite interesting. If you look at the S5R5 plot in the top right corner where there is a high density of points, you can see several (at least 5) groups of points that follow a straight line relatively close to parallel to the average line you have included. I haven't checked but this suggests to me that each separate frequency sub-band has a slightly different performance, some a bit quicker than average and some a bit slower. I'm assuming that a set of points clearly on their own particular straight line all belong to a single frequency.
EDIT: Is it possible to colour code the plotted points according to frequency?
Thanks.
EDIT: Is it possible to colour code the plotted points according to frequency?
Thanks.
Don't know how to do it in octave, but then there's TOPCAT as well :-)
Thanks very much for doing that! As seemed likely, there are a number of results of single frequency (colour) that fall on mini straight line segments. Then there are others that decidedly don't. For example, there are two frequencies that plot as red, 748.70Hz and 749.60. There are twelve points in total and a lot of scatter in the crunch times. No real order to those values.
In the bottom left corner there are a whole range of magenta points which must all be 749.50Hz. The seq#s are all heading down towards a trough but the crunch times show a huge variation, from just over 12ksecs to nearly 18Ksecs. I guess it must be just about impossible to come up with an algorithm for assigning fair credit with such a huge variation.
Hi! For statistics: My
)
Hi!
For statistics: My host 1275368 with S5R5 tasks.
RE: Hi! For statistics: My
)
Thanks, here's the data for completed WU's in RR format ( all designated as S5R5a )
[pre]
983.25, 1309, 23211.3
983.25, 1310, 23171.38
983.25, 1311, 23147.78
983.25, 1312, 23026.88
983.25, 1313, 23415.33
983.25, 1314, 23133.11
983.25, 1315, 23241.97
983.25, 1316, 23284.63
983.25, 1317, 20128.34
[/pre]
but thus far are too close in phase ( 0.602 - 0.630 ) to yield an estimate with RR V7G, yet. However I'll watch this machine as it is churning well and has 1301 thru 1308 pending for this frequency ( cycle period 284.5 ).
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
It seems that ATLAS has
)
It seems that ATLAS has rejoined E@H and there should be many useful results to analyse there .
CU
Bikeman
RE: My Windows XP host
)
I've been pretty busy converting my fleet mid-cache so that they could start receiving R5 before they had completed the on-board R4 work. That was quite an effort that required surgery on every single host's state file. That is all completed but I don't have much R5 work done as yet because many of the hosts have continued to get R4 work. Not so much in the way of first time R4 tasks - they have essentially dried up - but moreso in the way of R4 resends! They have been becoming more prolific as the days have passed. Maybe a lot of people simply aborted their old R4 work so as to get some new R5.
In fact the very last machine I converted was down to its last R4 task and had been getting refused for new R4 work for a couple of days. Immediately the conversion was finished, I expected it to get R5 work straight away but upon restarting BOINC and enabling work fetch, it received a bunch of R4 resends complete with new large data files. It had been working on a 103x.xx frequency band so I knew there would be a complete change in frequency since there are no R5 tasks over 1000Hz at the moment. I was expecting a much lower frequency so was quite surprised when 119x.xx data started arriving with the R4 resend tasks. I was curious to see how much work there was so I increased my cache in stages and ended up with 10 days worth of R4 resends before finally getting an R5 task.
I have noticed on other machines that have been getting R5 new tasks for a while, that quite frequently R4 resends will come along as well.
Now that I've got a bit more time, I've dusted off my data gathering shell script and Bikeman's awk script and tried them out on R5. I needed to edit Bikeman's script for R5 but my shell script seems to be working OK.
So here is the data from Richard's host so far, suitable for feeding into Mike Hewson's RR. The CSV data is Frequency, Sequence#, Crunch time, App Version.
I had tested things out using one of my hosts that had done a bit of R5 work, It's an old AMD64 3800+ dual core.
I decided to include this data as well because it shows the two expected features of R5, firstly that crunch times will be a lot less and secondly that there will be larger swings between peaks and troughs. That certainly seems to be the case with this initial set of results.
Cheers,
Gary.
Thanks Gary - I was away for
)
Thanks Gary - I was away for the weekend, and I've been busy since I got back. Just beginning to think I should start scraping data before it starts to purge, and there is it ready for me. Brilliant.
As with most of us, my hosts
)
As with most of us, my hosts seemed to draw a rather thin mix of work very near cycle peaks at first. So I did not make any graphs or do other work.
Just now I took another look, and saw that two hosts have seen work appreciably away from cycle peak.
The execution times drop considerably, but on first look I'm getting much more like a cloud than a nice pretty clean curve.
Here is all the 3.01 available for my premium host, a Q9550 running stock.
By contrast, here is late-season 6.05 from the same host, at the same settings
As this machine is actually used by two people for web browsing and document composition, it is possible that a difference in the state of those activities accounts for this (or maybe I just flubbed graph-making). But it would be interesting if others see such an effect.
Quite useful data, here are
)
Quite useful data, here are graphs for the S5R4 data
and for the S5R5 datapoints
The S5R5 datapoints are far more unregular, not surprising as there are now far fewer skypoints per WU to average out variations in runtime for individual skypoints.
CU
Bikeman
RE: Quite useful data, here
)
As you say, quite interesting. If you look at the S5R5 plot in the top right corner where there is a high density of points, you can see several (at least 5) groups of points that follow a straight line relatively close to parallel to the average line you have included. I haven't checked but this suggests to me that each separate frequency sub-band has a slightly different performance, some a bit quicker than average and some a bit slower. I'm assuming that a set of points clearly on their own particular straight line all belong to a single frequency.
EDIT: Is it possible to colour code the plotted points according to frequency?
Thanks.
Cheers,
Gary.
RE: EDIT: Is it possible
)
Don't know how to do it in octave, but then there's TOPCAT as well :-)
RE: RE: EDIT: Is it
)
Thanks very much for doing that! As seemed likely, there are a number of results of single frequency (colour) that fall on mini straight line segments. Then there are others that decidedly don't. For example, there are two frequencies that plot as red, 748.70Hz and 749.60. There are twelve points in total and a lot of scatter in the crunch times. No real order to those values.
In the bottom left corner there are a whole range of magenta points which must all be 749.50Hz. The seq#s are all heading down towards a trough but the crunch times show a huge variation, from just over 12ksecs to nearly 18Ksecs. I guess it must be just about impossible to come up with an algorithm for assigning fair credit with such a huge variation.
Cheers,
Gary.