There is no need for movies. From the data, a JavaScript application can show the same animation by using canvas. Since the application can be cached in the Web browser, only the data will need to be downloaded, so the bandwidth to reproduce the animation will be small.

[QUOTE=LaurV;410884]Edit: I don't think Chris is upset about this discussion at all, it is connected to GPu72 and Gimps Visu anyhow.[/QUOTE]

Absolutely. To the contrary, I'm very thankful to James for undertaking this.

I had hoped to have had the cycles to fix this myself, but I've recently learnt (the hard way) that "snagging" (read: finishing to completion) two houses' construction takes way more time that you might expect! (Damn Humans! Damn Atoms! :wink:)

[QUOTE=alpertron;410902]There is no need for movies. From the data, a JavaScript application can show the same animation by using canvas. Since the application can be cached in the Web browser, only the data will need to be downloaded, so the bandwidth to reproduce the animation will be small.[/QUOTE]

An excellent idea!

I had used the videos as a "test bed" for HTML5 video, but what you suggest would eliminate the heavy server-side processing, and pass the load onto the client. Perfect for data-driven videos.

[QUOTE=snme2pm1;410877]Something doesn't feel right in the propagation of the date specific qualification.
The algorithm seems too quick to introduce an absolute date.[/QUOTE]I have spent the afternoon reworking the GUI. Hopefully it now makes use of more sensible URLs with relative or absolute date comparisons for your convenience.

On the flip side, it's pretty likely I've broken something and not noticed it, so please let me know what it is and I'll try and fix it :smile:


PS: as for graphs, they're on my to-do-soon list. I'll try and include an option for animation as well (guaranteed not to work for [i]retina[/i] :whistle:)

[QUOTE=James Heinrich;410917]I have spent the afternoon reworking the GUI. Hopefully it now makes use of more sensible URLs with relative or absolute date comparisons for your convenience.

On the flip side, it's pretty likely I've broken something and not noticed it, so please let me know what it is and I'll try and fix it :smile:


PS: as for graphs, they're on my to-do-soon list. I'll try and include an option for animation as well (guaranteed not to work for [i]retina[/i] :whistle:)[/QUOTE]

I see the new GUI menu and I like it....however now when I click on a row in the table to zoom it does NOT zoom in fact it goes back to 0 - 900M.

[QUOTE=petrw1;410967]I see the new GUI menu and I like it....however now when I click on a row in the table to zoom it does NOT zoom in fact it goes back to 0 - 900M.[/QUOTE]Indeed. Thanks. Fixed.
I also uploaded the missing .js file for the calendar for picking specific dates.

[Feature Suggestion] "Cyclic Cooldown"
 

I have a suggestion for a feature for a future iteration of Prime95: "Cyclic Cooldown".

Basically, an option to, say, tell Prime95 to periodically stop the threads to give time for the machine to cool down. I'm not sure how practical it is to obtain the CPU temperature using assembly language, especially something that doesn't require high privileges, but the idea is that the feature will still allow you to run Prime95 on machines that are prone to overheating.

My own case in point: I once acquired a netbook that I tried to run Prime95 on, but after around 10 to 15 minutes, the machine forcefully turned itself off because it overheated, and the only way I could get around it was to play with the system settings to slow the CPU down. But would it be feasible to have a feature where you can have the worker threads running for 5 to 10 minutes (configurable), and then do a full stop for another 5 to 10 minutes (also configurable, so you can tailor the times if you know your machine well) so the machine can cool down, before starting again. Obviously it means the tests can take twice as long, but at least it can do [I]something[/I] without shutting off without having a chance to save etc, and can be left unattended.

Of course, the best solution would be periodic monitoring of the CPU core temperature and shutting down the worker threads if it reaches an upper threshold, and not starting up again until it cools below a lower threshold, but I'm not sure how practical that is.

[QUOTE=CuriousKit;410973]I have a suggestion for a feature for a future iteration of Prime95: "Cyclic Cooldown".

Basically, an option to, say, tell Prime95 to periodically stop the threads to give time for the machine to cool down. I'm not sure how practical it is to obtain the CPU temperature using assembly language, especially something that doesn't require high privileges, but the idea is that the feature will still allow you to run Prime95 on machines that are prone to overheating.

My own case in point: I once acquired a netbook that I tried to run Prime95 on, but after around 10 to 15 minutes, the machine forcefully turned itself off because it overheated, and the only way I could get around it was to play with the system settings to slow the CPU down. But would it be feasible to have a feature where you can have the worker threads running for 5 to 10 minutes (configurable), and then do a full stop for another 5 to 10 minutes (also configurable, so you can tailor the times if you know your machine well) so the machine can cool down, before starting again. Obviously it means the tests can take twice as long, but at least it can do [I]something[/I] without shutting off without having a chance to save etc, and can be left unattended.

Of course, the best solution would be periodic monitoring of the CPU core temperature and shutting down the worker threads if it reaches an upper threshold, and not starting up again until it cools below a lower threshold, but I'm not sure how practical that is.[/QUOTE]

This is in a way already there though not with any automatic sensors....

From readme.txt

[QUOTE]If you are running on a laptop or in a hot room and you want to slow the
program down to reduce heat, then you can add this line to prime.txt:
Throttle=n
where n is the percentage of time the program should run. For example,
Throttle=40 means the program will run 40% and be idle 60% of the time.[/QUOTE]

In my own experiment, if my memory is somewhat intact: If you use Throttle=90 for example it will run for 90 seconds then stop for 10 etc....

In my humble opinion: I believe that the core continually getting hot/cool/hot/cool is harder on it than a constant temp even if it is on the high side....

[QUOTE=CuriousKit;410973]I have a suggestion for a feature for a future iteration of Prime95[/QUOTE]Note that this thread is for feature requests on [url]www.gpu72.com[/url] (and by oblique extension [url]www.mersenne.ca[/url]) -- feature suggestions for Prime95 itself should probably go in the [URL="http://mersenneforum.org/forumdisplay.php?f=10"]Software[/URL] forum.

Erg, sorry. While trying to avoid making a new topic, I did a flat search for "Suggestion" without really looking properly at the forum board. Thanks for the correction.

[QUOTE=CuriousKit;410976]Erg, sorry. While trying to avoid making a new topic, I did a flat search for "Suggestion" without really looking properly at the forum board. Thanks for the correction.[/QUOTE]

And even though we're pretty off-topic, for future reference, on a Windows system it's available through a simple WMI call.

For example, run this from a command line (might need to run as admin):
[CODE]wmic /namespace:\\root\wmi PATH MSAcpi_ThermalZoneTemperature get CurrentTemperature[/CODE]

I think it outputs as Celsius * 100, e.g. I get "2815" when I run it which is 28.15 C ( ~ 82.7 F). But on this system I think that may be giving me a temp zone reading, not necessarily the CPU. But you get the idea.

Problem is, you'd want to measure it over time... it'll probably reach a high temp in seconds after starting, so you'd be more interested in throttling it to keep it from hitting the max temp for too long a period? Or introduce some throttling internally to try and keep the temp in a sweet spot.

Either way, a laptop prone to overheating probably isn't the best place to run something like this.