Has anyone ever tried the record function under Linux? My graphics work, I can change views and projections, stop rotation, and even generate a screen dump jpeg, but no recording (via Q or ctrl+Q.) Same result after granting my user account full privledges to the slab model data folder, or running Boinc Manager as root. I am running the \"radeon\" driver and am wondering if AMD\'s \"fglrx\" would make any differnce--or is this feature simply not part of the Linux hadsm3_graphics* program?

Has anyone ever tried the record function under Linux? My graphics work, I can change views and projections, stop rotation, and even generate a screen dump jpeg, but no recording (via Q or ctrl+Q.) Same result after granting my user account full privledges to the slab model data folder, or running Boinc Manager as root. I am running the \"radeon\" driver and am wondering if AMD\'s \"fglrx\" would make any differnce--or is this feature simply not part of the Linux hadsm3_graphics* program?

Same here. There is no key shortcut in the graphics help menu for recording, and it looks like that is appropriate. I thought at one time it might have worked, but if so, that was a long time ago.

I think we should report this to Tolu. Do you know which model types have no Ctrl+Q for recording in the graphics on Linux?

Or should it not be there?

---

Cpdn news

Thanks for responding geophi and mo.v,

Actually the graphics help screens do show a \"Q record\" option (it\'s on the second help page) under hadsm3, hadsm3mh and hadam3p, but these help screens might be a carry-over from the Windows implementations. Is the graphics generator program in Windows using OpenGL? Maybe swapping out the radeon driver for fglrx would help, I think it\'s supposed to better support OpenGL. I will report back later with my finding.

Great Jumping Jehosophat!

IT WORKS!!!

Upgrading the graphics driver to AMD\'s proprietary \"fglrx\" enables recording! I\'ll bet going from open-source to proprietary drivers for Nvidia cards will work as well.

Edit: You have to let your graphics run for a while, then you enable by pressing \"Q\" a few times.

Good to know that the Q recording option is in fact there in all the Linux models.

To capture an iceworld freeze point for a HadSM or HadSMMH and send the recording to Iain Inglis, I found a good method is to:

* make frequent backups whenever running these models but run them without recording
* if a model becomes an iceworld, restore the backup
* restore and run with recording until the freeze

Doing it this way reduces the time the recording has to be on.

Of course you can run the recording all the time from the beginning of these models, in which case you\'d never miss an iceworld freeze and wouldn\'t have to bother about backups. But I wonder about this:

* Has Iain actually discovered that iceworlds can occur on Linux? (I only have Windows where we know they can develop.)

* If he\'s identified Linux iceworlds but their occurrence is very rare, is it worth recording all of them all the time on the off-chance?

* Does anyone know whether graphics recording slows the model processing much? I imagine it must slow the model about as much as running the graphics. On a slow machine the slowdown would probably be bad; on a fast machine not bad.

---

Cpdn news

Has Iain actually discovered that iceworlds can occur on Linux?

On AMD, yes. On Intel, no. When I get to the end of analysing a brute force scan of 1000 WUs that\'s underway, it will be a surprise if the Linux/AMD rate differs much from Windows/Intel, Windows/AMD and Mac (when corrected for platform penetration rates and other factors) - i.e. ~13%.

Does anyone know whether graphics recording slows the model processing much? I imagine it must slow the model about as much as running the graphics.

That\'s exactly what I would expect, but it doesn\'t seem to work that way (on Windows/Intel). I\'ve found no significant slowdown in models when recording: strange but true.

Nice work, Belfry. That\'ll go into the tool bag for when Linux users pitch up here with malfunctioning graphics.

I have a PC running 32bit CentOS 5.4 and BOINC 6.2.15. It is running a GeForce 7200GS with the proprietary Nvidia graphics driver installed. Displaying the graphics window and pressing Q, or Ctrl-Q doesn\'t result in any graphics being captured.

At least it doesn\'t in /home/gdp/BOINC/projects/climateprediction.net/hadsm3fub_kad6_006470612/tmp

Belfry, are you seeing your graphics being captured in the tmp directory under the model directory?

@Iain...

I\'ve never seen any symptoms of an iceworld on my Linux AMDs. No significant speedup or slowdown at any point (other than what happens when adding/subtracting the number of models run, or running the slab with different model types). I\'ve also never seen the odd end of phase graphics on the webpage where the temp suddenly changes and goes off the scale. Crashes happen, but they are probably 1 or 2 out of 100. How are you determining an iceworld on AMD/Linux? I\'m sure you might have posted about this somewhere else, but if so, I wasn\'t paying attention at the time.

Then again, since my AMD/Linux PCs are utilizing SSE2, and most others are not, perhaps that puts my PCs in the same boat as Intel/Linux?

Hi geophi,

Yes, I have a little over 12,000 *.cpdn files totaling 1.4 GB in the projects/climateprediction.net/hadsm3*/tmp directory right now. I think I\'ll reach the iceworld tipping point within another gigabyte.

It might not have been the proprietary driver after all, but rather good old-fashioned trial and error. Set your gfx option to > 40% and > 40 fps in your preferences for good measure. Update and restart Boinc Manager. Turn on your graphics and wait a few minutes, then try toggling some controls like \"a\" and \"w\". Then alternately hit \"q\" and \"o\" a few times. This may wake-up the recording capablility and you will see \"recording...\" above the \"Atmos model time.\" Rinse and repeat if it doesn\'t. You don\'t need write permissions to the tmp directory--but it does make managing the files easier.

