Message boards : Number crunching : Postponed: VM job unmanageble, restarting later ?????
Message board moderation

To post messages, you must log in.

1 · 2 · Next

AuthorMessage
Thund3rb1rd

Send message
Joined: 24 Jul 05
Posts: 15
Credit: 1,342,197
RAC: 13
Message 35527 - Posted: 15 Jun 2018, 19:34:44 UTC

Why do you suppose the VM job became unmanageable? When is "...later".

Is there anything I can do about any of this?

These VM jobs are more of a pain than anything else in the projects I participate. Unstable, locks up my computers forcing a hard reboot. Hope it's worth it to the three projects that use it because it sure isn't worth the trouble from my side of the fence.
ID: 35527 · Report as offensive     Reply Quote
Toby Broom
Volunteer moderator

Send message
Joined: 27 Sep 08
Posts: 599
Credit: 379,031,541
RAC: 34,959
Message 35528 - Posted: 15 Jun 2018, 20:23:15 UTC - in response to Message 35527.  

I just quit them they never seem to restart.

I don't have many problems after some tweeking.

For me I had some hard locks always due to too much ram usage, limit the number of WU's until your happy with the RAM that is used.
ID: 35528 · Report as offensive     Reply Quote
nairb

Send message
Joined: 1 May 07
Posts: 13
Credit: 1,167,348
RAC: 16
Message 35544 - Posted: 17 Jun 2018, 15:24:44 UTC

I am having the same issues. I upgraded to the latest Boinc (7.10.2 x64) with the VB. Must be a version problem. 4 jobs all stuck with "VM job unmanageable, restarting later " Restarting Boinc get them running for a short while before the same message again. VB is 5.2.12.

Which version of VB is best?.
ID: 35544 · Report as offensive     Reply Quote
San-Fernando-Valley

Send message
Joined: 26 Mar 16
Posts: 30
Credit: 1,245,747
RAC: 0
Message 35659 - Posted: 28 Jun 2018, 9:07:49 UTC

I wonder why the LHC-team doesn't respond to these "problems".
I know they are busy, but so are we spending time on these issues (for months).

I am also receiving the message "Postponed: VM job unmanagable, restarting later ..." !

Suspending the project, then stopping BOINC and restarting the rig solves the problem - BUT only for a short time.

