I do have this version, but I haven't been able to install it on Solaris 10.
# ./aimk -gcc Building in directory: /home/sge/tar/sge-8.1.9/source making in SOLARIS64/ for SOLARIS64 at host m5000 _________C_O_R_E__S_Y_S_T_E_M_____________ make: Warning: Can't find `../common/common_dependencies': No such file or directory make: Fatal error in reader: ../common/Makefile, line 70: Read of include file `../common/common_dependencies' failed not done John -----Original Message----- From: William Hay [mailto:w....@ucl.ac.uk] Sent: Thursday, March 23, 2017 5:26 To: John_Tai Cc: Reuti; users@gridengine.org; Coleman, Marcus [JRDUS Non-J&J] Subject: Re: [gridengine users] John's cores pe (Was: users Digest...) On Thu, Mar 23, 2017 at 08:11:02AM +0000, John_Tai wrote: > Can I still download 6.2? Haven't been able to find it. > > John If you're going to upgrade you might as well go all the way to SoGE 8.1.9. William > > -----Original Message----- > From: Reuti [mailto:re...@staff.uni-marburg.de] > Sent: Wednesday, March 22, 2017 8:27 > To: John_Tai > Cc: Christopher Black; users@gridengine.org; Coleman, Marcus [JRDUS > Non-J&J] > Subject: Re: [gridengine users] John's cores pe (Was: users Digest...) > > Hi, > > > Am 22.03.2017 um 04:24 schrieb John_Tai <john_...@smics.com>: > > > > I am now using sge6.1, however it doesn't have the option "JOB" for complex > > consumable value. Is there another way to NOT multiply consumable memory > > resource by number of pe slots? > > Not that I'm aware of. It was a features introduced with SGE 6.2u2: > > https://arc.liv.ac.uk/trac/SGE/ticket/197 > > -- Reuti > > > > > > Thanks > > John > > > > > > > > -----Original Message----- > > From: Reuti [mailto:re...@staff.uni-marburg.de] > > Sent: Wednesday, December 21, 2016 7:05 > > To: Christopher Black > > Cc: John_Tai; users@gridengine.org; Coleman, Marcus [JRDUS Non-J&J] > > Subject: Re: [gridengine users] John's cores pe (Was: users > > Digest...) > > > > > > Am 20.12.2016 um 23:42 schrieb Christopher Black: > > > >> We have found that the behavior that multiples consumable memory resource > >> requests by number of pe slots can be confusing (and requires extra math > >> in automation scripts), so we've have the complex consumable value set to > >> "JOB" rather than "YES". When this is done (at least on SoGE), the memory > >> requested is NOT multiplied by the number of slots. We also use h_vmem > >> rather than virtual_free. > > > > Correct, it's not multiplied. But only the master exechost will get its > > memory reduced in the bookeeping. The slave exechosts might still show a > > too high value of the available memory I fear. > > > > -- Reuti > > > > > >> Best, > >> Chris > >> > >> On 12/20/16, 5:11 AM, "users-boun...@gridengine.org on behalf of Reuti" > >> <users-boun...@gridengine.org on behalf of re...@staff.uni-marburg.de> > >> wrote: > >> > >> > >>> Am 20.12.2016 um 02:45 schrieb John_Tai <john_...@smics.com>: > >>> > >>> I spoke too soon. I can request PE and virtual_free separately, but I > >>> cannot request both: > >>> > >>> > >>> > >>> # qsub -V -b y -cwd -now n -pe cores 7 -l mem=10G -q all.q@ibm037 > >>> xclock > >> > >> Above you request "mem" (which is a snapshot of the actual usage and may > >> vary over the runtime of other jobs [unless they request the total amount > >> already at the beginning of the job and stay with it]). > >> > >>> Your job 180 ("xclock") has been submitted # qstat > >>> job-ID prior name user state submit/start at queue > >>> slots ja-task-ID > >>> ----------------------------------------------------------------------------------------------------------------- > >>> 180 0.55500 xclock johnt qw 12/20/2016 09:43:41 > >>> 7 > >>> # qstat -j 180 > >>> ============================================================== > >>> job_number: 180 > >>> exec_file: job_scripts/180 > >>> submission_time: Tue Dec 20 09:43:41 2016 > >>> owner: johnt > >>> uid: 162 > >>> group: sa > >>> gid: 4563 > >>> sge_o_home: /home/johnt > >>> sge_o_log_name: johnt > >>> sge_o_path: > >>> /home/sge/sge8.1.9-1.el5/bin:/home/sge/sge8.1.9-1.el5/bin/lx-amd64:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin:/home/johnt/bin:. > >>> sge_o_shell: /bin/tcsh > >>> sge_o_workdir: /home/johnt/sge8 > >>> sge_o_host: ibm005 > >>> account: sge > >>> cwd: /home/johnt/sge8 > >>> hard resource_list: virtual_free=10G > >> > >> 10G times 7 = 70 GB > >> > >> The node has this amount of memory installed and it is defined this way > >> in `qconf -me ibm037`? > >> > >> -- Reuti > >> > >> > >>> mail_list: johnt@ibm005 > >>> notify: FALSE > >>> job_name: xclock > >>> jobshare: 0 > >>> hard_queue_list: all.q@ibm037 > >>> env_list: TERM=xterm,DISPLAY=dsls11:3. [..] > >>> script_file: xclock > >>> parallel environment: cores range: 7 > >>> binding: NONE > >>> job_type: binary > >>> scheduling info: cannot run in queue "sim.q" because it is not > >>> contained in its hard queue list (-q) > >>> cannot run in queue "pc.q" because it is not > >>> contained in its hard queue list (-q) > >>> cannot run in PE "cores" because it only > >>> offers 0 slots > >>> > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Reuti [mailto:re...@staff.uni-marburg.de] > >>> Sent: Saturday, December 17, 2016 10:16 > >>> To: Reuti > >>> Cc: John_Tai; users@gridengine.org; Coleman, Marcus [JRDUS > >>> Non-J&J] > >>> Subject: Re: [gridengine users] John's cores pe (Was: users > >>> Digest...) > >>> > >>> > >>> Am 17.12.2016 um 11:34 schrieb Reuti: > >>> > >>>> > >>>> Am 17.12.2016 um 02:01 schrieb John_Tai: > >>>> > >>>>> It is working!! Thank you to all that replied to me and helped me > >>>>> figure this out. > >>>>> > >>>>> I meant to set the default to 2G so that was my mistake. I changed it > >>>>> to: > >>>>> > >>>>> virtual_free mem MEMORY <= YES YES > >>>>> 2G 0 > >>>> > >>>> That's strange. A plain "2" was for me always two bytes. A "h_vmem" of 2 > >>>> bytes would crash the job instantly when it got scheduled, but for > >>>> "virtual_free" (which is only a guidance for SGE how to distribute jobs) > >>>> it shouldn't hinder the scheduling at all. > >>>> > >>>> `man sge_types` also lists: > >>>> > >>>> If no multiplier is present, the value is just counted in bytes. > >>> > >>> We have set "-w e" in /usr/sge/default/common/sge_request, and then I > >>> even face an "Unable to run job: error: no suitable queues." This happens > >>> whether the low 2 byte value is specified in the complex definition > >>> `qconf -mc` or on the command line as "-l virutal_free=2". > >>> > >>> It turns out, that the minimum value which is being accepted is: 33. > >>> > >>> -- Reuti > >>> > >>> > >>>> > >>>>> And it's working now. Although I'm not sure why it affected the PE. > >>>>> > >>>>> Also I didn't set a global one, what is the purpose of the global one? > >>>>> Should I set it? > >>>> > >>>> No, it was only one place I would have checked too. The global complexes > >>>> therein can for example be used for a limit in the number of licenses of > >>>> an application you have and which can be used floating in the cluster > >>>> (one could prefer to put such a limit in an RQS though). > >>>> > >>>> If you would have set it up there, it would have been the "overall limit > >>>> of memory which can be used in the complete cluster at the same time". > >>>> > >>>> -- Reuti > >>>> > >>>> > >>>>> # qconf -se global > >>>>> hostname global > >>>>> load_scaling NONE > >>>>> complex_values NONE > >>>>> load_values NONE > >>>>> processors 0 > >>>>> user_lists NONE > >>>>> xuser_lists NONE > >>>>> projects NONE > >>>>> xprojects NONE > >>>>> usage_scaling NONE > >>>>> report_variables NONE > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Reuti [mailto:re...@staff.uni-marburg.de] > >>>>> Sent: Friday, December 16, 2016 7:36 > >>>>> To: John_Tai > >>>>> Cc: Christopher Heiny; users@gridengine.org; Coleman, Marcus > >>>>> [JRDUS Non-J&J] > >>>>> Subject: Re: [gridengine users] John's cores pe (Was: users > >>>>> Digest...) > >>>>> > >>>>> > >>>>>> Am 16.12.2016 um 09:53 schrieb John_Tai <john_...@smics.com>: > >>>>>> > >>>>>> virtual_free mem MEMORY <= YES YES > >>>>>> 2 0 > >>>>> > >>>>> This would mean, that the default consumption is 2 bytes. I already > >>>>> feared that a high values was programmed here. More suitable would be a > >>>>> default of 1G or so. > >>>>> > >>>>> Is there any virtual_free complex defined on a global level: > >>>>> qconf -se global > >>>>> > >>>>> -- Reuti > >>>>> ________________________________ > >>>>> > >>>>> This email (including its attachments, if any) may be confidential and > >>>>> proprietary information of SMIC, and intended only for the use of the > >>>>> named recipient(s) above. Any unauthorized use or disclosure of this > >>>>> email is strictly prohibited. If you are not the intended recipient(s), > >>>>> please notify the sender immediately and delete this email from your > >>>>> computer. > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> users mailing list > >>>> users@gridengine.org > >>>> https://gridengine.org/mailman/listinfo/users > >>> > >>> ________________________________ > >>> > >>> This email (including its attachments, if any) may be confidential and > >>> proprietary information of SMIC, and intended only for the use of the > >>> named recipient(s) above. Any unauthorized use or disclosure of this > >>> email is strictly prohibited. If you are not the intended recipient(s), > >>> please notify the sender immediately and delete this email from your > >>> computer. > >>> > >> > >> > >> _______________________________________________ > >> users mailing list > >> users@gridengine.org > >> https://gridengine.org/mailman/listinfo/users > >> > >> > >> > >> This electronic message is intended for the use of the named recipient > >> only, and may contain information that is confidential, privileged or > >> protected from disclosure under applicable law. If you are not the > >> intended recipient, or an employee or agent responsible for delivering > >> this message to the intended recipient, you are hereby notified that any > >> reading, disclosure, dissemination, distribution, copying or use of the > >> contents of this message including any of its attachments is strictly > >> prohibited. If you have received this message in error or are not the > >> named recipient, please notify us immediately by contacting the sender at > >> the electronic mail address noted above, and destroy all copies of this > >> message. Please note, the recipient should check this email and any > >> attachments for the presence of viruses. The organization accepts no > >> liability for any damage caused by any virus transmitted by this email. > >> > > > > ________________________________ > > > > This email (including its attachments, if any) may be confidential and > > proprietary information of SMIC, and intended only for the use of the named > > recipient(s) above. Any unauthorized use or disclosure of this email is > > strictly prohibited. If you are not the intended recipient(s), please > > notify the sender immediately and delete this email from your computer. > > > > ________________________________ > > This email (including its attachments, if any) may be confidential and > proprietary information of SMIC, and intended only for the use of the named > recipient(s) above. Any unauthorized use or disclosure of this email is > strictly prohibited. If you are not the intended recipient(s), please notify > the sender immediately and delete this email from your computer. > > _______________________________________________ > users mailing list > users@gridengine.org > https://gridengine.org/mailman/listinfo/users ________________________________ This email (including its attachments, if any) may be confidential and proprietary information of SMIC, and intended only for the use of the named recipient(s) above. Any unauthorized use or disclosure of this email is strictly prohibited. If you are not the intended recipient(s), please notify the sender immediately and delete this email from your computer. _______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