After I get my iceworld I will try to figure out more exact steps that set this feature off.

Tried the various key pressing and couldn\'t ever get a recording status on the graphics, or any image files in the tmp directory. I also tried it on another PC with 64bit Ubuntu 9.10 and an ATI card with and without the proprietary drivers, and couldn\'t get it to work either. Perhaps there is another key that is undocumented that you hit while trying to get it to work? I\'ll be interested to see what it really is when you can figure out the needed procedure.

@Iain...

I\'ve never seen any symptoms of an iceworld on my Linux AMDs. No significant speedup or slowdown at any point (other than what happens when adding/subtracting the number of models run, or running the slab with different model types). I\'ve also never seen the odd end of phase graphics on the webpage where the temp suddenly changes and goes off the scale. Crashes happen, but they are probably 1 or 2 out of 100. How are you determining an iceworld on AMD/Linux? I\'m sure you might have posted about this somewhere else, but if so, I wasn\'t paying attention at the time.

Then again, since my AMD/Linux PCs are utilizing SSE2, and most others are not, perhaps that puts my PCs in the same boat as Intel/Linux?

The brute force scan of WU s/ts graphs is an attempt to gather circumstantial evidence linking the behaviour of the different platforms in re iceworlds. For example, the Intel/Darwin has the same rate of iceworlds as Intel/Windows: it could therefore be argued indirectly that Mac and Windows iceworlds are examples of the same phenomenon. (If a sympathetic Mac user gives me a \'.cpdn\' file then I would count that as direct evidence.)

However, there\'s another way of getting the rate and that is to estimate the \'reliable processor rate\' - i.e. the rate at which iceworlds occur for a user who tries to finish everything and doesn\'t have other types of crash. That\'s my policy and the rate at which I get iceworlds is the same as the brute force estimate, which validates my brute force iceworld detection method for Windows/Intel. I did then try to find users on other platforms who might operate as I do - and started with you for Linux/AMD! However, as you say, your rate is effectively zero and I gave up rather discouraged: the SSE2 thing perhaps explains why - so perhaps I should have persevered (or sent a PM). There are, of course, plenty of users who do a lot of crunching but it\'s hard for them to babysit lots of models and so I suspect that they just let BOINC get on with it - it\'s not then possible for me to tell whether a crash in their record is an iceworld or a PC upset.

geophi,

\"See-saw\" ctrl and q several times, varying the frequency--don\'t press them together. This is all that\'s necessary--you don\'t need to hit any other keys. It was blind luck that I stumbled onto this yesterday.

You are right on the money about AMD/Linux with the patched executable--you\'ll never see an iceworld. My iceworld didn\'t form yesterday because I decided to run the patched hasm3_um*, whereas it iceworlded with the unpatched one twice before. I will restore from my Wednesday backup tonight and run unpatched to get Iain his *.cpdn file. Then I\'ll restore the backup I made yesterday and finish the model running patched. Then I might try to start the entire model from scratch (I am not sure if this is doable) and run unpatched to see if it iceworlds earlier.

\"See-saw\" ctrl and q several times, varying the frequency--don\'t press them together. This is all that\'s necessary--you don\'t need to hit any other keys. It was blind luck that I stumbled onto this yesterday.

That\'s bizarre. I got it working...once...on the GeForce. But now can\'t reproduce it.

Well, I got it working again on a few PCs. But it\'s quite the effort. It might take 30-45 seconds of alternately pressing Ctrl and then Q before the \"Recording\" shows up on the graphic. There doesn\'t seem to be any rhyme or reason associated with it. It\'s obviously broken from what\'s intended.

...

There are, of course, plenty of users who do a lot of crunching but it\'s hard for them to babysit lots of models and so I suspect that they just let BOINC get on with it - it\'s not then possible for me to tell whether a crash in their record is an iceworld or a PC upset.

Bill Nichols is another big AMD/Linux user who seems to have pretty stable PCs, and is a veteran of DC. Although he has quite a few models that are \"detached\", there seems to be a pretty low rate of errored slab type models. He is not running the models with SSE2 enabled. I doubt that he looks at the graphics much/at all since there are so many running, but I could be wrong.

Well, I got it working again on a few PCs. But it\'s quite the effort. It might take 30-45 seconds of alternately pressing Ctrl and then Q before the \"Recording\" shows up on the graphic. There doesn\'t seem to be any rhyme or reason associated with it. It\'s obviously broken from what\'s intended.

If appropriate write permissions have been set up and you press \"9\" you get a jpeg file in the tmp directory immediately with ownership by the current desktop user. This makes sense because the desktop user owns the running graphics application. The recorded *.cpdn files however are owned by the \"boinc\" user. I know BOINC usually runs under this account and maybe the recording function requires it, but could the kernel interpret this as two users pressing keys at the same time? I\'ll do a test installation of BOINC running as the desktop user to test this later.

No, a single user installation still requires ctrl + q to be alternately pressed several times. I tested it on an Ubuntu 9.04 32-bit box (whereas my crunching machine is Ubuntu 9.04 64-bit.)

For anyone else reading this, you do not need AMD\'s \"fglrx\" driver, it will work with the open-source \"radeon\" driver. You do need some 3d capability though to get to the interface, so the open-source \"nv\" driver for Nvidia will not work.

Since the recording can run after closing the graphics and Boinc Manager, I wonder if there\'s some command-line hook that could get it to start, even on machines without any graphics?