parallel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: --eta, --bar, --progress (progression indicator): no show real progr


From: phoebus phoebus
Subject: Re: --eta, --bar, --progress (progression indicator): no show real progress
Date: Fri, 11 Apr 2014 22:27:45 +0100 (BST)

the options --joblog (Logfile for executed jobs) provides me the things i expected.
Just parse the 'logfiles for exectued jobs' to have some statistics i need.
It's not the smart way and efficient but is the only one i found. This usage seems to have no impact on execution time on my case.



De : phoebus phoebus <frphoebus@yahoo.fr>
À : "parallel@gnu.org" <parallel@gnu.org>
Envoyé le : Mercredi 2 avril 2014 9h18
Objet : --eta, --bar, --progress (progression indicator): no show real progress

According to GNU paralle man:
--bar
Show progress as a progress bar. In the bar is shown: % of jobs completed, estimated seconds left, and number of jobs started.
--eta
Show the estimated number of seconds before finishing. This forces GNU parallel to read all jobs before starting to find the number of jobs. GNU parallel normally only reads the next job to run. Implies --progress.
--progress
Show progress of computations. List the computers involved in the task with number of CPU cores detected and the max number of jobs to run. After that show progress for each computer: number of running jobs, number of completed jobs, and percentage of all jobs done by this computer. The percentage will only be available after all jobs have been scheduled as GNU parallel only read the next job when ready to schedule it - this is to avoid wasting time and memory by reading everything at startup.
By sending GNU parallel SIGUSR2 you can toggle turning on/off --progress on a running GNU parallel process.
See also --eta.
 
I have some troubles with send big sequence (by example 60000) to parallel to show job progression. For litlle sequence also but it's not a problem because it's a short time.
I don't know if the fact i use remote computer have some bad effects on statistics.
In live environment i push an input file (1 million entry) to parallel with option --eta, parallel seems frozen and the treatment progress very slowly. Default tratment it's done in 30 mn, but with --eta option 1h30 after is very far to be complete and give the impression it's need one day to be finish.
 
I need to have a live indicator and for batch how many jobs are trated by each computers (local and remotes).
Perhaps, it's me, i don't use well parallel with the right grammar.
 
 
Below and some example to repoduce the problem.
By default:
[root@virtualdev01 ~]#  seq 60000 | time parallel -S :,peritmp1,peritmp2,peritmp3,peritmp4 true
When using programs that use GNU Parallel to process data for publication please cite:
  O. Tange (2011): GNU Parallel - The Command-Line Power Tool,
  ;login: The USENIX Magazine, February 2011:42-47.
This helps funding further development; and it won't cost you a cent.
To silence this citation notice run 'parallel --bibtex' once or use '--no-notice'.
404.92user 368.12system 2:48.89elapsed 457%CPU (0avgtext+0avgdata 45280maxresident)k
8inputs+1817320outputs (0major+116216585minor)pagefaults 0swaps
[root@virtualdev01 ~]#
 
--eta:
[root@virtualdev01 ~]#  seq 60000 | time parallel  --eta -S :,peritmp1,peritmp2,peritmp3,peritmp4 true
When using programs that use GNU Parallel to process data for publication please cite:
  O. Tange (2011): GNU Parallel - The Command-Line Power Tool,
  ;login: The USENIX Magazine, February 2011:42-47.
This helps funding further development; and it won't cost you a cent.
To silence this citation notice run 'parallel --bibtex' once or use '--no-notice'.

Computers / CPU cores / Max jobs to run
1:local / 32 / 32
2:peritmp1 / 16 / 15
3:peritmp2 / 16 / 15
4:peritmp3 / 16 / 15
5:peritmp4 / 32 / 31
Computer:jobs running/jobs completed/%of started jobs
1:32/0/29% 2:15/0/13% 3:15/0/13% 4:15/0/13% 5:31/0/28%
Computer:jobs running/jobs completed
ETA: 0s Left: 0 AVG: 0.01s  1:0/17772 2:0/8337 3:0/8337 4:0/8337 5:0/17217
430.30user 1192.97system 9:18.37elapsed 290%CPU (0avgtext+0avgdata 1000560maxresident)k
0inputs+1805304outputs (0major+133723779minor)pagefaults 0swaps
[root@virtualdev01 ~]#
 
--bar:
[root@virtualdev01 ~]#  seq 60000 | time parallel  --bar -S :,peritmp1,peritmp2,peritmp3,peritmp4 true
When using programs that use GNU Parallel to process data for publication please cite:
  O. Tange (2011): GNU Parallel - The Command-Line Power Tool,
  ;login: The USENIX Magazine, February 2011:42-47.
This helps funding further development; and it won't cost you a cent.
To silence this citation notice run 'parallel --bibtex' once or use '--no-notice'.
100% 60000:0=0s 60000
429.46user 1259.50system 9:59.95elapsed 281%CPU (0avgtext+0avgdata 1000544maxresident)k
0inputs+1787912outputs (0major+131390205minor)pagefaults 0swaps
[root@virtualdev01 ~]#
 
--progress:
[root@virtualdev01 ~]#  seq 60000 | time parallel  --progress -S :,peritmp1,peritmp2,peritmp3,peritmp4 true
When using programs that use GNU Parallel to process data for publication please cite:
  O. Tange (2011): GNU Parallel - The Command-Line Power Tool,
  ;login: The USENIX Magazine, February 2011:42-47.
This helps funding further development; and it won't cost you a cent.
To silence this citation notice run 'parallel --bibtex' once or use '--no-notice'.

Computers / CPU cores / Max jobs to run
1:local / 32 / 32
2:peritmp1 / 16 / 15
3:peritmp2 / 16 / 15
4:peritmp3 / 16 / 15
5:peritmp4 / 32 / 31
Computer:jobs running/jobs completed/%of started jobs
1:0/20444/34% 2:0/8124/13% 3:0/7490/12% 4:0/8122/13% 5:0/15820/26%%%
388.32user 311.88system 2:24.49elapsed 484%CPU (0avgtext+0avgdata 45328maxresident)k
8inputs+1834488outputs (0major+116432910minor)pagefaults 0swaps
[root@virtualdev01 ~]#
 
 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]