While trying this method to recover, I am receiving message "waiting for slot ..." (I don't remember the complete text).

I noticed that of the four WUs running per rig, one of the four gets postponed while the three others run happily.
After restarting the rig (shutdown and restart) it is the other way around: three of the four wait for slots (?) and the one previously postponed runs nicely.
For a while - then the whole process repeats itself ...

ATLAS seems to be the troublemaker - it is the one that always becomes postponed first after all four WUs where running for a couple of minutes.
AND, please, don't suggest to just not run ATLAS !!

Just for the records:
-- hyperthreading is turned off,
-- no overclocking,
-- plenty ram (64GB),
-- fast SSDs (NVMe Samsung 500GB),
-- no overheating,
-- fast GPU (here of no concern),
-- CPU load varies - from around 50 to 100%,
-- no other projects are running,
-- rigs are just crunching - doing nothing else,
-- no dead/hungup "machines" in VirtualBox 5.2.12
and lots of sunshine outside with blue skys.

I wonder if the LHC-team (L.ets H.appily C.runch) really realises that we volunteers are "donating" time and money trying/wanting to help THEM ?

Thanks for reading up to here - so have a nice day ...
ID: 35659 · Report as offensive     Reply Quote
maeax

Send message
Joined: 2 May 07
Posts: 1021
Credit: 35,635,048
RAC: 24,302
Message 35661 - Posted: 28 Jun 2018, 9:38:56 UTC - in response to Message 35659.  

Have this also,
thinking it is a RAM-problem.
Atlas-tasks are dynamicly growing to use more RAM.
When there is no more RAM avalaible in the PC than postponed...
Every better answer is welcome for us volunteers.
ID: 35661 · Report as offensive     Reply Quote
computezrmle
Volunteer moderator
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 15 Jun 08
Posts: 1551
Credit: 88,456,303
RAC: 93,071
Message 35663 - Posted: 28 Jun 2018, 9:58:50 UTC - in response to Message 35659.  

There is, unfortunately, not yet a recent stderr.txt from your WUs that can be analysed.

The older logs as well as the error messages
1. "postponed: VM job unmanageable ..."
2. "Postponed: Waiting to acquire slot directory lock. Another instance may be running"
point out a local problem rather than a general problem.

(1.) could be caused by the RAM setting you configured in your BOINC client.
(2.) could be caused by remains of older crashes.

Did you recently
- restarted your hosts
- reinstalled BOINC
- cleaned your VBox environment
- reset the project?

How many cores do you use for your ATLAS WUs?
How much RAM is configured?
ID: 35663 · Report as offensive     Reply Quote
Erich56

Send message
Joined: 18 Dec 15
Posts: 1311
Credit: 23,872,044
RAC: 9,882
Message 35664 - Posted: 28 Jun 2018, 10:50:58 UTC

hello, San Fernando

while for me, too, it's not clear by what your problems are caused, one of your lines jumped into my eye:

-- fast SSDs (NVMe Samsung 500GB)

Are you really sure you want to crunch LHC VM tasks with a SSD? Particularly Atlas writes tons of data to the disk.
When I started crunching Atlas with my new PC which was equipped with a SSD, I quickly figured that 4 (or was it even only 3?) concurrently running ATLAS tasks were writing up to 200GB data per day (!). So, it was clear to me that the TBW value of the SSD would be reached within a year, if not earlier (although meanwhile one could read in various forums that some people's SSDs have reached a manyfold of the indicated TBW).

So, once your ATLAS tasks will run well again, you might give a thought to operate VM crunching on a separate HDD.
Just my advice - whatever it's worth :-)
ID: 35664 · Report as offensive     Reply Quote
San-Fernando-Valley

Send message
Joined: 26 Mar 16
Posts: 30
Credit: 1,245,747
RAC: 0
Message 35679 - Posted: 28 Jun 2018, 17:22:08 UTC - in response to Message 35661.  

Have this also,
thinking it is a RAM-problem.
Atlas-tasks are dynamicly growing to use more RAM.
When there is no more RAM avalaible in the PC than postponed...
Every better answer is welcome for us volunteers.


please read my text carefully - ALL MY CONCERNED RIGS HAVE 64GB RAM !!

Taskmanager shows, depending, between 5 and 9 GB used !

So it must be something else ..
ID: 35679 · Report as offensive     Reply Quote
San-Fernando-Valley

Send message
Joined: 26 Mar 16
Posts: 30
Credit: 1,245,747
RAC: 0
Message 35680 - Posted: 28 Jun 2018, 17:25:03 UTC - in response to Message 35664.  

hello, San Fernando

while for me, too, it's not clear by what your problems are caused, one of your lines jumped into my eye:

-- fast SSDs (NVMe Samsung 500GB)

Are you really sure you want to crunch LHC VM tasks with a SSD? Particularly Atlas writes tons of data to the disk.
When I started crunching Atlas with my new PC which was equipped with a SSD, I quickly figured that 4 (or was it even only 3?) concurrently running ATLAS tasks were writing up to 200GB data per day (!). So, it was clear to me that the TBW value of the SSD would be reached within a year, if not earlier (although meanwhile one could read in various forums that some people's SSDs have reached a manyfold of the indicated TBW).

So, once your ATLAS tasks will run well again, you might give a thought to operate VM crunching on a separate HDD.
Just my advice - whatever it's worth :-)


Thanks for the advice - but I am absolutely not concerned about the SSDs ...

I'm concerned about the behavior of the various WUs from LHC ...
ID: 35680 · Report as offensive     Reply Quote
San-Fernando-Valley

Send message
Joined: 26 Mar 16
Posts: 30
Credit: 1,245,747
RAC: 0
Message 35681 - Posted: 28 Jun 2018, 17:36:20 UTC - in response to Message 35663.  

There is, unfortunately, not yet a recent stderr.txt from your WUs that can be analysed.

The older logs as well as the error messages
1. "postponed: VM job unmanageable ..."
2. "Postponed: Waiting to acquire slot directory lock. Another instance may be running"
point out a local problem rather than a general problem.

(1.) could be caused by the RAM setting you configured in your BOINC client.
(2.) could be caused by remains of older crashes.

Did you recently
- restarted your hosts
- reinstalled BOINC
- cleaned your VBox environment
- reset the project?

How many cores do you use for your ATLAS WUs?
How much RAM is configured?


Thanks for your reply:

RAM settings in BOINC are: no more than 90% of total (the rig has 64GB)
No crashes ... as I said no "dead" entries in VirtualBox.
Of course I restarted the host - they don't run 24/7/365 ...
No, I haven't reinstalled BOINC - why should I ?
No, I did not reset the project.

I use one core per WU (ATLAS, Theaory, LHCb) - in other words I'm playing it save!

I would like to point out, that I have/had other projects running nicely in the past years - some of them up to 16GB RAM usage AND using
hyperthreading (2x4 cores) ... (turned off now).
ID: 35681 · Report as offensive     Reply Quote
San-Fernando-Valley

Send message
Joined: 26 Mar 16
Posts: 30
Credit: 1,245,747
RAC: 0
Message 35683 - Posted: 28 Jun 2018, 17:52:57 UTC

The idea is not to have to think/analyse too much ...
Sometimes looking/searching for problems is challenging - sometimes even fun -

I now have a new interesting situation:

ATLAS now has an elapsed time of almost ten hours - taking so far the last three hours for 10 seconds of remaining run time !

At the same time theory WU is predicting 1 to 2 days (!) of remaining time.

LHCb has upped the estimated time to around 20 hours !

This is the state on all four concerned rigs. They are using between 5 and 9 GB RAM.

CPU load varies nicely - so something is beeing crunched.

I will wait another one hours and then flip a coin (the one with both sides the same) and ABORT all.

Maybe someone has some last tip or hint?
ID: 35683 · Report as offensive     Reply Quote
Erich56

Send message
Joined: 18 Dec 15
Posts: 1311
Credit: 23,872,044
RAC: 9,882
Message 35685 - Posted: 28 Jun 2018, 19:38:41 UTC - in response to Message 35681.  


The older logs as well as the error messages
1. "postponed: VM job unmanageable ..."
2. "Postponed: Waiting to acquire slot directory lock. Another instance may be running"

Of course I restarted the host - they don't run 24/7/365 ...
there are 2 thoughs on this:

- did you wait due time between shutting down BOINC and shutting down the computer, so that the VB can close down properly? I remember having had the "Postponed: ..." error when, rarely enough, my PC froze or had some other failure, so that the VB could not close the way it's supposed to.

- I guess I remember having read somewhere here that if a VB task (regardless which one: Atlas, CMS, LHCb, Theory) is interrupted for too long time (by shutting down the PC for a while), it's unable to properly continue lateron.

So, my guess would be that either one of the above points, or both, are the reason for your problems.
ID: 35685 · Report as offensive     Reply Quote
San-Fernando-Valley

Send message
Joined: 26 Mar 16
Posts: 30
Credit: 1,245,747
RAC: 0
Message 35686 - Posted: 28 Jun 2018, 20:12:48 UTC - in response to Message 35685.  

there are 2 thoughs on this:
...
So, my guess would be that either one of the above points, or both, are the reason for your problems.


You might have a point there - BUT I had to shutdown the computer BECAUSE of the "postponed ..." message (trying to revive the ATLAS WU).
So this "action" of mine probably is the reason for the problems that followed afterwards.

So what is the remedy for the initial problem?
Just don't crunch ATLAS.
Same remedy for CMS.

Thanks for your time - I appreciate it.

I will ABORT the WUs and keep on crunching other projects.

Have a nice day.
ID: 35686 · Report as offensive     Reply Quote
bronco

Send message
Joined: 13 Apr 18
Posts: 443
Credit: 8,438,885
RAC: 0
Message 35687 - Posted: 28 Jun 2018, 20:40:39 UTC - in response to Message 35683.  

The problem with the lockfile acquisition is indeed indicative of a crash or not giving the VM enough time to shutdown properly before shutting down the OS. BOINC will not fix that problem for you. You must find out which slot dir that lockfile is in then delete it manually from an admin account though I doubt that action alone will cure all your problems. Sounds like you need to remove the LHC project and then re-add it.
ID: 35687 · Report as offensive     Reply Quote
computezrmle
Volunteer moderator
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 15 Jun 08
Posts: 1551
Credit: 88,456,303
RAC: 93,071
Message 35688 - Posted: 28 Jun 2018, 20:42:38 UTC - in response to Message 35683.  

ATLAS now has an elapsed time of almost ten hours - taking so far the last three hours for 10 seconds of remaining run time !
At the same time theory WU is predicting 1 to 2 days (!) of remaining time.
LHCb has upped the estimated time to around 20 hours !


Don't rely on the times.
They are more or less fake as they are based on fixed input parameters.
ATLAS: has longer or shorter batches
Theory, LHCb (,CMS): designed to run 12h+ but time calculation is based on the watchdog limit of 18h

Theory special: Today a new app version has been introduced. It needs a couple of days until your BOINC client corrects the times.



Some stderr.txt files are now available.
Most of them show that your hosts are much too busy (for whatever reason).
Thus your BOINC client, VirtualBox, vboxwrapper and VMs run into timing/priority problems.


There are lots of blank lines in your logs plus messages like this:
2018-06-28 20:54:21 (2308): Powering off VM.
2018-06-28 20:59:22 (2308): VM did not power off when requested.
2018-06-28 20:59:22 (2308): VM was successfully terminated.


2018-06-28 21:13:37 (5104): Powering off VM.
2018-06-28 21:18:38 (5104): VM did not power off when requested.
2018-06-28 21:18:38 (5104): VM was NOT successfully terminated.


2018-06-28 11:19:33 (3948): ERROR: Vboxwrapper lost communication with VirtualBox, rescheduling task for a later time.




ATLAS 1-core may run with only 3500 MB but to be on the save side you may configure 4800 MB via an app_config.xml:
2018-06-28 08:35:04 (3904): Setting Memory Size for VM. (3500MB)
2018-06-28 08:35:05 (3904): Setting CPU Count for VM. (1)



Your BOINC client was terminated before it could save all VMs and other relevant files.
How many VMs (all together) do you run concurrently? Seems to be too much.
Same problem occurs when you restart too many VMs concurrently.
This is what Erich56 already mentioned.
09:57:41 (3984): BOINC client no longer exists - exiting
09:57:41 (3984): timer handler: client dead, exiting
09:57:52 (3984): BOINC client no longer exists - exiting
09:57:52 (3984): timer handler: client dead, exiting
09:58:03 (3984): BOINC client no longer exists - exiting
09:58:03 (3984): timer handler: client dead, exiting
09:58:04 (4896): Can't acquire lockfile (32) - waiting 35s
09:58:13 (3984): BOINC client no longer exists - exiting
09:58:13 (3984): timer handler: client dead, exiting
09:58:23 (3984): BOINC client no longer exists - exiting
09:58:23 (3984): timer handler: client dead, exiting
09:58:33 (3984): BOINC client no longer exists - exiting
09:58:33 (3984): timer handler: client dead, exiting
09:58:39 (4896): Can't acquire lockfile (32) - exiting
09:58:39 (4896): Error: The process cannot access the file because it is being used by another process.
ID: 35688 · Report as offensive     Reply Quote
San-Fernando-Valley

Send message
Joined: 26 Mar 16
Posts: 30
Credit: 1,245,747
RAC: 0
Message 35716 - Posted: 30 Jun 2018, 15:16:54 UTC - in response to Message 35687.  

The problem with the lockfile acquisition is indeed indicative of a crash or not giving the VM enough time to shutdown properly before shutting down the OS. BOINC will not fix that problem for you. You must find out which slot dir that lockfile is in then delete it manually from an admin account though I doubt that action alone will cure all your problems. Sounds like you need to remove the LHC project and then re-add it.


Thanks for your time answering me.
But I would like to point out, that I am not experiencing/responsible for any crashes - matter of fact: what is a crash - what do you mean by that?

Let me explain my situation again from the beginning:

1. Started my rigs (three Win7 - one Win10) - all is fine !
2. Started BOINC 7.10.2 - OK !
3. Checked VirtualBox 5.2.12 if anything was left behind - nothing there (had not run VB for some time) !
4. Requested Tasks for LHC (all subprojects checked in LHC prefs) in BOINC - no other projects running !
5. RAM 64GB !
6. SSDs fast and large enough (NVMe Samsung 500GB - more or less empty) !
7. BOINC Options fully "open" - no restrictions !
8. Hyperthreading off - so I have 4 cores !
9. No overclocking !
10. The request for tasks for LHC downloaded per core one LHC (mixed subprojects - but always one ATLAS included) !
11. After a longer while (10 minutes ? - don't remember) ATLAS gets the "postponed" message - for no reason whatsoever !
12. The other (mixed) three keep on running fine !
13. Checking VB shows ATLAS powered off !
14. As time goes by, the "remaining exc. time" keeps on going up - way up !
15. So now I have the situation, that one fourth of each rig is doing nothing - ATLAS blocking one core - nice !
16. Suspended LHC !
17. Waited for VB to shutoff its machines correctly - takes quite long !
18. THEN I stopt BOINC !
19. Waited a while - then LOGOFF for rig user !
20. RESTART for the rig !
21. Went on with point 1. above !
22. In BOINC ticked RESUME for LHC !
23. ALL four WUs start - even the postponed ATLAS WU !
24. After a while (see above point 11.) ATLAS againgoes into "postponed ..." !
25. Retried the whole procedure again - same results - EXCEPT this time other non-ATLAS WUs show the other message (slots or something ...), while ATLA runs ok !
26. Furthermore, the "remaining estimated run time" for all WUs goes up and up (on all rigs) - extremely fast - to 1 day or 2 days and more ... !

Hope my above list is somewhat complete and informative.

Any further hints/tips/comments?
Would appreciate it !!
ID: 35716 · Report as offensive     Reply Quote
San-Fernando-Valley

Send message
Joined: 26 Mar 16
Posts: 30
Credit: 1,245,747
RAC: 0
Message 35717 - Posted: 30 Jun 2018, 15:35:28 UTC - in response to Message 35688.  

ATLAS now has an elapsed time of almost ten hours - taking so far the last three hours for 10 seconds of remaining run time !
At the same time theory WU is predicting 1 to 2 days (!) of remaining time.
LHCb has upped the estimated time to around 20 hours !


Don't rely on the times.
They are more or less fake as they are based on fixed input parameters.
ATLAS: has longer or shorter batches
Theory, LHCb (,CMS): designed to run 12h+ but time calculation is based on the watchdog limit of 18h

Theory special: Today a new app version has been introduced. It needs a couple of days until your BOINC client corrects the times.



Some stderr.txt files are now available.
Most of them show that your hosts are much too busy (for whatever reason).
Thus your BOINC client, VirtualBox, vboxwrapper and VMs run into timing/priority problems.


There are lots of blank lines in your logs plus messages like this:
2018-06-28 20:54:21 (2308): Powering off VM.
2018-06-28 20:59:22 (2308): VM did not power off when requested.
2018-06-28 20:59:22 (2308): VM was successfully terminated.


2018-06-28 21:13:37 (5104): Powering off VM.
2018-06-28 21:18:38 (5104): VM did not power off when requested.
2018-06-28 21:18:38 (5104): VM was NOT successfully terminated.


2018-06-28 11:19:33 (3948): ERROR: Vboxwrapper lost communication with VirtualBox, rescheduling task for a later time.




ATLAS 1-core may run with only 3500 MB but to be on the save side you may configure 4800 MB via an app_config.xml:
2018-06-28 08:35:04 (3904): Setting Memory Size for VM. (3500MB)
2018-06-28 08:35:05 (3904): Setting CPU Count for VM. (1)



Your BOINC client was terminated before it could save all VMs and other relevant files.
How many VMs (all together) do you run concurrently? Seems to be too much.
Same problem occurs when you restart too many VMs concurrently.
This is what Erich56 already mentioned.
09:57:41 (3984): BOINC client no longer exists - exiting
09:57:41 (3984): timer handler: client dead, exiting
09:57:52 (3984): BOINC client no longer exists - exiting
09:57:52 (3984): timer handler: client dead, exiting
09:58:03 (3984): BOINC client no longer exists - exiting
09:58:03 (3984): timer handler: client dead, exiting
09:58:04 (4896): Can't acquire lockfile (32) - waiting 35s
09:58:13 (3984): BOINC client no longer exists - exiting
09:58:13 (3984): timer handler: client dead, exiting
09:58:23 (3984): BOINC client no longer exists - exiting
09:58:23 (3984): timer handler: client dead, exiting
09:58:33 (3984): BOINC client no longer exists - exiting
09:58:33 (3984): timer handler: client dead, exiting
09:58:39 (4896): Can't acquire lockfile (32) - exiting
09:58:39 (4896): Error: The process cannot access the file because it is being used by another process.



Thanks for the very comprehensive info.
These informations exceed my horizon - partially !

I'll try to respond:

TIMES -- Ok, the times don't really bother me - except that I have troubles planning my "structured day",

TERMINATION -- YES, I got very unpatient at the end of rer-re-re-trying that situation and just "cut the line" forcibly,

VM - There is only ONE VB (VirtualBox) running per rig. In this one VB I see the four WUs and their status.

SIDE NOTE: Shouldn't these WUs run WITHOUT me/us having to fiddel around with apps etc.? - My 2 cents of griping.
ID: 35717 · Report as offensive     Reply Quote
bronco

Send message
Joined: 13 Apr 18
Posts: 443
Credit: 8,438,885
RAC: 0
Message 35718 - Posted: 30 Jun 2018, 17:36:02 UTC - in response to Message 35717.  
Last modified: 30 Jun 2018, 17:41:37 UTC

SIDE NOTE: Shouldn't these WUs run WITHOUT me/us having to fiddel around with apps etc.? - My 2 cents of griping.


Well of course they should and someday maybe they will but for now they do not and don't expect even 2 billion cents worth of griping and exclamations at the end of every sentence to change that fact overnight. The programmers are getting it figured out but they're not perfect just human. The best we can do as crunchers is accept that reality and work with it patiently. If you can't find the patience then you need to decide whether or not crunching is for you.

One thing that makes it easier is to walk before you run. And don't EVER "cut the line forcibly" because on an OS as unstable and poorly designed as Windoze you're just asking for tons of trouble. I would consider formatting the drive and reinstalling everything from scratch and this time going with a real OS instead of Windoze. Then learn how to walk before you run. Turning on ALL the applications at this project is likely a mistake. Setting "unlimited cores" would be another mistake.

You seem to have a number of hosts so simplify things by segregating LHC apps by computer which means run ATLAS and nothing but ATLAS on host A, Theory and nothing but Theory on host B, LHCb and nothing but LHCb on host C. Try it that way for a couple months until you get a better handle on what plays nice together and what does not. Then you'll have an idea of how much babysitting is required and whether you have the time and patience to make things even more complex by attempting to mix apps. That's the lovely thing here... you can make it as simple or as complex as you like :)
ID: 35718 · Report as offensive     Reply Quote
Jim1348

Send message
Joined: 15 Nov 14
Posts: 466
Credit: 13,276,411
RAC: 11,504
Message 35719 - Posted: 30 Jun 2018, 19:23:49 UTC - in response to Message 35718.  

You seem to have a number of hosts so simplify things by segregating LHC apps by computer which means run ATLAS and nothing but ATLAS on host A, Theory and nothing but Theory on host B, LHCb and nothing but LHCb on host C.

What works for me (sort of) is a non-VirtualBox machine to run native ATLAS, and then a VirtualBox machine. For the latter, I can usually run Theory and LHCb without a problem, but I would avoid CMS like the plague if you want a simple life.
And I don't normally do Sixtrack at all; it is too easy, and anyone can do it without special software, so I leave it to them.

But what used to work is not working so well now, as everything is falling apart in various degrees. I think the fact of life is that LHC is the most advanced physics project in the world, and it has the most complicated computer and network structure as a necessary part of it. Furthermore, it was not developed for the home users running BOINC, as are most BOINC projects, but was developed for the advanced computing capabilities of similar large institutions (Fermilab, etc.) around the world. They probably don't use VBox at all. So we are sort of an afterthought. It is not that they don't appreciate our efforts, but we are the tail of the dog, not the head of it.
ID: 35719 · Report as offensive     Reply Quote
tullio

Send message
Joined: 19 Feb 08
Posts: 611
Credit: 3,829,373
RAC: 520
Message 35723 - Posted: 1 Jul 2018, 2:51:27 UTC

On the Top500 list IBM has reached the top with its Summit computer, which makes large use of nVidia Tesla GPU boards at 200 petaflops. The second is a Chinese supercomputer which was first last time, the third is another American computer, Sierra. The Piz Daint Swiss computer which was third is now sixth, the best Italian is thirteenth. Things change rapidly in the supercomputer world.
Tullio
ID: 35723 · Report as offensive     Reply Quote
1 · 2 · Next

Message boards : Number crunching : Postponed: VM job unmanageble, restarting later ?????


©2020 CERN