Discussion:
Issue seen in 6.2U5 : memory values reported by SGE too low compared to top output on linux systems
shruti_m
2010-03-09 23:37:44 UTC
Permalink
Hi All,

We recently upgraded one of the sites to 6.2U5. Since the upgrade, we have noticed that vmem and maxvmem values reported by qstat in SGE is much low compared to real time mem consumed by the job and reflected in top output of the system.

e.g I submit a job to grab 20G memory and hold it for 300 sec. In top output, I do see my job consuming upto 20G memory for 300 sec...qstat output shows maxvmem to have never exceeded 3G !! It is easibly reproducible on lx24-amd64 systems.

Let me know, if anybody else has seen similar behavior.

Thanks,
Shruti

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=247770

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
reuti
2010-03-10 13:51:19 UTC
Permalink
Hi,

Am 10.03.2010 um 00:37 schrieb shruti_m:

> We recently upgraded one of the sites to 6.2U5. Since the upgrade,
> we have noticed that vmem and maxvmem values reported by qstat in
> SGE is much low compared to real time mem consumed by the job and
> reflected in top output of the system.
>
> e.g I submit a job to grab 20G memory and hold it for 300 sec. In
> top output, I do see my job consuming upto 20G memory for 300 sec…
> qstat output shows maxvmem to have never exceeded 3G !! It is
> easibly reproducible on lx24-amd64 systems.

the memory is also filled with valid data or just allocted without
being used?

-- Reuti


> Let me know, if anybody else has seen similar behavior.
>
> Thanks,
> Shruti

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=247837

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
stephendennis
2010-03-10 14:20:55 UTC
Permalink
Hello Shruti

When you allocated the memory did you also write data into it?
Until you do the allocation is virtual.

Stephen
________________________________________
From: shruti_m [***@synopsys.com]
Sent: Tuesday, March 09, 2010 6:37 PM
To: ***@gridengine.sunsource.net
Subject: [GE users] Issue seen in 6.2U5 : memory values reported by SGE too low compared to top output on linux systems

Hi All,

We recently upgraded one of the sites to 6.2U5. Since the upgrade, we have noticed that vmem and maxvmem values reported by qstat in SGE is much low compared to real time mem consumed by the job and reflected in top output of the system.

e.g I submit a job to grab 20G memory and hold it for 300 sec. In top output, I do see my job consuming upto 20G memory for 300 sec
qstat output shows maxvmem to have never exceeded 3G !! It is easibly reproducible on lx24-amd64 systems.

Let me know, if anybody else has seen similar behavior.

Thanks,
Shruti

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=247841

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
shruti_m
2010-03-10 18:10:45 UTC
Permalink
Hi Reuti/Stephen,



Actual data is being written to memory. Both VIRT and RES values are quite high compared to vmem reported by SGE. It is easily reproducible and consistent in behavior.



=======================================================================================================



top - 10:08:48 up 104 days, 13:52, 11 users, load average: 1.00, 0.69, 0.30

Tasks: 124 total, 2 running, 122 sleeping, 0 stopped, 0 zombie

Cpu(s): 24.4% us, 0.7% sy, 0.0% ni, 74.8% id, 0.1% wa, 0.0% hi, 0.1% si

Mem: 16409180k total, 12688836k used, 3720344k free, 69944k buffers

Swap: 33557960k total, 127132k used, 33430828k free, 427984k cached



PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

14517 shruti 25 0 11.7g 11g 23m R 99.9 73.2 5:13.35 common_shell_ex


=======================================================================================================

usage 1: cpu=00:04:44, mem=512.92204 GBs, io=0.00000, vmem=2.681G, maxvmem=3.997G

=======================================================================================================



Thanks,

Shruti





-----Original Message-----
From: stephendennis [mailto:***@univaud.com]
Sent: Wednesday, March 10, 2010 6:21 AM
To: ***@gridengine.sunsource.net
Subject: RE: [GE users] Issue seen in 6.2U5 : memory values reported by SGE too low compared to top output on linux systems



Hello Shruti



When you allocated the memory did you also write data into it?

Until you do the allocation is virtual.



Stephen

________________________________________

From: shruti_m [***@synopsys.com]

Sent: Tuesday, March 09, 2010 6:37 PM

To: ***@gridengine.sunsource.net

Subject: [GE users] Issue seen in 6.2U5 : memory values reported by SGE too low compared to top output on linux systems



Hi All,



We recently upgraded one of the sites to 6.2U5. Since the upgrade, we have noticed that vmem and maxvmem values reported by qstat in SGE is much low compared to real time mem consumed by the job and reflected in top output of the system.



e.g I submit a job to grab 20G memory and hold it for 300 sec. In top output, I do see my job consuming upto 20G memory for 300 sec
qstat output shows maxvmem to have never exceeded 3G !! It is easibly reproducible on lx24-amd64 systems.



Let me know, if anybody else has seen similar behavior.



Thanks,

Shruti



------------------------------------------------------

http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=247841



To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=247871

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
icaci
2010-03-11 00:17:55 UTC
Permalink
Hi,

I can confirm that both vmem and maxvmem values shown by qstat (and qacct) are modulo 2^32 in bytes, at least on lx24-amd64. Here is the output from qacct for a simple C program that calloc()-s some good deal of memory of various sizes:

calloc 3 GiB:
cpu 3.540
mem 7.374
maxvmem 3.013G

calloc 7 GiB:
cpu 8.120
mem 22.271
maxvmem 3.013G

calloc 11 GiB:
cpu 12.710
mem 34.406
maxvmem 3.013G

calloc 4 GiB:
cpu 4.730
mem 0.012
maxvmem 13.074M

It looks like a bug in SGE to me - vmem's value is converted to 32-bit somewhere along the path (probably as early as in the shepherd). That results in incorrect value for the time integral in "mem" as well.

Hristo

On 10.03.2010, at 20:10, shruti_m wrote:

> Hi Reuti/Stephen,
>
> Actual data is being written to memory. Both VIRT and RES values are quite high compared to vmem reported by SGE. It is easily reproducible and consistent in behavior.
>
> =======================================================================================================
>
> top - 10:08:48 up 104 days, 13:52, 11 users, load average: 1.00, 0.69, 0.30
> Tasks: 124 total, 2 running, 122 sleeping, 0 stopped, 0 zombie
> Cpu(s): 24.4% us, 0.7% sy, 0.0% ni, 74.8% id, 0.1% wa, 0.0% hi, 0.1% si
> Mem: 16409180k total, 12688836k used, 3720344k free, 69944k buffers
> Swap: 33557960k total, 127132k used, 33430828k free, 427984k cached
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 14517 shruti 25 0 11.7g 11g 23m R 99.9 73.2 5:13.35 common_shell_ex
>
> =======================================================================================================
> usage 1: cpu=00:04:44, mem=512.92204 GBs, io=0.00000, vmem=2.681G, maxvmem=3.997G
> =======================================================================================================
>
> Thanks,
> Shruti
>
>
> -----Original Message-----
> From: stephendennis [mailto:***@univaud.com]
> Sent: Wednesday, March 10, 2010 6:21 AM
> To: ***@gridengine.sunsource.net
> Subject: RE: [GE users] Issue seen in 6.2U5 : memory values reported by SGE too low compared to top output on linux systems
>
> Hello Shruti
>
> When you allocated the memory did you also write data into it?
> Until you do the allocation is virtual.
>
> Stephen
> ________________________________________
> From: shruti_m [***@synopsys.com]
> Sent: Tuesday, March 09, 2010 6:37 PM
> To: ***@gridengine.sunsource.net
> Subject: [GE users] Issue seen in 6.2U5 : memory values reported by SGE too low compared to top output on linux systems
>
> Hi All,
>
> We recently upgraded one of the sites to 6.2U5. Since the upgrade, we have noticed that vmem and maxvmem values reported by qstat in SGE is much low compared to real time mem consumed by the job and reflected in top output of the system.
>
> e.g I submit a job to grab 20G memory and hold it for 300 sec. In top output, I do see my job consuming upto 20G memory for 300 sec
qstat output shows maxvmem to have never exceeded 3G !! It is easibly reproducible on lx24-amd64 systems.
>
> Let me know, if anybody else has seen similar behavior.
>
> Thanks,
> Shruti
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=247841
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

--
Dr Hristo Iliev
Monte Carlo research group
Faculty of Physics, University of Sofia
5 James Bourchier blvd, 1164 Sofia, Bulgaria
http://cluster.phys.uni-sofia.bg/hristo/

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=247921

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
yungsg
2010-03-11 09:48:22 UTC
Permalink
hi,

I'm seeing the same problem too. Here's 'top' output on the compute node
(lx24-amd64, 6.2u5):

Mem: 16440132k total, 16162000k used, 278132k free, 1760k buffers
Swap: 15631204k total, 560672k used, 15070532k free, 2020072k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3602 g0700703 18 0 505m 283m 6792 R 102.5 1.8 1291:15 vasp-mpi-gamma-
3603 g0700703 18 0 504m 283m 6792 R 102.5 1.8 1291:12 vasp-mpi-gamma-
7523 g0700690 25 0 12.7g 12g 231m R 100.5 79.2 167:22.66 green
3948 g0700703 25 0 571m 439m 9408 R 98.6 2.7 1137:13 vasp-mpi-gamma-

PID 7523 is using 12g, while the qstat for the job shows:
cpu=02:56:06, mem=22080.33477 GBs, io=0.19387, vmem=1.222G, maxvmem=4.030G

I started seeing this problem from 6.2u4 (or u3 I think...). It was ok
with earlier versions.

rgds,
--shing

On Tue, 9 Mar 2010, shruti_m wrote:

>
> Hi All,
>
>  
>
> We recently upgraded one of the sites to 6.2U5. Since the upgrade, we have
> noticed that vmem and maxvmem values reported by qstat in SGE is much low
> compared to real time mem consumed by the job and reflected in top output of
> the system.
>
>  
>
> e.g I submit a job to grab 20G memory and hold it for 300 sec. In top
> output, I do see my job consuming upto 20G memory for 300 sec
qstat output
> shows maxvmem to have never exceeded 3G !! It is easibly reproducible on
> lx24-amd64 systems.
>
>  
>
> Let me know, if anybody else has seen similar behavior.
>
>  
>
> Thanks,
>
> Shruti
>
>
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=247978

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
reuti
2010-03-11 10:26:30 UTC
Permalink
Hi,

Am 11.03.2010 um 10:48 schrieb yungsg:

> I'm seeing the same problem too. Here's 'top' output on the compute
> node
> (lx24-amd64, 6.2u5):
>
> Mem: 16440132k total, 16162000k used, 278132k free, 1760k
> buffers
> Swap: 15631204k total, 560672k used, 15070532k free, 2020072k
> cached
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 3602 g0700703 18 0 505m 283m 6792 R 102.5 1.8 1291:15 vasp-
> mpi-gamma-
> 3603 g0700703 18 0 504m 283m 6792 R 102.5 1.8 1291:12 vasp-
> mpi-gamma-
> 7523 g0700690 25 0 12.7g 12g 231m R 100.5 79.2 167:22.66 green
> 3948 g0700703 25 0 571m 439m 9408 R 98.6 2.7 1137:13 vasp-
> mpi-gamma-
>
> PID 7523 is using 12g, while the qstat for the job shows:
> cpu=02:56:06, mem=22080.33477 GBs, io=0.19387, vmem=1.222G,
> maxvmem=4.030G
>
> I started seeing this problem from 6.2u4 (or u3 I think...). It was ok
> with earlier versions.

can one of them who detects it file an issue please, pointing to this
discussion.

-- Reuti


> rgds,
> --shing
>
> On Tue, 9 Mar 2010, shruti_m wrote:
>
>>
>> Hi All,
>>
>>
>>
>> We recently upgraded one of the sites to 6.2U5. Since the upgrade,
>> we have
>> noticed that vmem and maxvmem values reported by qstat in SGE is
>> much low
>> compared to real time mem consumed by the job and reflected in top
>> output of
>> the system.
>>
>>
>>
>> e.g I submit a job to grab 20G memory and hold it for 300 sec. In top
>> output, I do see my job consuming upto 20G memory for 300 sec…
>> qstat output
>> shows maxvmem to have never exceeded 3G !! It is easibly
>> reproducible on
>> lx24-amd64 systems.
>>
>>
>>
>> Let me know, if anybody else has seen similar behavior.
>>
>>
>>
>> Thanks,
>>
>> Shruti
>>
>>
>>
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?
> dsForumId=38&dsMessageId=247978
>
> To unsubscribe from this discussion, e-mail: [users-
> ***@gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=247983

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
shruti_m
2010-03-11 19:21:52 UTC
Permalink
Hi Reuti,

SR # 72565888 is already filed for it. Dan Templeton is also aware of the same.

Thanks,
Shruti

-----Original Message-----
From: reuti [mailto:***@staff.uni-marburg.de]
Sent: Thursday, March 11, 2010 2:27 AM
To: ***@gridengine.sunsource.net
Subject: Re: [GE users] Issue seen in 6.2U5 : memory values reported by SGE too low compared to top output on linux systems

Hi,

Am 11.03.2010 um 10:48 schrieb yungsg:

> I'm seeing the same problem too. Here's 'top' output on the compute
> node
> (lx24-amd64, 6.2u5):
>
> Mem: 16440132k total, 16162000k used, 278132k free, 1760k
> buffers
> Swap: 15631204k total, 560672k used, 15070532k free, 2020072k
> cached
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 3602 g0700703 18 0 505m 283m 6792 R 102.5 1.8 1291:15 vasp-
> mpi-gamma-
> 3603 g0700703 18 0 504m 283m 6792 R 102.5 1.8 1291:12 vasp-
> mpi-gamma-
> 7523 g0700690 25 0 12.7g 12g 231m R 100.5 79.2 167:22.66 green
> 3948 g0700703 25 0 571m 439m 9408 R 98.6 2.7 1137:13 vasp-
> mpi-gamma-
>
> PID 7523 is using 12g, while the qstat for the job shows:
> cpu=02:56:06, mem=22080.33477 GBs, io=0.19387, vmem=1.222G,
> maxvmem=4.030G
>
> I started seeing this problem from 6.2u4 (or u3 I think...). It was ok
> with earlier versions.

can one of them who detects it file an issue please, pointing to this
discussion.

-- Reuti


> rgds,
> --shing
>
> On Tue, 9 Mar 2010, shruti_m wrote:
>
>>
>> Hi All,
>>
>>
>>
>> We recently upgraded one of the sites to 6.2U5. Since the upgrade,
>> we have
>> noticed that vmem and maxvmem values reported by qstat in SGE is
>> much low
>> compared to real time mem consumed by the job and reflected in top
>> output of
>> the system.
>>
>>
>>
>> e.g I submit a job to grab 20G memory and hold it for 300 sec. In top
>> output, I do see my job consuming upto 20G memory for 300 sec…
>> qstat output
>> shows maxvmem to have never exceeded 3G !! It is easibly
>> reproducible on
>> lx24-amd64 systems.
>>
>>
>>
>> Let me know, if anybody else has seen similar behavior.
>>
>>
>>
>> Thanks,
>>
>> Shruti
>>
>>
>>
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?
> dsForumId=38&dsMessageId=247978
>
> To unsubscribe from this discussion, e-mail: [users-
> ***@gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=247983

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=248062

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sun
jching
2010-08-16 19:24:06 UTC
Permalink
Has there been a fix for this? How do you check the SR #? Thanks!

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274813

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
rayson
2010-08-16 19:33:16 UTC
Permalink
Yes, it is fixed in SGE 6.2u6, but as Ron has already mentioned, you
can't use it in production because it is not opensource anymore. And
you need to be an Oracle customer to view the SR.

I have the fix, I will test it again and release the patch.

Rayson



On Mon, Aug 16, 2010 at 3:24 PM, jching <***@bbn.com> wrote:
> Has there been a fix for this?  How do you check the SR #?  Thanks!
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274813
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274815

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
jching
2010-08-17 02:13:20 UTC
Permalink
Oh,is it not possible to do the maintenance patch from 6.2u5 up to 6.2u6?

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274838

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
ron
2010-08-17 02:18:58 UTC
Permalink
Yes you can use 6.2u6, but *make sure* you read the license.

It's a 90-day Evaluation License, so you it would be illegal to use it after 90 days if you don't buy the license.

So, it comes down to, if you have money to spare, then buy from Oracle. And if you don't have money to spare, then wait till Rayson releases the patch and download it free of charge.

Both will have this memory reporting issue fixed.

-Ron



--- On Tue, 8/17/10, jching <***@bbn.com> wrote:
> Oh,is it not possible to do the
> maintenance patch from 6.2u5 up to 6.2u6?
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274838
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274839

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
laotsao
2010-08-17 02:30:29 UTC
Permalink
> It's fixed in SGE 6.2u6. See here:
>
> http://gridengine.sunsource.net/project/gridengine/62patches.txt
>
> I also thought it was introduced with u5 and not with u4.
>
> Andy
so many bug in u5:-(

On 8/16/2010 10:18 PM, ron wrote:
> Yes you can use 6.2u6, but *make sure* you read the license.
>
> It's a 90-day Evaluation License, so you it would be illegal to use it after 90 days if you don't buy the license.
>
> So, it comes down to, if you have money to spare, then buy from Oracle. And if you don't have money to spare, then wait till Rayson releases the patch and download it free of charge.
>
> Both will have this memory reporting issue fixed.
>
> -Ron
>
>
>
> --- On Tue, 8/17/10, jching<***@bbn.com> wrote:
>> Oh,is it not possible to do the
>> maintenance patch from 6.2u5 up to 6.2u6?
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274838
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274839
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274840

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
jching
2010-08-17 02:45:58 UTC
Permalink
Thanks Ron, makes sense to wait for Rayson :)

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274841

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
rayson
2010-08-18 03:17:53 UTC
Permalink
What is your machine's Linux distribution and version?? I will see if
I can build the SGE source tree on a machine that has similar kernel &
glibc version as yours.

If I can find such a machine, or if you know how to build from source,
then you can expect a patch from me later this week or early next
week.

Rayson



On Mon, Aug 16, 2010 at 10:45 PM, jching <***@bbn.com> wrote:
> Thanks Ron, makes sense to wait for Rayson :)
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274841
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275072

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
jenny
2010-08-18 03:42:18 UTC
Permalink
Hi Rayson,

I use rocks v5.3 distributed a cluster, with centos 5.4, gcc 4.1.2, and sge 6.2U4. Can the patch be built?

thanks

Jenny



发件人 rayson
发送时闎 2010-08-18 11:18:43
收件人 users
抄送
䞻题 Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE too low compared to top output on linux systems

What is your machine's Linux distribution and version?? I will see if
I can build the SGE source tree on a machine that has similar kernel &
glibc version as yours.
If I can find such a machine, or if you know how to build from source,
then you can expect a patch from me later this week or early next
week.
Rayson
On Mon, Aug 16, 2010 at 10:45 PM, jching <***@bbn.com> wrote:
> Thanks Ron, makes sense to wait for Rayson :)
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274841
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>
------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275072
To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
__________ Information from ESET NOD32 Antivirus, version of virus signature database 5374 (20100817) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275076

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
rayson
2010-08-18 03:50:27 UTC
Permalink
32-bit or 64-bit?

I am running Fedora Core 13, which has newer versions of everything:
gcc 4.4.4, kernel 2.6.33.6-147.2.4.fc13.x86_64, glibc 2.12. I will see
if I can find an older machine.

Rayson



2010/8/17 jenny <***@genomics.org.cn>:
> Hi Rayson,
>
> I use rocks v5.3 distributed a cluster, with centos 5.4, gcc 4.1.2, and sge
> 6.2U4. Can the patch be built?
>
> thanks
>
> Jenny
> ________________________________
> 发件人: rayson
> 发送时间: 2010-08-18 11:18:43
> 收件人: users
> 抄送:
> 主题: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE
> too low compared to top output on linux systems
> What is your machine's Linux distribution and version?? I will see if
> I can build the SGE source tree on a machine that has similar kernel &
> glibc version as yours.
> If I can find such a machine, or if you know how to build from source,
> then you can expect a patch from me later this week or early next
> week.
> Rayson
> On Mon, Aug 16, 2010 at 10:45 PM, jching <***@bbn.com> wrote:
>> Thanks Ron, makes sense to wait for Rayson :)
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274841
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275072
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 5374 (20100817) __________
> The message was checked by ESET NOD32 Antivirus.
> http://www.eset.com

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275078

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
jenny
2010-08-18 03:54:05 UTC
Permalink
64-bit


2010-08-18



卢䞜花 Jenny_Lu
计算平台
深圳华倧基因研究院
***@genomics.org.cn
Tel:075525273811
Mobile:15986782583 62583



发件人 rayson
发送时闎 2010-08-18 11:51:16
收件人 users
抄送
䞻题 Re: [GE users] Re: Re: Re: [GE users] Issue seen in 6.2U5 : memoryvalues reported bySGE too low compared to top output on linux systems

32-bit or 64-bit?
I am running Fedora Core 13, which has newer versions of everything:
gcc 4.4.4, kernel 2.6.33.6-147.2.4.fc13.x86_64, glibc 2.12. I will see
if I can find an older machine.
Rayson
2010/8/17 jenny <***@genomics.org.cn>:
> Hi Rayson,
>
> I use rocks v5.3 distributed a cluster, with centos 5.4, gcc 4.1.2, and sge
> 6.2U4. Can the patch be built?
>
> thanks
>
> Jenny
> ________________________________
> 发件人 rayson
> 发送时闎 2010-08-18 11:18:43
> 收件人 users
> 抄送
> 䞻题 Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE
> too low compared to top output on linux systems
> What is your machine's Linux distribution and version?? I will see if
> I can build the SGE source tree on a machine that has similar kernel &
> glibc version as yours.
> If I can find such a machine, or if you know how to build from source,
> then you can expect a patch from me later this week or early next
> week.
> Rayson
> On Mon, Aug 16, 2010 at 10:45 PM, jching <***@bbn.com> wrote:
>> Thanks Ron, makes sense to wait for Rayson :)
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274841
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275072
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 5374 (20100817) __________
> The message was checked by ESET NOD32 Antivirus.
> http://www.eset.com
------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275078
To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
__________ Information from ESET NOD32 Antivirus, version of virus signature database 5374 (20100817) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275080

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
laotsao
2010-08-18 04:23:11 UTC
Permalink
may be just install vbox and install rocks5.3

On 8/17/2010 11:50 PM, rayson wrote:
> 32-bit or 64-bit?
>
> I am running Fedora Core 13, which has newer versions of everything:
> gcc 4.4.4, kernel 2.6.33.6-147.2.4.fc13.x86_64, glibc 2.12. I will see
> if I can find an older machine.
>
> Rayson
>
>
>
> 2010/8/17 jenny<***@genomics.org.cn>:
>> Hi Rayson,
>>
>> I use rocks v5.3 distributed a cluster, with centos 5.4, gcc 4.1.2, and sge
>> 6.2U4. Can the patch be built?
>>
>> thanks
>>
>> Jenny
>> ________________________________
>> 发件人 rayson
>> 发送时闎 2010-08-18 11:18:43
>> 收件人 users
>> 抄送
>> 䞻题 Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE
>> too low compared to top output on linux systems
>> What is your machine's Linux distribution and version?? I will see if
>> I can build the SGE source tree on a machine that has similar kernel&
>> glibc version as yours.
>> If I can find such a machine, or if you know how to build from source,
>> then you can expect a patch from me later this week or early next
>> week.
>> Rayson
>> On Mon, Aug 16, 2010 at 10:45 PM, jching<***@bbn.com> wrote:
>>> Thanks Ron, makes sense to wait for Rayson :)
>>>
>>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274841
>>>
>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275072
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>> __________ Information from ESET NOD32 Antivirus, version of virus signature database 5374 (20100817) __________
>> The message was checked by ESET NOD32 Antivirus.
>> http://www.eset.com
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275078
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275085

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
rayson
2010-08-18 04:26:51 UTC
Permalink
That's a good idea, but I don't have enough time to support each
distro. It's 12:30am in Toronto and I am still up :(

Someone interested in providing build support? I guess without Sun, we
will need to handle many things ourselves!

Rayson



On Wed, Aug 18, 2010 at 12:23 AM, LaoTsao 老曹 <***@gmail.com> wrote:
>  may be just install vbox and install rocks5.3
>
> On 8/17/2010 11:50 PM, rayson wrote:
>>
>> 32-bit or 64-bit?
>>
>> I am running Fedora Core 13, which has newer versions of everything:
>> gcc 4.4.4, kernel 2.6.33.6-147.2.4.fc13.x86_64, glibc 2.12. I will see
>> if I can find an older machine.
>>
>> Rayson
>>
>>
>>
>> 2010/8/17 jenny<***@genomics.org.cn>:
>>>
>>> Hi Rayson,
>>>
>>> I use rocks v5.3 distributed a cluster, with centos 5.4, gcc 4.1.2, and
>>> sge
>>> 6.2U4. Can the patch be built?
>>>
>>> thanks
>>>
>>> Jenny
>>> ________________________________
>>> 发件人: rayson
>>> 发送时间: 2010-08-18  11:18:43
>>> 收件人: users
>>> 抄送:
>>> 主题: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE
>>> too low compared to top output on linux systems
>>> What is your machine's Linux distribution and version?? I will see if
>>> I can build the SGE source tree on a machine that has similar kernel&
>>> glibc version as yours.
>>> If I can find such a machine, or if you know how to build from source,
>>> then you can expect a patch from me later this week or early next
>>> week.
>>> Rayson
>>> On Mon, Aug 16, 2010 at 10:45 PM, jching<***@bbn.com>  wrote:
>>>>
>>>> Thanks Ron, makes sense to wait for Rayson :)
>>>>
>>>> ------------------------------------------------------
>>>>
>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274841
>>>>
>>>> To unsubscribe from this discussion, e-mail:
>>>> [users-***@gridengine.sunsource.net].
>>>>
>>> ------------------------------------------------------
>>>
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275072
>>> To unsubscribe from this discussion, e-mail:
>>> [users-***@gridengine.sunsource.net].
>>> __________ Information from ESET NOD32 Antivirus, version of virus
>>> signature database 5374 (20100817) __________
>>> The message was checked by ESET NOD32 Antivirus.
>>> http://www.eset.com
>>
>> ------------------------------------------------------
>>
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275078
>>
>> To unsubscribe from this discussion, e-mail:
>> [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275086

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
jenny
2010-08-18 04:34:04 UTC
Permalink
i'm not familiar with building sge . but i'm pleasure to help if i can.


Jenny




发件人 rayson
发送时闎 2010-08-18 12:27:47
收件人 laotsao
抄送 users
䞻题 Re: [GE users] Re: Re: Re: [GE users] Issue seen in 6.2U5 : memoryvalues reported bySGE too low compared to top output on linux systems

That's a good idea, but I don't have enough time to support each
distro. It's 12:30am in Toronto and I am still up :(
Someone interested in providing build support? I guess without Sun, we
will need to handle many things ourselves!
Rayson
On Wed, Aug 18, 2010 at 12:23 AM, LaoTsao 老曹 <***@gmail.com> wrote:
> may be just install vbox and install rocks5.3
>
> On 8/17/2010 11:50 PM, rayson wrote:
>>
>> 32-bit or 64-bit?
>>
>> I am running Fedora Core 13, which has newer versions of everything:
>> gcc 4.4.4, kernel 2.6.33.6-147.2.4.fc13.x86_64, glibc 2.12. I will see
>> if I can find an older machine.
>>
>> Rayson
>>
>>
>>
>> 2010/8/17 jenny<***@genomics.org.cn>:
>>>
>>> Hi Rayson,
>>>
>>> I use rocks v5.3 distributed a cluster, with centos 5.4, gcc 4.1.2, and
>>> sge
>>> 6.2U4. Can the patch be built?
>>>
>>> thanks
>>>
>>> Jenny
>>> ________________________________
>>> 发件人 rayson
>>> 发送时闎 2010-08-18 11:18:43
>>> 收件人 users
>>> 抄送
>>> 䞻题 Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE
>>> too low compared to top output on linux systems
>>> What is your machine's Linux distribution and version?? I will see if
>>> I can build the SGE source tree on a machine that has similar kernel&
>>> glibc version as yours.
>>> If I can find such a machine, or if you know how to build from source,
>>> then you can expect a patch from me later this week or early next
>>> week.
>>> Rayson
>>> On Mon, Aug 16, 2010 at 10:45 PM, jching<***@bbn.com> wrote:
>>>>
>>>> Thanks Ron, makes sense to wait for Rayson :)
>>>>
>>>> ------------------------------------------------------
>>>>
>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274841
>>>>
>>>> To unsubscribe from this discussion, e-mail:
>>>> [users-***@gridengine.sunsource.net].
>>>>
>>> ------------------------------------------------------
>>>
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275072
>>> To unsubscribe from this discussion, e-mail:
>>> [users-***@gridengine.sunsource.net].
>>> __________ Information from ESET NOD32 Antivirus, version of virus
>>> signature database 5374 (20100817) __________
>>> The message was checked by ESET NOD32 Antivirus.
>>> http://www.eset.com
>>
>> ------------------------------------------------------
>>
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275078
>>
>> To unsubscribe from this discussion, e-mail:
>> [users-***@gridengine.sunsource.net].
>
------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275086
To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
__________ Information from ESET NOD32 Antivirus, version of virus signature database 5374 (20100817) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275087

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
dr_st
2010-08-18 07:22:25 UTC
Permalink
rayson a écrit :
> That's a good idea, but I don't have enough time to support each
> distro. It's 12:30am in Toronto and I am still up :(
>
> Someone interested in providing build support? I guess without Sun, we
> will need to handle many things ourselves!
>
> Rayson
>
>

If you need some help, i'm ok to try to build it against various OSes:
- Mandriva Linux (all versions)
- Fedora (some versions)
- anything else?

I'm already a contributor (packager/developper) for Mandriva, so if i
can help for providing binaries, let me know.

Stéphane

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275127

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
reuti
2010-08-18 07:52:57 UTC
Permalink
Am 18.08.2010 um 06:26 schrieb rayson:

> That's a good idea, but I don't have enough time to support each
> distro. It's 12:30am in Toronto and I am still up :(
>
> Someone interested in providing build support? I guess without Sun, we
> will need to handle many things ourselves!

Well, same what happened to ex OpenPBS is then happening to SGE. What do we need:

- a name
- a place for the stuff, e.g. a sourecforge project
- our own bug tracker
- our own repository
- ...

-- Reuti



> Rayson
>
>
>
> On Wed, Aug 18, 2010 at 12:23 AM, LaoTsao 老曹 <***@gmail.com> wrote:
>> may be just install vbox and install rocks5.3
>>
>> On 8/17/2010 11:50 PM, rayson wrote:
>>>
>>> 32-bit or 64-bit?
>>>
>>> I am running Fedora Core 13, which has newer versions of everything:
>>> gcc 4.4.4, kernel 2.6.33.6-147.2.4.fc13.x86_64, glibc 2.12. I will see
>>> if I can find an older machine.
>>>
>>> Rayson
>>>
>>>
>>>
>>> 2010/8/17 jenny<***@genomics.org.cn>:
>>>>
>>>> Hi Rayson,
>>>>
>>>> I use rocks v5.3 distributed a cluster, with centos 5.4, gcc 4.1.2, and
>>>> sge
>>>> 6.2U4. Can the patch be built?
>>>>
>>>> thanks
>>>>
>>>> Jenny
>>>> ________________________________
>>>> 发件人: rayson
>>>> 发送时间: 2010-08-18 11:18:43
>>>> 收件人: users
>>>> 抄送:
>>>> 主题: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE
>>>> too low compared to top output on linux systems
>>>> What is your machine's Linux distribution and version?? I will see if
>>>> I can build the SGE source tree on a machine that has similar kernel&
>>>> glibc version as yours.
>>>> If I can find such a machine, or if you know how to build from source,
>>>> then you can expect a patch from me later this week or early next
>>>> week.
>>>> Rayson
>>>> On Mon, Aug 16, 2010 at 10:45 PM, jching<***@bbn.com> wrote:
>>>>>
>>>>> Thanks Ron, makes sense to wait for Rayson :)
>>>>>
>>>>> ------------------------------------------------------
>>>>>
>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274841
>>>>>
>>>>> To unsubscribe from this discussion, e-mail:
>>>>> [users-***@gridengine.sunsource.net].
>>>>>
>>>> ------------------------------------------------------
>>>>
>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275072
>>>> To unsubscribe from this discussion, e-mail:
>>>> [users-***@gridengine.sunsource.net].
>>>> __________ Information from ESET NOD32 Antivirus, version of virus
>>>> signature database 5374 (20100817) __________
>>>> The message was checked by ESET NOD32 Antivirus.
>>>> http://www.eset.com
>>>
>>> ------------------------------------------------------
>>>
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275078
>>>
>>> To unsubscribe from this discussion, e-mail:
>>> [users-***@gridengine.sunsource.net].
>>
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275086
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275135

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
rayson
2010-08-18 14:10:12 UTC
Permalink
On Wed, Aug 18, 2010 at 3:52 AM, reuti <***@staff.uni-marburg.de> wrote:
> Well, same what happened to ex OpenPBS is then happening to SGE. What do we need:
>
> - a name
> - a place for the stuff, e.g. a sourecforge project
> - our own bug tracker
> - our own repository
> - ...

Ron and I will work on those.

Rayson




>
> -- Reuti
>
>
>
>> Rayson
>>
>>
>>
>> On Wed, Aug 18, 2010 at 12:23 AM, LaoTsao 老曹 <***@gmail.com> wrote:
>>>  may be just install vbox and install rocks5.3
>>>
>>> On 8/17/2010 11:50 PM, rayson wrote:
>>>>
>>>> 32-bit or 64-bit?
>>>>
>>>> I am running Fedora Core 13, which has newer versions of everything:
>>>> gcc 4.4.4, kernel 2.6.33.6-147.2.4.fc13.x86_64, glibc 2.12. I will see
>>>> if I can find an older machine.
>>>>
>>>> Rayson
>>>>
>>>>
>>>>
>>>> 2010/8/17 jenny<***@genomics.org.cn>:
>>>>>
>>>>> Hi Rayson,
>>>>>
>>>>> I use rocks v5.3 distributed a cluster, with centos 5.4, gcc 4.1.2, and
>>>>> sge
>>>>> 6.2U4. Can the patch be built?
>>>>>
>>>>> thanks
>>>>>
>>>>> Jenny
>>>>> ________________________________
>>>>> 发件人: rayson
>>>>> 发送时间: 2010-08-18  11:18:43
>>>>> 收件人: users
>>>>> 抄送:
>>>>> 主题: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE
>>>>> too low compared to top output on linux systems
>>>>> What is your machine's Linux distribution and version?? I will see if
>>>>> I can build the SGE source tree on a machine that has similar kernel&
>>>>> glibc version as yours.
>>>>> If I can find such a machine, or if you know how to build from source,
>>>>> then you can expect a patch from me later this week or early next
>>>>> week.
>>>>> Rayson
>>>>> On Mon, Aug 16, 2010 at 10:45 PM, jching<***@bbn.com>  wrote:
>>>>>>
>>>>>> Thanks Ron, makes sense to wait for Rayson :)
>>>>>>
>>>>>> ------------------------------------------------------
>>>>>>
>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274841
>>>>>>
>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>> [users-***@gridengine.sunsource.net].
>>>>>>
>>>>> ------------------------------------------------------
>>>>>
>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275072
>>>>> To unsubscribe from this discussion, e-mail:
>>>>> [users-***@gridengine.sunsource.net].
>>>>> __________ Information from ESET NOD32 Antivirus, version of virus
>>>>> signature database 5374 (20100817) __________
>>>>> The message was checked by ESET NOD32 Antivirus.
>>>>> http://www.eset.com
>>>>
>>>> ------------------------------------------------------
>>>>
>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275078
>>>>
>>>> To unsubscribe from this discussion, e-mail:
>>>> [users-***@gridengine.sunsource.net].
>>>
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275086
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275135
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275196

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
ppk
2010-08-18 14:27:49 UTC
Permalink
Thank you Rayson, Ron, Reuti and others.

Prakashan


rayson wrote:
> On Wed, Aug 18, 2010 at 3:52 AM, reuti <***@staff.uni-marburg.de> wrote:
>> Well, same what happened to ex OpenPBS is then happening to SGE. What do we need:
>>
>> - a name
>> - a place for the stuff, e.g. a sourecforge project
>> - our own bug tracker
>> - our own repository
>> - ...
>
> Ron and I will work on those.
>
> Rayson
>
>
>
>
>> -- Reuti
>>
>>
>>
>>> Rayson
>>>
>>>
>>>
>>> On Wed, Aug 18, 2010 at 12:23 AM, LaoTsao 老曹 <***@gmail.com> wrote:
>>>> may be just install vbox and install rocks5.3
>>>>
>>>> On 8/17/2010 11:50 PM, rayson wrote:
>>>>> 32-bit or 64-bit?
>>>>>
>>>>> I am running Fedora Core 13, which has newer versions of everything:
>>>>> gcc 4.4.4, kernel 2.6.33.6-147.2.4.fc13.x86_64, glibc 2.12. I will see
>>>>> if I can find an older machine.
>>>>>
>>>>> Rayson
>>>>>
>>>>>
>>>>>
>>>>> 2010/8/17 jenny<***@genomics.org.cn>:
>>>>>> Hi Rayson,
>>>>>>
>>>>>> I use rocks v5.3 distributed a cluster, with centos 5.4, gcc 4.1.2, and
>>>>>> sge
>>>>>> 6.2U4. Can the patch be built?
>>>>>>
>>>>>> thanks
>>>>>>
>>>>>> Jenny
>>>>>> ________________________________
>>>>>> 发件人: rayson
>>>>>> 发送时间: 2010-08-18 11:18:43
>>>>>> 收件人: users
>>>>>> 抄送:
>>>>>> 主题: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE
>>>>>> too low compared to top output on linux systems
>>>>>> What is your machine's Linux distribution and version?? I will see if
>>>>>> I can build the SGE source tree on a machine that has similar kernel&
>>>>>> glibc version as yours.
>>>>>> If I can find such a machine, or if you know how to build from source,
>>>>>> then you can expect a patch from me later this week or early next
>>>>>> week.
>>>>>> Rayson
>>>>>> On Mon, Aug 16, 2010 at 10:45 PM, jching<***@bbn.com> wrote:
>>>>>>> Thanks Ron, makes sense to wait for Rayson :)
>>>>>>>
>>>>>>> ------------------------------------------------------
>>>>>>>
>>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274841
>>>>>>>
>>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>>> [users-***@gridengine.sunsource.net].
>>>>>>>
>>>>>> ------------------------------------------------------
>>>>>>
>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275072
>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>> [users-***@gridengine.sunsource.net].
>>>>>> __________ Information from ESET NOD32 Antivirus, version of virus
>>>>>> signature database 5374 (20100817) __________
>>>>>> The message was checked by ESET NOD32 Antivirus.
>>>>>> http://www.eset.com
>>>>> ------------------------------------------------------
>>>>>
>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275078
>>>>>
>>>>> To unsubscribe from this discussion, e-mail:
>>>>> [users-***@gridengine.sunsource.net].
>>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275086
>>>
>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275135
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275196
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275205

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
jching
2010-08-18 14:35:24 UTC
Permalink
you guys are awesome! totally appreciated, i'll wait for the source patch so i try to build it form source. thanks again!

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275207

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
laotsao
2010-08-18 14:56:35 UTC
Permalink
I can help to compile codes on
1)Solaris x64
2)linux x64
regards


On 8/18/2010 10:10 AM, rayson wrote:
> On Wed, Aug 18, 2010 at 3:52 AM, reuti<***@staff.uni-marburg.de> wrote:
>> Well, same what happened to ex OpenPBS is then happening to SGE. What do we need:
>>
>> - a name
>> - a place for the stuff, e.g. a sourecforge project
>> - our own bug tracker
>> - our own repository
>> - ...
> Ron and I will work on those.
>
> Rayson
>
>
>
>
>> -- Reuti
>>
>>
>>
>>> Rayson
>>>
>>>
>>>
>>> On Wed, Aug 18, 2010 at 12:23 AM, LaoTsao 老曹<***@gmail.com> wrote:
>>>> may be just install vbox and install rocks5.3
>>>>
>>>> On 8/17/2010 11:50 PM, rayson wrote:
>>>>> 32-bit or 64-bit?
>>>>>
>>>>> I am running Fedora Core 13, which has newer versions of everything:
>>>>> gcc 4.4.4, kernel 2.6.33.6-147.2.4.fc13.x86_64, glibc 2.12. I will see
>>>>> if I can find an older machine.
>>>>>
>>>>> Rayson
>>>>>
>>>>>
>>>>>
>>>>> 2010/8/17 jenny<***@genomics.org.cn>:
>>>>>> Hi Rayson,
>>>>>>
>>>>>> I use rocks v5.3 distributed a cluster, with centos 5.4, gcc 4.1.2, and
>>>>>> sge
>>>>>> 6.2U4. Can the patch be built?
>>>>>>
>>>>>> thanks
>>>>>>
>>>>>> Jenny
>>>>>> ________________________________
>>>>>> 发件人 rayson
>>>>>> 发送时闎 2010-08-18 11:18:43
>>>>>> 收件人 users
>>>>>> 抄送
>>>>>> 䞻题 Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE
>>>>>> too low compared to top output on linux systems
>>>>>> What is your machine's Linux distribution and version?? I will see if
>>>>>> I can build the SGE source tree on a machine that has similar kernel&
>>>>>> glibc version as yours.
>>>>>> If I can find such a machine, or if you know how to build from source,
>>>>>> then you can expect a patch from me later this week or early next
>>>>>> week.
>>>>>> Rayson
>>>>>> On Mon, Aug 16, 2010 at 10:45 PM, jching<***@bbn.com> wrote:
>>>>>>> Thanks Ron, makes sense to wait for Rayson :)
>>>>>>>
>>>>>>> ------------------------------------------------------
>>>>>>>
>>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274841
>>>>>>>
>>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>>> [users-***@gridengine.sunsource.net].
>>>>>>>
>>>>>> ------------------------------------------------------
>>>>>>
>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275072
>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>> [users-***@gridengine.sunsource.net].
>>>>>> __________ Information from ESET NOD32 Antivirus, version of virus
>>>>>> signature database 5374 (20100817) __________
>>>>>> The message was checked by ESET NOD32 Antivirus.
>>>>>> http://www.eset.com
>>>>> ------------------------------------------------------
>>>>>
>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275078
>>>>>
>>>>> To unsubscribe from this discussion, e-mail:
>>>>> [users-***@gridengine.sunsource.net].
>>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275086
>>>
>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275135
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275196
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275220

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
reuti
2010-08-18 16:07:43 UTC
Permalink
Am 18.08.2010 um 16:10 schrieb rayson:

> On Wed, Aug 18, 2010 at 3:52 AM, reuti <***@staff.uni-marburg.de> wrote:
>> Well, same what happened to ex OpenPBS is then happening to SGE. What do we need:
>>
>> - a name
>> - a place for the stuff, e.g. a sourceforge project
>> - our own bug tracker
>> - our own repository
>> - ...
>
> Ron and I will work on those.

- mailing list with better search and sort options (Beowulf's and Torque's mailing list archives I also find hard to use)

Great. Will we also need to copy (if legal) this mailing list archive to somewhere else? AFAIK CollabNet is not free, but paid by someone - when it's shut down, all collected knowledge therein will be lost otherwise.

Maybe this would also be a good point to move to autotools/cmake for the build process at this cut, in favor of any precompiled binaries.

-- Reuti


> Rayson
>
>> -- Reuti
>>
>>> Rayson
>>>
>>> On Wed, Aug 18, 2010 at 12:23 AM, LaoTsao 老曹 <***@gmail.com> wrote:
>>>> may be just install vbox and install rocks5.3
>>>>
>>>> On 8/17/2010 11:50 PM, rayson wrote:
>>>>>
>>>>> 32-bit or 64-bit?
>>>>>
>>>>> I am running Fedora Core 13, which has newer versions of everything:
>>>>> gcc 4.4.4, kernel 2.6.33.6-147.2.4.fc13.x86_64, glibc 2.12. I will see
>>>>> if I can find an older machine.
>>>>>
>>>>> Rayson
>>>>>
>>>>>
>>>>>
>>>>> 2010/8/17 jenny<***@genomics.org.cn>:
>>>>>>
>>>>>> Hi Rayson,
>>>>>>
>>>>>> I use rocks v5.3 distributed a cluster, with centos 5.4, gcc 4.1.2, and
>>>>>> sge
>>>>>> 6.2U4. Can the patch be built?
>>>>>>
>>>>>> thanks
>>>>>>
>>>>>> Jenny
>>>>>> ________________________________
>>>>>> 发件人: rayson
>>>>>> 发送时间: 2010-08-18 11:18:43
>>>>>> 收件人: users
>>>>>> 抄送:
>>>>>> 主题: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE
>>>>>> too low compared to top output on linux systems
>>>>>> What is your machine's Linux distribution and version?? I will see if
>>>>>> I can build the SGE source tree on a machine that has similar kernel&
>>>>>> glibc version as yours.
>>>>>> If I can find such a machine, or if you know how to build from source,
>>>>>> then you can expect a patch from me later this week or early next
>>>>>> week.
>>>>>> Rayson
>>>>>> On Mon, Aug 16, 2010 at 10:45 PM, jching<***@bbn.com> wrote:
>>>>>>>
>>>>>>> Thanks Ron, makes sense to wait for Rayson :)
>>>>>>>
>>>>>>> ------------------------------------------------------
>>>>>>>
>>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274841
>>>>>>>
>>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>>> [users-***@gridengine.sunsource.net].
>>>>>>>
>>>>>> ------------------------------------------------------
>>>>>>
>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275072
>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>> [users-***@gridengine.sunsource.net].
>>>>>> __________ Information from ESET NOD32 Antivirus, version of virus
>>>>>> signature database 5374 (20100817) __________
>>>>>> The message was checked by ESET NOD32 Antivirus.
>>>>>> http://www.eset.com
>>>>>
>>>>> ------------------------------------------------------
>>>>>
>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275078
>>>>>
>>>>> To unsubscribe from this discussion, e-mail:
>>>>> [users-***@gridengine.sunsource.net].
>>>>
>>>
>>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275086
>>>
>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275135
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275196
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275226

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
rayson
2010-08-18 16:35:31 UTC
Permalink
I have successfully built the "Grid Scheduler" (right now it is 100%
identical to SGE 6.2u5) on Linux.

http://sourceforge.net/projects/gridscheduler/

Rayson



On Wed, Aug 18, 2010 at 12:07 PM, reuti <***@staff.uni-marburg.de> wrote:
> Am 18.08.2010 um 16:10 schrieb rayson:
>
>> On Wed, Aug 18, 2010 at 3:52 AM, reuti <***@staff.uni-marburg.de> wrote:
>>> Well, same what happened to ex OpenPBS is then happening to SGE. What do we need:
>>>
>>> - a name
>>> - a place for the stuff, e.g. a sourceforge project
>>> - our own bug tracker
>>> - our own repository
>>> - ...
>>
>> Ron and I will work on those.
>
> - mailing list with better search and sort options (Beowulf's and Torque's mailing list archives I also find hard to use)
>
> Great. Will we also need to copy (if legal) this mailing list archive to somewhere else? AFAIK CollabNet is not free, but paid by someone - when it's shut down, all collected knowledge therein will be lost otherwise.
>
> Maybe this would also be a good point to move to autotools/cmake for the build process at this cut, in favor of any precompiled binaries.
>
> -- Reuti
>
>
>> Rayson
>>
>>> -- Reuti
>>>
>>>> Rayson
>>>>
>>>> On Wed, Aug 18, 2010 at 12:23 AM, LaoTsao 老曹 <***@gmail.com> wrote:
>>>>>  may be just install vbox and install rocks5.3
>>>>>
>>>>> On 8/17/2010 11:50 PM, rayson wrote:
>>>>>>
>>>>>> 32-bit or 64-bit?
>>>>>>
>>>>>> I am running Fedora Core 13, which has newer versions of everything:
>>>>>> gcc 4.4.4, kernel 2.6.33.6-147.2.4.fc13.x86_64, glibc 2.12. I will see
>>>>>> if I can find an older machine.
>>>>>>
>>>>>> Rayson
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2010/8/17 jenny<***@genomics.org.cn>:
>>>>>>>
>>>>>>> Hi Rayson,
>>>>>>>
>>>>>>> I use rocks v5.3 distributed a cluster, with centos 5.4, gcc 4.1.2, and
>>>>>>> sge
>>>>>>> 6.2U4. Can the patch be built?
>>>>>>>
>>>>>>> thanks
>>>>>>>
>>>>>>> Jenny
>>>>>>> ________________________________
>>>>>>> 发件人: rayson
>>>>>>> 发送时间: 2010-08-18  11:18:43
>>>>>>> 收件人: users
>>>>>>> 抄送:
>>>>>>> 主题: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE
>>>>>>> too low compared to top output on linux systems
>>>>>>> What is your machine's Linux distribution and version?? I will see if
>>>>>>> I can build the SGE source tree on a machine that has similar kernel&
>>>>>>> glibc version as yours.
>>>>>>> If I can find such a machine, or if you know how to build from source,
>>>>>>> then you can expect a patch from me later this week or early next
>>>>>>> week.
>>>>>>> Rayson
>>>>>>> On Mon, Aug 16, 2010 at 10:45 PM, jching<***@bbn.com>  wrote:
>>>>>>>>
>>>>>>>> Thanks Ron, makes sense to wait for Rayson :)
>>>>>>>>
>>>>>>>> ------------------------------------------------------
>>>>>>>>
>>>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274841
>>>>>>>>
>>>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>>>> [users-***@gridengine.sunsource.net].
>>>>>>>>
>>>>>>> ------------------------------------------------------
>>>>>>>
>>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275072
>>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>>> [users-***@gridengine.sunsource.net].
>>>>>>> __________ Information from ESET NOD32 Antivirus, version of virus
>>>>>>> signature database 5374 (20100817) __________
>>>>>>> The message was checked by ESET NOD32 Antivirus.
>>>>>>> http://www.eset.com
>>>>>>
>>>>>> ------------------------------------------------------
>>>>>>
>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275078
>>>>>>
>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>> [users-***@gridengine.sunsource.net].
>>>>>
>>>>
>>>> ------------------------------------------------------
>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275086
>>>>
>>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>>
>>>
>>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275135
>>>
>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275196
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275226
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275230

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
ppk
2010-08-18 16:59:58 UTC
Permalink
Thank you Rayson. Great job! Let us know when it is
ready to download and test.

Prakashan


rayson wrote:
> I have successfully built the "Grid Scheduler" (right now it is 100%
> identical to SGE 6.2u5) on Linux.
>
> http://sourceforge.net/projects/gridscheduler/
>
> Rayson
>
>
>
> On Wed, Aug 18, 2010 at 12:07 PM, reuti <***@staff.uni-marburg.de> wrote:
>> Am 18.08.2010 um 16:10 schrieb rayson:
>>
>>> On Wed, Aug 18, 2010 at 3:52 AM, reuti <***@staff.uni-marburg.de> wrote:
>>>> Well, same what happened to ex OpenPBS is then happening to SGE. What do we need:
>>>>
>>>> - a name
>>>> - a place for the stuff, e.g. a sourceforge project
>>>> - our own bug tracker
>>>> - our own repository
>>>> - ...
>>> Ron and I will work on those.
>> - mailing list with better search and sort options (Beowulf's and Torque's mailing list archives I also find hard to use)
>>
>> Great. Will we also need to copy (if legal) this mailing list archive to somewhere else? AFAIK CollabNet is not free, but paid by someone - when it's shut down, all collected knowledge therein will be lost otherwise.
>>
>> Maybe this would also be a good point to move to autotools/cmake for the build process at this cut, in favor of any precompiled binaries.
>>
>> -- Reuti
>>
>>
>>> Rayson
>>>
>>>> -- Reuti
>>>>
>>>>> Rayson
>>>>>
>>>>> On Wed, Aug 18, 2010 at 12:23 AM, LaoTsao 老曹 <***@gmail.com> wrote:
>>>>>> may be just install vbox and install rocks5.3
>>>>>>
>>>>>> On 8/17/2010 11:50 PM, rayson wrote:
>>>>>>> 32-bit or 64-bit?
>>>>>>>
>>>>>>> I am running Fedora Core 13, which has newer versions of everything:
>>>>>>> gcc 4.4.4, kernel 2.6.33.6-147.2.4.fc13.x86_64, glibc 2.12. I will see
>>>>>>> if I can find an older machine.
>>>>>>>
>>>>>>> Rayson
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2010/8/17 jenny<***@genomics.org.cn>:
>>>>>>>> Hi Rayson,
>>>>>>>>
>>>>>>>> I use rocks v5.3 distributed a cluster, with centos 5.4, gcc 4.1.2, and
>>>>>>>> sge
>>>>>>>> 6.2U4. Can the patch be built?
>>>>>>>>
>>>>>>>> thanks
>>>>>>>>
>>>>>>>> Jenny
>>>>>>>> ________________________________
>>>>>>>> 发件人: rayson
>>>>>>>> 发送时间: 2010-08-18 11:18:43
>>>>>>>> 收件人: users
>>>>>>>> 抄送:
>>>>>>>> 主题: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE
>>>>>>>> too low compared to top output on linux systems
>>>>>>>> What is your machine's Linux distribution and version?? I will see if
>>>>>>>> I can build the SGE source tree on a machine that has similar kernel&
>>>>>>>> glibc version as yours.
>>>>>>>> If I can find such a machine, or if you know how to build from source,
>>>>>>>> then you can expect a patch from me later this week or early next
>>>>>>>> week.
>>>>>>>> Rayson
>>>>>>>> On Mon, Aug 16, 2010 at 10:45 PM, jching<***@bbn.com> wrote:
>>>>>>>>> Thanks Ron, makes sense to wait for Rayson :)
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------
>>>>>>>>>
>>>>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274841
>>>>>>>>>
>>>>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>>>>> [users-***@gridengine.sunsource.net].
>>>>>>>>>
>>>>>>>> ------------------------------------------------------
>>>>>>>>
>>>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275072
>>>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>>>> [users-***@gridengine.sunsource.net].
>>>>>>>> __________ Information from ESET NOD32 Antivirus, version of virus
>>>>>>>> signature database 5374 (20100817) __________
>>>>>>>> The message was checked by ESET NOD32 Antivirus.
>>>>>>>> http://www.eset.com
>>>>>>> ------------------------------------------------------
>>>>>>>
>>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275078
>>>>>>>
>>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>>> [users-***@gridengine.sunsource.net].
>>>>> ------------------------------------------------------
>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275086
>>>>>
>>>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>>>
>>>> ------------------------------------------------------
>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275135
>>>>
>>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>>
>>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275196
>>>
>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275226
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275230
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275235

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
bdbaddog
2010-08-19 05:04:24 UTC
Permalink
Gents,

Subversion for the repository?
Didn't want to go with git or hg? (Support distributed work more easily?)

-Bill

On Wed, Aug 18, 2010 at 9:59 AM, ppk <***@ats.ucla.edu> wrote:
> Thank you Rayson.   Great job!   Let us know when it is
> ready to download and test.
>
> Prakashan
>
>
> rayson wrote:
>> I have successfully built the "Grid Scheduler" (right now it is 100%
>> identical to SGE 6.2u5) on Linux.
>>
>> http://sourceforge.net/projects/gridscheduler/
>>
>> Rayson
>>
>>
>>
>> On Wed, Aug 18, 2010 at 12:07 PM, reuti <***@staff.uni-marburg.de> wrote:
>>> Am 18.08.2010 um 16:10 schrieb rayson:
>>>
>>>> On Wed, Aug 18, 2010 at 3:52 AM, reuti <***@staff.uni-marburg.de> wrote:
>>>>> Well, same what happened to ex OpenPBS is then happening to SGE. What do we need:
>>>>>
>>>>> - a name
>>>>> - a place for the stuff, e.g. a sourceforge project
>>>>> - our own bug tracker
>>>>> - our own repository
>>>>> - ...
>>>> Ron and I will work on those.
>>> - mailing list with better search and sort options (Beowulf's and Torque's mailing list archives I also find hard to use)
>>>
>>> Great. Will we also need to copy (if legal) this mailing list archive to somewhere else? AFAIK CollabNet is not free, but paid by someone - when it's shut down, all collected knowledge therein will be lost otherwise.
>>>
>>> Maybe this would also be a good point to move to autotools/cmake for the build process at this cut, in favor of any precompiled binaries.
>>>
>>> -- Reuti
>>>
>>>
>>>> Rayson
>>>>
>>>>> -- Reuti
>>>>>
>>>>>> Rayson
>>>>>>
>>>>>> On Wed, Aug 18, 2010 at 12:23 AM, LaoTsao 老曹 <***@gmail.com> wrote:
>>>>>>>  may be just install vbox and install rocks5.3
>>>>>>>
>>>>>>> On 8/17/2010 11:50 PM, rayson wrote:
>>>>>>>> 32-bit or 64-bit?
>>>>>>>>
>>>>>>>> I am running Fedora Core 13, which has newer versions of everything:
>>>>>>>> gcc 4.4.4, kernel 2.6.33.6-147.2.4.fc13.x86_64, glibc 2.12. I will see
>>>>>>>> if I can find an older machine.
>>>>>>>>
>>>>>>>> Rayson
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2010/8/17 jenny<***@genomics.org.cn>:
>>>>>>>>> Hi Rayson,
>>>>>>>>>
>>>>>>>>> I use rocks v5.3 distributed a cluster, with centos 5.4, gcc 4.1.2, and
>>>>>>>>> sge
>>>>>>>>> 6.2U4. Can the patch be built?
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>>
>>>>>>>>> Jenny
>>>>>>>>> ________________________________
>>>>>>>>> 发件人: rayson
>>>>>>>>> 发送时间: 2010-08-18  11:18:43
>>>>>>>>> 收件人: users
>>>>>>>>> 抄送:
>>>>>>>>> 主题: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE
>>>>>>>>> too low compared to top output on linux systems
>>>>>>>>> What is your machine's Linux distribution and version?? I will see if
>>>>>>>>> I can build the SGE source tree on a machine that has similar kernel&
>>>>>>>>> glibc version as yours.
>>>>>>>>> If I can find such a machine, or if you know how to build from source,
>>>>>>>>> then you can expect a patch from me later this week or early next
>>>>>>>>> week.
>>>>>>>>> Rayson
>>>>>>>>> On Mon, Aug 16, 2010 at 10:45 PM, jching<***@bbn.com>  wrote:
>>>>>>>>>> Thanks Ron, makes sense to wait for Rayson :)
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274841
>>>>>>>>>>
>>>>>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>>>>>> [users-***@gridengine.sunsource.net].
>>>>>>>>>>
>>>>>>>>> ------------------------------------------------------
>>>>>>>>>
>>>>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275072
>>>>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>>>>> [users-***@gridengine.sunsource.net].
>>>>>>>>> __________ Information from ESET NOD32 Antivirus, version of virus
>>>>>>>>> signature database 5374 (20100817) __________
>>>>>>>>> The message was checked by ESET NOD32 Antivirus.
>>>>>>>>> http://www.eset.com
>>>>>>>> ------------------------------------------------------
>>>>>>>>
>>>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275078
>>>>>>>>
>>>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>>>> [users-***@gridengine.sunsource.net].
>>>>>> ------------------------------------------------------
>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275086
>>>>>>
>>>>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>>>>
>>>>> ------------------------------------------------------
>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275135
>>>>>
>>>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>>>
>>>> ------------------------------------------------------
>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275196
>>>>
>>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>>
>>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275226
>>>
>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275230
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275235
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275305

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
mhanby
2010-08-19 14:38:24 UTC
Permalink
My vote is distributed and Git.

-----Original Message-----
From: bdbaddog [mailto:***@baddogconsulting.com]
Sent: Thursday, August 19, 2010 12:04 AM
To: ***@gridengine.sunsource.net
Subject: Re: [GE users] Followup project

Gents,

Subversion for the repository?
Didn't want to go with git or hg? (Support distributed work more easily?)

-Bill

On Wed, Aug 18, 2010 at 9:59 AM, ppk <***@ats.ucla.edu> wrote:
> Thank you Rayson.   Great job!   Let us know when it is
> ready to download and test.
>
> Prakashan
>
>
> rayson wrote:
>> I have successfully built the "Grid Scheduler" (right now it is 100%
>> identical to SGE 6.2u5) on Linux.
>>
>> http://sourceforge.net/projects/gridscheduler/
>>
>> Rayson
>>
>>
>>
>> On Wed, Aug 18, 2010 at 12:07 PM, reuti <***@staff.uni-marburg.de> wrote:
>>> Am 18.08.2010 um 16:10 schrieb rayson:
>>>
>>>> On Wed, Aug 18, 2010 at 3:52 AM, reuti <***@staff.uni-marburg.de> wrote:
>>>>> Well, same what happened to ex OpenPBS is then happening to SGE. What do we need:
>>>>>
>>>>> - a name
>>>>> - a place for the stuff, e.g. a sourceforge project
>>>>> - our own bug tracker
>>>>> - our own repository
>>>>> - ...
>>>> Ron and I will work on those.
>>> - mailing list with better search and sort options (Beowulf's and Torque's mailing list archives I also find hard to use)
>>>
>>> Great. Will we also need to copy (if legal) this mailing list archive to somewhere else? AFAIK CollabNet is not free, but paid by someone - when it's shut down, all collected knowledge therein will be lost otherwise.
>>>
>>> Maybe this would also be a good point to move to autotools/cmake for the build process at this cut, in favor of any precompiled binaries.
>>>
>>> -- Reuti
>>>
>>>
>>>> Rayson
>>>>
>>>>> -- Reuti
>>>>>
>>>>>> Rayson
>>>>>>
>>>>>> On Wed, Aug 18, 2010 at 12:23 AM, LaoTsao 老曹 <***@gmail.com> wrote:
>>>>>>>  may be just install vbox and install rocks5.3
>>>>>>>
>>>>>>> On 8/17/2010 11:50 PM, rayson wrote:
>>>>>>>> 32-bit or 64-bit?
>>>>>>>>
>>>>>>>> I am running Fedora Core 13, which has newer versions of everything:
>>>>>>>> gcc 4.4.4, kernel 2.6.33.6-147.2.4.fc13.x86_64, glibc 2.12. I will see
>>>>>>>> if I can find an older machine.
>>>>>>>>
>>>>>>>> Rayson
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2010/8/17 jenny<***@genomics.org.cn>:
>>>>>>>>> Hi Rayson,
>>>>>>>>>
>>>>>>>>> I use rocks v5.3 distributed a cluster, with centos 5.4, gcc 4.1.2, and
>>>>>>>>> sge
>>>>>>>>> 6.2U4. Can the patch be built?
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>>
>>>>>>>>> Jenny
>>>>>>>>> ________________________________
>>>>>>>>> 发件人: rayson
>>>>>>>>> 发送时间: 2010-08-18  11:18:43
>>>>>>>>> 收件人: users
>>>>>>>>> 抄送:
>>>>>>>>> 主题: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE
>>>>>>>>> too low compared to top output on linux systems
>>>>>>>>> What is your machine's Linux distribution and version?? I will see if
>>>>>>>>> I can build the SGE source tree on a machine that has similar kernel&
>>>>>>>>> glibc version as yours.
>>>>>>>>> If I can find such a machine, or if you know how to build from source,
>>>>>>>>> then you can expect a patch from me later this week or early next
>>>>>>>>> week.
>>>>>>>>> Rayson
>>>>>>>>> On Mon, Aug 16, 2010 at 10:45 PM, jching<***@bbn.com>  wrote:
>>>>>>>>>> Thanks Ron, makes sense to wait for Rayson :)
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274841
>>>>>>>>>>
>>>>>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>>>>>> [users-***@gridengine.sunsource.net].
>>>>>>>>>>
>>>>>>>>> ------------------------------------------------------
>>>>>>>>>
>>>>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275072
>>>>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>>>>> [users-***@gridengine.sunsource.net].
>>>>>>>>> __________ Information from ESET NOD32 Antivirus, version of virus
>>>>>>>>> signature database 5374 (20100817) __________
>>>>>>>>> The message was checked by ESET NOD32 Antivirus.
>>>>>>>>> http://www.eset.com
>>>>>>>> ------------------------------------------------------
>>>>>>>>
>>>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275078
>>>>>>>>
>>>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>>>> [users-***@gridengine.sunsource.net].
>>>>>> ------------------------------------------------------
>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275086
>>>>>>
>>>>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>>>>
>>>>> ------------------------------------------------------
>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275135
>>>>>
>>>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>>>
>>>> ------------------------------------------------------
>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275196
>>>>
>>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>>
>>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275226
>>>
>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275230
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275235
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275305

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275472

To unsubscribe from this discussion, e-mail: [users-
rumpelkeks
2010-08-19 15:52:26 UTC
Permalink
Hello,

willing to help as well, can't promise how much I can do though. Might
be able to do some packaging (Red Hat Enterprise 32 and 64 bit, possibly
Debian); I can probably do some testing.

Would not go for subversion for any new project. I'd second the vote for
git.

I'd quite definitely second moving to 'standard' automake or cmake
tools; that would be quite some improvement.

License wise, I'd say GPL. Especially if there's some considering of
incorporating other GNU tools (like the batch scheduler).

Tina

mhanby wrote:
> My vote is distributed and Git.
>
> -----Original Message-----
> From: bdbaddog [mailto:***@baddogconsulting.com]
> Sent: Thursday, August 19, 2010 12:04 AM
> To: ***@gridengine.sunsource.net
> Subject: Re: [GE users] Followup project
>
> Gents,
>
> Subversion for the repository?
> Didn't want to go with git or hg? (Support distributed work more easily?)
>
> -Bill
>
> On Wed, Aug 18, 2010 at 9:59 AM, ppk <***@ats.ucla.edu> wrote:
>> Thank you Rayson. Great job! Let us know when it is
>> ready to download and test.
>>
>> Prakashan
>>
>>
>> rayson wrote:
>>> I have successfully built the "Grid Scheduler" (right now it is 100%
>>> identical to SGE 6.2u5) on Linux.
>>>
>>> http://sourceforge.net/projects/gridscheduler/
>>>
>>> Rayson
>>>
>>>
>>>
>>> On Wed, Aug 18, 2010 at 12:07 PM, reuti <***@staff.uni-marburg.de> wrote:
>>>> Am 18.08.2010 um 16:10 schrieb rayson:
>>>>
>>>>> On Wed, Aug 18, 2010 at 3:52 AM, reuti <***@staff.uni-marburg.de> wrote:
>>>>>> Well, same what happened to ex OpenPBS is then happening to SGE. What do we need:
>>>>>>
>>>>>> - a name
>>>>>> - a place for the stuff, e.g. a sourceforge project
>>>>>> - our own bug tracker
>>>>>> - our own repository
>>>>>> - ...
>>>>> Ron and I will work on those.
>>>> - mailing list with better search and sort options (Beowulf's and Torque's mailing list archives I also find hard to use)
>>>>
>>>> Great. Will we also need to copy (if legal) this mailing list archive to somewhere else? AFAIK CollabNet is not free, but paid by someone - when it's shut down, all collected knowledge therein will be lost otherwise.
>>>>
>>>> Maybe this would also be a good point to move to autotools/cmake for the build process at this cut, in favor of any precompiled binaries.
>>>>
>>>> -- Reuti
>>>>
>>>>
>>>>> Rayson
>>>>>
>>>>>> -- Reuti
>>>>>>
>>>>>>> Rayson
>>>>>>>
>>>>>>> On Wed, Aug 18, 2010 at 12:23 AM, LaoTsao 老曹 <***@gmail.com> wrote:
>>>>>>>> may be just install vbox and install rocks5.3
>>>>>>>>
>>>>>>>> On 8/17/2010 11:50 PM, rayson wrote:
>>>>>>>>> 32-bit or 64-bit?
>>>>>>>>>
>>>>>>>>> I am running Fedora Core 13, which has newer versions of everything:
>>>>>>>>> gcc 4.4.4, kernel 2.6.33.6-147.2.4.fc13.x86_64, glibc 2.12. I will see
>>>>>>>>> if I can find an older machine.
>>>>>>>>>
>>>>>>>>> Rayson
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2010/8/17 jenny<***@genomics.org.cn>:
>>>>>>>>>> Hi Rayson,
>>>>>>>>>>
>>>>>>>>>> I use rocks v5.3 distributed a cluster, with centos 5.4, gcc 4.1.2, and
>>>>>>>>>> sge
>>>>>>>>>> 6.2U4. Can the patch be built?
>>>>>>>>>>
>>>>>>>>>> thanks
>>>>>>>>>>
>>>>>>>>>> Jenny
>>>>>>>>>> ________________________________
>>>>>>>>>> 发件人: rayson
>>>>>>>>>> 发送时间: 2010-08-18 11:18:43
>>>>>>>>>> 收件人: users
>>>>>>>>>> 抄送:
>>>>>>>>>> 主题: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE
>>>>>>>>>> too low compared to top output on linux systems
>>>>>>>>>> What is your machine's Linux distribution and version?? I will see if
>>>>>>>>>> I can build the SGE source tree on a machine that has similar kernel&
>>>>>>>>>> glibc version as yours.
>>>>>>>>>> If I can find such a machine, or if you know how to build from source,
>>>>>>>>>> then you can expect a patch from me later this week or early next
>>>>>>>>>> week.
>>>>>>>>>> Rayson
>>>>>>>>>> On Mon, Aug 16, 2010 at 10:45 PM, jching<***@bbn.com> wrote:
>>>>>>>>>>> Thanks Ron, makes sense to wait for Rayson :)
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274841
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>>>>>>> [users-***@gridengine.sunsource.net].
>>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275072
>>>>>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>>>>>> [users-***@gridengine.sunsource.net].
>>>>>>>>>> __________ Information from ESET NOD32 Antivirus, version of virus
>>>>>>>>>> signature database 5374 (20100817) __________
>>>>>>>>>> The message was checked by ESET NOD32 Antivirus.
>>>>>>>>>> http://www.eset.com
>>>>>>>>> ------------------------------------------------------
>>>>>>>>>
>>>>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275078
>>>>>>>>>
>>>>>>>>> To unsubscribe from this discussion, e-mail:
>>>>>>>>> [users-***@gridengine.sunsource.net].
>>>>>>> ------------------------------------------------------
>>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275086
>>>>>>>
>>>>>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>>>>>
>>>>>> ------------------------------------------------------
>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275135
>>>>>>
>>>>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>>>>
>>>>> ------------------------------------------------------
>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275196
>>>>>
>>>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>>>
>>>> ------------------------------------------------------
>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275226
>>>>
>>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>>
>>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275230
>>>
>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275235
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275305
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275472
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].


--
Tina Friedrich, Computer Systems Administrator, Diamond Light Source Ltd
Diamond House, Harwell Science and Innovation Campus - 01235 77 8442

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275490

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
joelandman
2010-08-19 15:57:29 UTC
Permalink
Let me ask a (somewhat obvious) set of questions.

Is there any possibility that this project could be shut down due to
Oracle flexing legal muscle? That is, DanT looks like his group has
funding and a roadmap, and they might not take too kindly to an external
group building a relicensed version. Nor give their permission for
relicensure.



--
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics Inc.
email: ***@scalableinformatics.com
web : http://scalableinformatics.com
http://scalableinformatics.com/jackrabbit
phone: +1 734 786 8423 x121
fax : +1 866 888 3112
cell : +1 734 612 4615

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275491

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
ppk
2010-08-19 16:15:36 UTC
Permalink
It appears to me so far all the efforts to the Open Grid
Scheduler is coming from individuals volunteering to help.
We are not stealing anything. We are just reusing what is
already available to us in the open source form and sharing
among us. It is just my common sense thinking. :-)

Prakashan



joelandman wrote:
> Let me ask a (somewhat obvious) set of questions.
>
> Is there any possibility that this project could be shut down due to
> Oracle flexing legal muscle? That is, DanT looks like his group has
> funding and a roadmap, and they might not take too kindly to an external
> group building a relicensed version. Nor give their permission for
> relicensure.
>
>
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275495

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
joelandman
2010-08-19 16:23:35 UTC
Permalink
ppk wrote:
> It appears to me so far all the efforts to the Open Grid
> Scheduler is coming from individuals volunteering to help.
> We are not stealing anything. We are just reusing what is
> already available to us in the open source form and sharing
> among us. It is just my common sense thinking. :-)
>
> Prakashan

Hi Prakashan

My concern is that if the folks who own the IP in the code decide to
start asserting that ownership in a way that makes it hard for us to
work with this/contribute.

We want to. I just don't want us to run afoul of other peoples
property.

Yes it is "open source" (its not GPL2 as I remember, I don't remember
which license it is). No one is accusing anyone of stealing. Someone
owns that IP, and that ownership isn't dropped as part of using an OSS
license. They can take all their marbles and go home. What I am hoping
is that with some rebranding and removal of the copyrighted info, this
can continue.

Again, this is something we may be able to commit resources to. I
just want to know we aren't going to get slapped down for doing it.

Joe

>
>
>
> joelandman wrote:
>> Let me ask a (somewhat obvious) set of questions.
>>
>> Is there any possibility that this project could be shut down due to
>> Oracle flexing legal muscle? That is, DanT looks like his group has
>> funding and a roadmap, and they might not take too kindly to an external
>> group building a relicensed version. Nor give their permission for
>> relicensure.
>>
>>
>>
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275495
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].


--
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics Inc.
email: ***@scalableinformatics.com
web : http://scalableinformatics.com
http://scalableinformatics.com/jackrabbit
phone: +1 734 786 8423 x121
fax : +1 866 888 3112
cell : +1 734 612 4615

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275496

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
ppk
2010-08-19 16:33:38 UTC
Permalink
Hi Joe,

Here is the license description.
http://gridengine.sunsource.net/Gridengine_SISSL_license.html

Prakashan



joelandman wrote:
> ppk wrote:
>> It appears to me so far all the efforts to the Open Grid
>> Scheduler is coming from individuals volunteering to help.
>> We are not stealing anything. We are just reusing what is
>> already available to us in the open source form and sharing
>> among us. It is just my common sense thinking. :-)
>>
>> Prakashan
>
> Hi Prakashan
>
> My concern is that if the folks who own the IP in the code decide to
> start asserting that ownership in a way that makes it hard for us to
> work with this/contribute.
>
> We want to. I just don't want us to run afoul of other peoples
> property.
>
> Yes it is "open source" (its not GPL2 as I remember, I don't remember
> which license it is). No one is accusing anyone of stealing. Someone
> owns that IP, and that ownership isn't dropped as part of using an OSS
> license. They can take all their marbles and go home. What I am hoping
> is that with some rebranding and removal of the copyrighted info, this
> can continue.
>
> Again, this is something we may be able to commit resources to. I
> just want to know we aren't going to get slapped down for doing it.
>
> Joe
>
>>
>>
>> joelandman wrote:
>>> Let me ask a (somewhat obvious) set of questions.
>>>
>>> Is there any possibility that this project could be shut down due to
>>> Oracle flexing legal muscle? That is, DanT looks like his group has
>>> funding and a roadmap, and they might not take too kindly to an external
>>> group building a relicensed version. Nor give their permission for
>>> relicensure.
>>>
>>>
>>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275495
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275499

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
andy
2010-08-20 07:38:17 UTC
Permalink
Joe,

> Let me ask a (somewhat obvious) set of questions.
>
> Is there any possibility that this project could be shut down due to
> Oracle flexing legal muscle? That is, DanT looks like his group has
> funding and a roadmap, and they might not take too kindly to an external
> group building a relicensed version. Nor give their permission for
> relicensure.

your question raises a fair concern and needs to be asked here. No one,
neither contributing as an individual nor by representing a company
wants to get involved in any legal troubles when kicking off a
community-led fork of the Grid Engine project.

Though I'm now a Oracle employee and an old-timer in the Grid Engine
engineering team since 16 years I can't speak for Oracle here. So I just
can share my personal view: As I always understood the SISSL license
gives the freedom to anyone to take the code and create a fork - even
commercial versions seem to be allowed if the requirements of the SISSL
are met. I agree a statement or clarification and explanation what can
be done and what not were helpful.

And the legal question is not only about the code: I could not give an
answer under which license the Issuezilla database and mailing list
archives had been made available. That needs to be answered as well.

Undoubtedly the vast effort of all contributions with new feature
development and bug fixing was contributed by Sun in the past 9 years
since we went open source in June 2001. There were a few code
contributions from our community (think about the array job
interdependencies) and there was help with porting to new OS platforms
(the most important certainly was the initial port to Mac OS X). In my
view the greatest asset which had been created was the incredible
adoption of Grid Engine and this tremendously active, helpful and
positive mailing lists in the Grid Engine project. Also the many issues
and bugs which had been reported by our community helped us to improve
the quality of the Grid Engine code and helped others to get fixes
before they ran into it as well. No doubt, that helped our paying
customers as well.

All of you who are in the software business know what's the price tag of
developing new features and fixing bugs. There are numbers which say a
single bug on average costs more than $10k to fix. What I'm wondering is
if the community will be able to sustain the code quality of the current
feature set - and what's about new development or complete new modules
which address new needs, like the Service Domain Manager? This thread
originally has started with a memory reporting regression on Linux. That
bug was easy to fix. Others we fixed in 6.2u6 (see here
http://gridengine.sunsource.net/project/gridengine/62patches.txt) took
even us many, many person weeks to analyze and solve them, not talking
about the QA team and lab and the continuous investment in the testsuite
to ensure and improve the quality of the released code on all of the
supported platforms.

There's certainly quite some risk for anyone who is responsible for
running clusters where every hour hundreds, thousands or tens of
thousands CPU hours are waiting to kept busy and keep the company behind
running. So is the assumed zero price tag worth the money you will lose
if the DRM system of your choice does not work? Our customers are giving
us figures which say that hardware, electricity, cooling,
administration, OS licenses, DRM system licenses only make up one third
of their costs. The remaining money goes into the licenses of the
software which runs in the grid. Not talking about the labor costs for
the engineers using the Grid. So can the license and support costs of a
DRM system have any cost saving potential when you compare it with the
value it adds to the bulk of hardware in a data center?

Regards,
Andy
---
Snr Software Development Manager, Grid Engine
ORACLE Deutschland B.V. & Co. KG
Dr.-Leo-Ritter-Str. 7
D-93049 Regensburg
---
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275622

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
laotsao
2010-08-20 08:45:54 UTC
Permalink
IMHO, most user will be happy if oracle provide
1)pay version that has more features and access to patches
2)opensource version that include bug fixes but limited features

oracle need to have roadmap/direction on all opensource project
1)gridengine (??)
2)Solaris (Solsris 11 and some source?)
3)lustre (??)
4)openoffice (two versions?)
5)openDS (no future?)
6)openSSO (no future?)
7)MySQL (two versions)
etc

On 8/20/2010 3:38 AM, andy wrote:
> Joe,
>
> > Let me ask a (somewhat obvious) set of questions.
> >
> > Is there any possibility that this project could be shut down due to
> > Oracle flexing legal muscle? That is, DanT looks like his group has
> > funding and a roadmap, and they might not take too kindly to an external
> > group building a relicensed version. Nor give their permission for
> > relicensure.
>
> your question raises a fair concern and needs to be asked here. No one,
> neither contributing as an individual nor by representing a company
> wants to get involved in any legal troubles when kicking off a
> community-led fork of the Grid Engine project.
>
> Though I'm now a Oracle employee and an old-timer in the Grid Engine
> engineering team since 16 years I can't speak for Oracle here. So I just
> can share my personal view: As I always understood the SISSL license
> gives the freedom to anyone to take the code and create a fork - even
> commercial versions seem to be allowed if the requirements of the SISSL
> are met. I agree a statement or clarification and explanation what can
> be done and what not were helpful.
>
> And the legal question is not only about the code: I could not give an
> answer under which license the Issuezilla database and mailing list
> archives had been made available. That needs to be answered as well.
>
> Undoubtedly the vast effort of all contributions with new feature
> development and bug fixing was contributed by Sun in the past 9 years
> since we went open source in June 2001. There were a few code
> contributions from our community (think about the array job
> interdependencies) and there was help with porting to new OS platforms
> (the most important certainly was the initial port to Mac OS X). In my
> view the greatest asset which had been created was the incredible
> adoption of Grid Engine and this tremendously active, helpful and
> positive mailing lists in the Grid Engine project. Also the many issues
> and bugs which had been reported by our community helped us to improve
> the quality of the Grid Engine code and helped others to get fixes
> before they ran into it as well. No doubt, that helped our paying
> customers as well.
>
> All of you who are in the software business know what's the price tag of
> developing new features and fixing bugs. There are numbers which say a
> single bug on average costs more than $10k to fix. What I'm wondering is
> if the community will be able to sustain the code quality of the current
> feature set - and what's about new development or complete new modules
> which address new needs, like the Service Domain Manager? This thread
> originally has started with a memory reporting regression on Linux. That
> bug was easy to fix. Others we fixed in 6.2u6 (see here
> http://gridengine.sunsource.net/project/gridengine/62patches.txt) took
> even us many, many person weeks to analyze and solve them, not talking
> about the QA team and lab and the continuous investment in the testsuite
> to ensure and improve the quality of the released code on all of the
> supported platforms.
>
> There's certainly quite some risk for anyone who is responsible for
> running clusters where every hour hundreds, thousands or tens of
> thousands CPU hours are waiting to kept busy and keep the company behind
> running. So is the assumed zero price tag worth the money you will lose
> if the DRM system of your choice does not work? Our customers are giving
> us figures which say that hardware, electricity, cooling,
> administration, OS licenses, DRM system licenses only make up one third
> of their costs. The remaining money goes into the licenses of the
> software which runs in the grid. Not talking about the labor costs for
> the engineers using the Grid. So can the license and support costs of a
> DRM system have any cost saving potential when you compare it with the
> value it adds to the bulk of hardware in a data center?
>
> Regards,
> Andy
> ---
> Snr Software Development Manager, Grid Engine
> ORACLE Deutschland B.V.& Co. KG
> Dr.-Leo-Ritter-Str. 7
> D-93049 Regensburg
> ---
> ORACLE Deutschland B.V.& Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 MÃŒnchen
> Registergericht: Amtsgericht MÃŒnchen, HRA 95603
> KomplementÀrin: ORACLE Deutschland Verwaltung B.V.
> Rijnzathe 6, 3454PV De Meern, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> GeschÀftsfÌhrer: JÌrgen Kunz, Marcel van de Molen, Alexander van der Ven
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275622
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275642

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
laotsao
2010-08-20 09:24:10 UTC
Permalink
of course user can always move to other opensource DRM if the
opensource gridengine doesnot meet their need:-(


On 8/20/2010 4:45 AM, LaoTsao 老曹 wrote:
>
> IMHO, most user will be happy if oracle provide
> 1)pay version that has more features and access to patches
> 2)opensource version that include bug fixes but limited features
>
> oracle need to have roadmap/direction on all opensource project
> 1)gridengine (??)
> 2)Solaris (Solsris 11 and some source?)
> 3)lustre (??)
> 4)openoffice (two versions?)
> 5)openDS (no future?)
> 6)openSSO (no future?)
> 7)MySQL (two versions)
> etc
>
> On 8/20/2010 3:38 AM, andy wrote:
>> Joe,
>>
>> > Let me ask a (somewhat obvious) set of questions.
>> >
>> > Is there any possibility that this project could be shut down due to
>> > Oracle flexing legal muscle? That is, DanT looks like his group has
>> > funding and a roadmap, and they might not take too kindly to an
>> external
>> > group building a relicensed version. Nor give their permission for
>> > relicensure.
>>
>> your question raises a fair concern and needs to be asked here. No one,
>> neither contributing as an individual nor by representing a company
>> wants to get involved in any legal troubles when kicking off a
>> community-led fork of the Grid Engine project.
>>
>> Though I'm now a Oracle employee and an old-timer in the Grid Engine
>> engineering team since 16 years I can't speak for Oracle here. So I just
>> can share my personal view: As I always understood the SISSL license
>> gives the freedom to anyone to take the code and create a fork - even
>> commercial versions seem to be allowed if the requirements of the SISSL
>> are met. I agree a statement or clarification and explanation what can
>> be done and what not were helpful.
>>
>> And the legal question is not only about the code: I could not give an
>> answer under which license the Issuezilla database and mailing list
>> archives had been made available. That needs to be answered as well.
>>
>> Undoubtedly the vast effort of all contributions with new feature
>> development and bug fixing was contributed by Sun in the past 9 years
>> since we went open source in June 2001. There were a few code
>> contributions from our community (think about the array job
>> interdependencies) and there was help with porting to new OS platforms
>> (the most important certainly was the initial port to Mac OS X). In my
>> view the greatest asset which had been created was the incredible
>> adoption of Grid Engine and this tremendously active, helpful and
>> positive mailing lists in the Grid Engine project. Also the many issues
>> and bugs which had been reported by our community helped us to improve
>> the quality of the Grid Engine code and helped others to get fixes
>> before they ran into it as well. No doubt, that helped our paying
>> customers as well.
>>
>> All of you who are in the software business know what's the price tag of
>> developing new features and fixing bugs. There are numbers which say a
>> single bug on average costs more than $10k to fix. What I'm wondering is
>> if the community will be able to sustain the code quality of the current
>> feature set - and what's about new development or complete new modules
>> which address new needs, like the Service Domain Manager? This thread
>> originally has started with a memory reporting regression on Linux. That
>> bug was easy to fix. Others we fixed in 6.2u6 (see here
>> http://gridengine.sunsource.net/project/gridengine/62patches.txt) took
>> even us many, many person weeks to analyze and solve them, not talking
>> about the QA team and lab and the continuous investment in the testsuite
>> to ensure and improve the quality of the released code on all of the
>> supported platforms.
>>
>> There's certainly quite some risk for anyone who is responsible for
>> running clusters where every hour hundreds, thousands or tens of
>> thousands CPU hours are waiting to kept busy and keep the company behind
>> running. So is the assumed zero price tag worth the money you will lose
>> if the DRM system of your choice does not work? Our customers are giving
>> us figures which say that hardware, electricity, cooling,
>> administration, OS licenses, DRM system licenses only make up one third
>> of their costs. The remaining money goes into the licenses of the
>> software which runs in the grid. Not talking about the labor costs for
>> the engineers using the Grid. So can the license and support costs of a
>> DRM system have any cost saving potential when you compare it with the
>> value it adds to the bulk of hardware in a data center?
>>
>> Regards,
>> Andy
>> ---
>> Snr Software Development Manager, Grid Engine
>> ORACLE Deutschland B.V.& Co. KG
>> Dr.-Leo-Ritter-Str. 7
>> D-93049 Regensburg
>> ---
>> ORACLE Deutschland B.V.& Co. KG
>> Hauptverwaltung: Riesstr. 25, D-80992 MÃŒnchen
>> Registergericht: Amtsgericht MÃŒnchen, HRA 95603
>> KomplementÀrin: ORACLE Deutschland Verwaltung B.V.
>> Rijnzathe 6, 3454PV De Meern, Niederlande
>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
>> GeschÀftsfÌhrer: JÌrgen Kunz, Marcel van de Molen, Alexander van der Ven
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275622
>>
>>
>> To unsubscribe from this discussion, e-mail:
>> [users-***@gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275647

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
dr_st
2010-08-20 09:21:55 UTC
Permalink
andy a écrit :

> There's certainly quite some risk for anyone who is responsible for
> running clusters where every hour hundreds, thousands or tens of
> thousands CPU hours are waiting to kept busy and keep the company behind
> running. So is the assumed zero price tag worth the money you will lose
> if the DRM system of your choice does not work? Our customers are giving
> us figures which say that hardware, electricity, cooling,
> administration, OS licenses, DRM system licenses only make up one third
> of their costs. The remaining money goes into the licenses of the
> software which runs in the grid. Not talking about the labor costs for
> the engineers using the Grid. So can the license and support costs of a
> DRM system have any cost saving potential when you compare it with the
> value it adds to the bulk of hardware in a data center?

To sum up, I'd say we all know the price and efforts needed to maintain
softwares in good shape, for a long period of time. For those managing
huge datacenters, I think the Oracle support is by no means a problem
(or should not), however i assume we are a lot of scientists out there
using only single/few multiple-core workstation(s), and cannot afford
it. This is not a "philosophy" problem but a financial one.

Provided for now Oracle is not providing clear directions about the
future (mysql, solaris, openoffice.org, and the rest?) and it seems even
employees do not also have a clear vision, i think the decision to
"fork-first" is wise, at least we know there is a "gold standard" we can
still use (even if frozen). I'm not sure about the future, but the lack
of Oracle clear position on all of these is more freakening than
anything else...

I hope to see those projects staying open-source (at least up to a
certain level of usage?), but for now it's getting more and more closed.

Please let me know if I'm wrong, I'd be happy to.

Stéphane

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275646

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
ron
2010-08-20 13:01:30 UTC
Permalink
Thanks Andy, and this is really one of the few responses related to the future of the SGE open source project from an Oracle employee.

The reason why I started the "fork" is because we need to maintain the software running on clusters that do not have an Oracle support contract. They, as you mentioned, need a good DRM system. Also, the Rocks Cluster Distribution needs an open source version of Grid Engine. Even if Oracle gives away free SGE binraries, they won't accept it.

(I put fork in quotes because we will merge back with the project in the future if the Oracle-paid developers are going to use the open source model. As others have already mentioned, forking is not something we really want to see, but we also don't want to see an unmaintained version of Grid Engine neither!)

We will be spending the next few months in bug fixing mode before we start anything new, and Univa UD works with the Sun and Oracle developers to fix bugs, so it's not like no commercial entities are interested in fixing bugs in SGE.

Finally, I've seen finicial companies using the open source version of SGE without having a support contract. And they have a few clusters with close to 5000 cores in total, and SGE has been working for them almost perfectly for more than 5 years.

-Ron



--- On Fri, 8/20/10, andy <***@oracle.com> wrote:
> Joe,
>
> > Let me ask a (somewhat obvious) set of questions.
> >
> > Is there any possibility that this project could be
> shut down due to
> > Oracle flexing legal muscle? That is, DanT looks like
> his group has
> > funding and a roadmap, and they might not take too
> kindly to an external
> > group building a relicensed version. Nor give their
> permission for
> > relicensure.
>
> your question raises a fair concern and needs to be asked
> here. No one,
> neither contributing as an individual nor by representing a
> company
> wants to get involved in any legal troubles when kicking
> off a
> community-led fork of the Grid Engine project.
>
> Though I'm now a Oracle employee and an old-timer in the
> Grid Engine
> engineering team since 16 years I can't speak for Oracle
> here. So I just
> can share my personal view: As I always understood the
> SISSL license
> gives the freedom to anyone to take the code and create a
> fork - even
> commercial versions seem to be allowed if the requirements
> of the SISSL
> are met. I agree a statement or clarification and
> explanation what can
> be done and what not were helpful.
>
> And the legal question is not only about the code: I could
> not give an
> answer under which license the Issuezilla database and
> mailing list
> archives had been made available. That needs to be answered
> as well.
>
> Undoubtedly the vast effort of all contributions with new
> feature
> development and bug fixing was contributed by Sun in the
> past 9 years
> since we went open source in June 2001. There were a few
> code
> contributions from our community (think about the array job
>
> interdependencies) and there was help with porting to new
> OS platforms
> (the most important certainly was the initial port to Mac
> OS X). In my
> view the greatest asset which had been created was the
> incredible
> adoption of Grid Engine and this tremendously active,
> helpful and
> positive mailing lists in the Grid Engine project. Also the
> many issues
> and bugs which had been reported by our community helped us
> to improve
> the quality of the Grid Engine code and helped others to
> get fixes
> before they ran into it as well. No doubt, that helped our
> paying
> customers as well.
>
> All of you who are in the software business know what's the
> price tag of
> developing new features and fixing bugs. There are numbers
> which say a
> single bug on average costs more than $10k to fix. What I'm
> wondering is
> if the community will be able to sustain the code quality
> of the current
> feature set - and what's about new development or complete
> new modules
> which address new needs, like the Service Domain Manager?
> This thread
> originally has started with a memory reporting regression
> on Linux. That
> bug was easy to fix. Others we fixed in 6.2u6 (see here
> http://gridengine.sunsource.net/project/gridengine/62patches.txt)
> took
> even us many, many person weeks to analyze and solve them,
> not talking
> about the QA team and lab and the continuous investment in
> the testsuite
> to ensure and improve the quality of the released code on
> all of the
> supported platforms.
>
> There's certainly quite some risk for anyone who is
> responsible for
> running clusters where every hour hundreds, thousands or
> tens of
> thousands CPU hours are waiting to kept busy and keep the
> company behind
> running. So is the assumed zero price tag worth the money
> you will lose
> if the DRM system of your choice does not work? Our
> customers are giving
> us figures which say that hardware, electricity, cooling,
> administration, OS licenses, DRM system licenses only make
> up one third
> of their costs. The remaining money goes into the licenses
> of the
> software which runs in the grid. Not talking about the
> labor costs for
> the engineers using the Grid. So can the license and
> support costs of a
> DRM system have any cost saving potential when you compare
> it with the
> value it adds to the bulk of hardware in a data center?
>
> Regards,
> Andy
> ---
> Snr Software Development Manager, Grid Engine
> ORACLE Deutschland B.V. & Co. KG
> Dr.-Leo-Ritter-Str. 7
> D-93049 Regensburg
> ---
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Rijnzathe 6, 3454PV De Meern, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr.
> 30143697
> Geschäftsführer: Jürgen Kunz, Marcel van de Molen,
> Alexander van der Ven
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275622
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275669

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
jlb
2010-08-20 15:56:50 UTC
Permalink
On Fri, 20 Aug 2010 at 9:38am, andy wrote

> Our customers are giving us figures which say that hardware,
> electricity, cooling, administration, OS licenses, DRM system licenses
> only make up one third of their costs. The remaining money goes into the
> licenses of the software which runs in the grid. Not talking about the
> labor costs for the engineers using the Grid. So can the license and
> support costs of a DRM system have any cost saving potential when you
> compare it with the value it adds to the bulk of hardware in a data
> center?

I think the operative word in the above is "our customers". That's
obviously a biased sample. In academia, e.g., the situation is quite
different. I run a cluster with over 3000 cores (about to expand by
another 1000 or so) used by many PIs. Our software licensing fees are
practically zero -- the bulk of the software we run is either open-source
or in-house. Our support fees are minimal. We don't pay for space,
power, or cooling (well the PIs do, indirectly, but not in proportion to
how much we use). The vast bulk of our money goes towards nodes. Why?
It is simply very, very hard to get the PIs to spend money on anything
other than cores.

I'm not at all trying to diminish the value of SGE and it's commercially
supported model. I'm just pointing out that there are some sizeable users
for whom the paid version just isn't viable.

--
Joshua Baker-LePain
QB3 Shared Cluster Sysadmin
UCSF

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275687

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
iank
2010-08-20 16:12:51 UTC
Permalink
On Fri, Aug 20, 2010 at 8:56 AM, jlb <***@salilab.org> wrote:
> On Fri, 20 Aug 2010 at 9:38am, andy wrote
>
>> Our customers are giving us figures which say that hardware,
>> electricity, cooling, administration, OS licenses, DRM system licenses
>> only make up one third of their costs. The remaining money goes into the
>> licenses of the software which runs in the grid. Not talking about the
>> labor costs for the engineers using the Grid. So can the license and
>> support costs of a DRM system have any cost saving potential when you
>> compare it with the value it adds to the bulk of hardware in a data
>> center?
>
> I think the operative word in the above is "our customers".  That's
> obviously a biased sample.  In academia, e.g., the situation is quite
> different.  I run a cluster with over 3000 cores (about to expand by
> another 1000 or so) used by many PIs.  Our software licensing fees are
> practically zero -- the bulk of the software we run is either open-source
> or in-house.  Our support fees are minimal.  We don't pay for space,
> power, or cooling (well the PIs do, indirectly, but not in proportion to
> how much we use).  The vast bulk of our money goes towards nodes.  Why?
> It is simply very, very hard to get the PIs to spend money on anything
> other than cores.
>
> I'm not at all trying to diminish the value of SGE and it's commercially
> supported model.  I'm just pointing out that there are some sizeable users
> for whom the paid version just isn't viable.
>

I have to agree. Coming from the institution where ROCKS is developed,
most of the software used on clusters here is either Open Source or
developed by the students and researchers utilizing those systems. We
pay for space, heat and cooling, but at a nominal fee. Our biggest
expense is support in terms of FTEs and hardware.

If we have to move to paid versions of SGE, we will most likely move
to Torque/Maui or some other freely available scheduler.

Ian

--
Ian Kaufman
Research Systems Administrator
UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275689

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
ppk
2010-08-20 16:13:58 UTC
Permalink
I think what Joshua described is pretty much the same across
many UC campuses. We just install Linux and all open source
software on our 6000+ cores cluster. Any software that has
to be licensed is PIs problem. They have to pay for it from
their grant. We just configure FlexLM license manager so
that only their group can use what they paid for. We do
have few general licenses for Matlab, Mathematica etc.
mainly for occasional general users, but waiting time for
those licenses will be longer or unpredictable.

Pretty much everybody write their own (or from a
collaborator) code in Fortran/C/C++ for serial or using
MPI/OpenMP for parallel. Major expenses are for the nodes
itself, Infiniband interconnect fabric and storage server.


Prakashan


jlb wrote:
> On Fri, 20 Aug 2010 at 9:38am, andy wrote
>
>> Our customers are giving us figures which say that hardware,
>> electricity, cooling, administration, OS licenses, DRM system licenses
>> only make up one third of their costs. The remaining money goes into the
>> licenses of the software which runs in the grid. Not talking about the
>> labor costs for the engineers using the Grid. So can the license and
>> support costs of a DRM system have any cost saving potential when you
>> compare it with the value it adds to the bulk of hardware in a data
>> center?
>
> I think the operative word in the above is "our customers". That's
> obviously a biased sample. In academia, e.g., the situation is quite
> different. I run a cluster with over 3000 cores (about to expand by
> another 1000 or so) used by many PIs. Our software licensing fees are
> practically zero -- the bulk of the software we run is either open-source
> or in-house. Our support fees are minimal. We don't pay for space,
> power, or cooling (well the PIs do, indirectly, but not in proportion to
> how much we use). The vast bulk of our money goes towards nodes. Why?
> It is simply very, very hard to get the PIs to spend money on anything
> other than cores.
>
> I'm not at all trying to diminish the value of SGE and it's commercially
> supported model. I'm just pointing out that there are some sizeable users
> for whom the paid version just isn't viable.
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275690

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
ffoertter
2010-09-10 16:58:07 UTC
Permalink
Exactly Ian. Worse are smaller companies like mine that do have to pay for space, cooling, FTE, and hardware. We run a smallish cluster <300 cores. What typically happens when the Oracles of the world decide to charge for something is that while for universities they charge next to nothing, for industry the charge both arms, a leg and some fingers... (SAS, Oracle just to name a few.)

Coming from academia sized pricing I was shocked and the hundreds of thousands of dollars spent by my company on licensing... they love to charge per core, so when you're upgrading that 4yo dual socket dual-core machine to a dual socket quad, you're screwed by licensing costs that didn't evolve with the hardware. It's one instance of the software, but darn it, they'll charge you for ever core you're using. I'm surprised they don't tack on how many mem banks you have filled... we had negotiations with another company on whether we could run a VM using the same number of cores as in our license just so we wouldn't have to pay up +100K to redraw our 10yo contract, but these folks wanted to charge by hardware, not by use of hardware. At some point we suggested removing a chip just to stay within the 4 core limit...

What's the point of all this drama? We don't trust licensing...because they never use the Walmart model: charge a little sell a lot. They use the "look, we're the only game in town, pay up" model. Like Ian, if we have to pay for SGE, I'll gladly use another open source version and help develop it too. It's time the big guns realize that the Red Hat/Cloudera model can work... and we in the community are MORE THAN HAPPY to help continue the development of your software... and as the Linux Mag article said "we're all rocket scientists" it would be silly to throw away free (wo)man-hours of bug testing and development because they want to milk it all. But us young up and coming developers will continue to recommend to companies that they free themselves from the shackles of these bloated restrictive licenses.

We have science to do, we don't have time to be negotiating disabling sockets vs pricing. It's like going to a restaurant and paying for seats you don't fill at your table and the time it took the cook to develop the recipe. People are more than willing to pay for the insurance to have something fixed fast when needed. If software companies spent more time making sure the software is robust (by say using the community to beta test), they can watch the cash roll in while support calls are far and few in between. But if you prefer to keep the close the source, license the use, then the fork will give us far better user/customer support you could ever provide.

My 0.2c

FF

On Aug 20, 2010, at 11:12 AM, iank wrote:

>
> If we have to move to paid versions of SGE, we will most likely move
> to Torque/Maui or some other freely available scheduler.
>
> Ian

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=280989

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
ron
2010-09-15 14:50:46 UTC
Permalink
I've just added the third contributor (1st = Ron, 2nd = Rayson), Stephen, to the Open Grid Scheduler.

- We will now need to decide where to discuss our issues.
- We also need to decide how we handle the code review process.
- Further, we need to agree what we need to test the changes.

Comments welcome!

-Ron


--- On Sat, 9/11/10, ffoertter <***@gmail.com> wrote:
> Exactly Ian.  Worse are smaller
> companies like mine that do have to pay for space, cooling,
> FTE, and hardware.  We run a smallish cluster <300
> cores.  What typically happens when the Oracles of the
> world decide to charge for something is that while for
> universities they charge next to nothing, for industry the
> charge both arms, a leg and some fingers... (SAS, Oracle
> just to name a few.)
>
> Coming from academia sized pricing I was shocked and the
> hundreds of thousands of dollars spent by my company on
> licensing... they love to charge per core, so when you're
> upgrading that 4yo dual socket dual-core machine to a dual
> socket quad, you're screwed by licensing costs that didn't
> evolve with the hardware.  It's one instance of the
> software, but darn it, they'll charge you for ever core
> you're using.  I'm surprised they don't tack on how
> many mem banks you have filled... we had negotiations with
> another company on whether we could run a VM using the same
> number of cores as in our license just so we wouldn't have
> to pay up +100K to redraw our 10yo contract, but these folks
> wanted to charge by hardware, not by use of hardware. 
> At some point we suggested removing a chip just to stay
> within the 4 core limit...
>
> What's the point of all this drama?  We don't trust
> licensing...because they never use the Walmart model: charge
> a little sell a lot.  They use the "look, we're the
> only game in town, pay up" model.  Like Ian, if we have
> to pay for SGE, I'll gladly use another open source version
> and help develop it too.  It's time the big guns
> realize that the Red Hat/Cloudera model can work... and we
> in the community are MORE THAN HAPPY to help continue the
> development of your software... and as the Linux Mag article
> said "we're all rocket scientists" it would be silly to
> throw away free (wo)man-hours of bug testing and development
> because they want to milk it all.  But us young up and
> coming developers will continue to recommend to companies
> that they free themselves from the shackles of these bloated
> restrictive licenses.
>
> We have science to do, we don't have time to be negotiating
> disabling sockets vs pricing.  It's like going to a
> restaurant and paying for seats you don't fill at your table
> and the time it took the cook to develop the recipe. 
> People are more than willing to pay for the insurance to
> have something fixed fast when needed.  If software
> companies spent more time making sure the software is robust
> (by say using the community to beta test), they can watch
> the cash roll in while support calls are far and few in
> between.  But if you prefer to keep the close the
> source, license the use, then the fork will give us far
> better user/customer support you could ever provide.
>
> My 0.2c
>
> FF
>
> On Aug 20, 2010, at 11:12 AM, iank wrote:
>
> >
> > If we have to move to paid versions of SGE, we will
> most likely move
> > to Torque/Maui or some other freely available
> scheduler.
> >
> > Ian
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=280989
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=281903

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
joelandman
2010-08-20 17:07:24 UTC
Permalink
On 08/20/2010 03:38 AM, Andy Schwierskott wrote:
> Joe,
>
> > Let me ask a (somewhat obvious) set of questions.
> >
> > Is there any possibility that this project could be shut down due to
> > Oracle flexing legal muscle? That is, DanT looks like his group has
> > funding and a roadmap, and they might not take too kindly to an external
> > group building a relicensed version. Nor give their permission for
> > relicensure.
>

Hi Andy

As always, I appreciate your reply, your and the team's work on it.
We've been using/recommending SGE for the better part of the last
decade. We've developed a number of tools in use by numerous groups for
running certain calculations with SGE hidden beneath, as well as
accounting, usage reporting, etc. These tools have been available on
our sites for years, as GPL.

> your question raises a fair concern and needs to be asked here. No one,
> neither contributing as an individual nor by representing a company
> wants to get involved in any legal troubles when kicking off a
> community-led fork of the Grid Engine project.

I think a few of us were surprised by the change ... I expected
something, though I wasn't sure what.

> Though I'm now a Oracle employee and an old-timer in the Grid Engine
> engineering team since 16 years I can't speak for Oracle here. So I just
> can share my personal view: As I always understood the SISSL license
> gives the freedom to anyone to take the code and create a fork - even
> commercial versions seem to be allowed if the requirements of the SISSL
> are met. I agree a statement or clarification and explanation what can
> be done and what not were helpful.
>
> And the legal question is not only about the code: I could not give an
> answer under which license the Issuezilla database and mailing list
> archives had been made available. That needs to be answered as well.

I think there are non-Oracle resources that have mirrored the lists.
The bug/patch bits are another thing entirely, only one host for those.
The archives represent a huge investment on the part of the community,
in terms of providing effectively free support to others (free and paid
customers of Sun/Oracle). Chris Dag's gridinfo.net wiki represents an
incredibly useful knowledge store. These community resources are
available freely to all.

> Undoubtedly the vast effort of all contributions with new feature
> development and bug fixing was contributed by Sun in the past 9 years
> since we went open source in June 2001. There were a few code
> contributions from our community (think about the array job
> interdependencies) and there was help with porting to new OS platforms
> (the most important certainly was the initial port to Mac OS X). In my
> view the greatest asset which had been created was the incredible
> adoption of Grid Engine and this tremendously active, helpful and
> positive mailing lists in the Grid Engine project. Also the many issues
> and bugs which had been reported by our community helped us to improve
> the quality of the Grid Engine code and helped others to get fixes
> before they ran into it as well. No doubt, that helped our paying
> customers as well.

Yes I agree. The community has been one of the best selling points to
have customers adopt SGE. Support is an email away. With many eyes,
many problems are shallow.

> All of you who are in the software business know what's the price tag of
> developing new features and fixing bugs. There are numbers which say a
> single bug on average costs more than $10k to fix. What I'm wondering is

Well, there are numbers and ... er ... then there are numbers. I don't
put much faith in these generalized metrics.

This said, bugs do cost real money to fix, and your point is basically
pointing to the need of the OGE group to show a positive revenue,
hopefully in (significant) excess of the costs to deliver this product.

Bugs cost people time (salary/benefits), machine time (power,
acquisition costs, etc). These are non-zero. Of this there is no doubt.

> if the community will be able to sustain the code quality of the current
> feature set - and what's about new development or complete new modules
> which address new needs, like the Service Domain Manager? This thread

Look carefully at Torque and some of the others (Slurm etc). Open
source, contributing community, and quite vibrant, without the need for
$10k/bug metrics and revenue offsets of the same.

> originally has started with a memory reporting regression on Linux. That
> bug was easy to fix. Others we fixed in 6.2u6 (see here
> http://gridengine.sunsource.net/project/gridengine/62patches.txt) took
> even us many, many person weeks to analyze and solve them, not talking
> about the QA team and lab and the continuous investment in the testsuite
> to ensure and improve the quality of the released code on all of the
> supported platforms.
>
> There's certainly quite some risk for anyone who is responsible for
> running clusters where every hour hundreds, thousands or tens of
> thousands CPU hours are waiting to kept busy and keep the company behind
> running. So is the assumed zero price tag worth the money you will lose
> if the DRM system of your choice does not work? Our customers are giving
> us figures which say that hardware, electricity, cooling,
> administration, OS licenses, DRM system licenses only make up one third
> of their costs. The remaining money goes into the licenses of the
> software which runs in the grid. Not talking about the labor costs for
> the engineers using the Grid. So can the license and support costs of a
> DRM system have any cost saving potential when you compare it with the
> value it adds to the bulk of hardware in a data center?

My concern is how the license changes impact the community. Others have
answered the costs issues. You know as well as I that charging per core
in an HPC scenario is a good way to kill sales. We've seen folks
charging $1k/core for clusters, and not understanding why they aren't
rolling in the money.

In particular spaces, we are seeing customers actively investing in open
source projects which allow them to scale their computing without
scaling their software costs, which directly compete with the closed
source systems at several thousands of dollars per socket. The HPC user
group run by IDC keeps harping on these pricing models, and points out
that this is what customers complain the most about. Changing to that
model isn't likely to increase the number of customers in this space,
nor endear the product to those who would be most likely to buy it. I
am not trying to be critical ... just pointing out what we hear others say.

This said, I am still hopeful that some sort of method will exist to
enable users to keep using the OGE in an open source manner (think like
the Centos-Redhat relationship). Customers who don't want/need support
don't pay for it. Those who want/need it, do. Redhat has a very
similar issue to the OGE team on this. Similar business model. Its
workable. Centos can kick bugfixes back upstairs to RHEL, and they have
access to the database. This is something of what I'd hope for here.
There are customers who'd pay for it, but its a smaller number than
those who would use it.

Regards,

Joe

--
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics, Inc.
email: ***@scalableinformatics.com
web : http://scalableinformatics.com
http://scalableinformatics.com/jackrabbit
phone: +1 734 786 8423 x121
fax : +1 866 888 3112
cell : +1 734 612 4615

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275726

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
fx
2010-08-23 14:36:22 UTC
Permalink
joelandman <***@scalableinformatics.com> writes:

>> All of you who are in the software business know what's the price tag of
>> developing new features and fixing bugs. There are numbers which say a
>> single bug on average costs more than $10k to fix. What I'm wondering is
>
> Well, there are numbers and ... er ... then there are numbers. I don't
> put much faith in these generalized metrics.

Right; some of us ought to be millionaires at $10k/bug, except that
we've done the work as volunteers or as part of our public service
employment. If that's what it actually costs Oracle, it looks like a
business opportunity for others.

> Look carefully at Torque and some of the others (Slurm etc). Open
> source, contributing community, and quite vibrant, without the need for
> $10k/bug metrics and revenue offsets of the same.

You could ask why the same hasn't happened with SGE (and possibly other
Sun free software products). It seems to me that it was relatively hard
to contribute. There's some indication that now Oracle has killed
OpenSolaris, the fork (whose name I forget) will end up in quite good
shape.

> Redhat has a very similar issue to the OGE team on this.

Specifically its HPC offering which I assume is all free software.

--
Dave Love
Advanced Research Computing, Computing Services, University of Liverpool
AKA ***@gnu.org

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276275

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
fx
2010-08-23 14:34:04 UTC
Permalink
andy <***@oracle.com> writes:

> Joe,
>
> > Let me ask a (somewhat obvious) set of questions.
> >
> > Is there any possibility that this project could be shut down due to
> > Oracle flexing legal muscle? That is, DanT looks like his group has
> > funding and a roadmap, and they might not take too kindly to an external
> > group building a relicensed version. Nor give their permission for
> > relicensure.

Is anyone actually proposing changing the licence unilaterally? I
wouldn't contribute to a project violating copyright like that, even if
it wasn't closed down in short order.

> As I always understood the SISSL license
> gives the freedom to anyone to take the code and create a fork -

Yes, it's a free software licence (see below).

> even commercial versions seem to be allowed if the requirements of the
> SISSL are met.

s/commercial/proprietary/

> I agree a statement or clarification and explanation what can
> be done and what not were helpful.

I think the only issues surround details of the `standards' business
and, possibly, the implications of the patent language for people in
places afflicted by software patents (ugh).

> And the legal question is not only about the code: I could not give an
> answer under which license the Issuezilla database and mailing list
> archives had been made available. That needs to be answered as well.

http://www.sunsource.net/TUPPCP.html covers that, though I think it
couldn't apply to posts to the mail lists generally since the posters
may not have seen it. Anyway, Oracle surely can't claim copyright on
them, and they're already in markmail and Gmane.

> There's certainly quite some risk for anyone who is responsible for
> running clusters where every hour hundreds, thousands or tens of
> thousands CPU hours are waiting to kept busy and keep the company behind
> running.

[SGE is the least of our worries for reliability of our Sun
clusters :-(.]

> So is the assumed zero price tag worth the money you will lose
> if the DRM system of your choice does not work?

Although most of us couldn't afford the huge Sun/Oracle support fees, I
guess for a significant number of us, the issue is free v. proprietary
software. I go along roughly with <http://www.sunsource.net/why.html>,
considering `open source' equal to `free'. I.e. it's a question of
freedom, not price, and if SGE hadn't been free software, I'd have used
Torque/Maui originally.

We'd like to be in a position here to pay reasonable fees for
appropriate support (as opposed to the largely useless support we paid
for though the vendor of our Sun systems, and licence fees for
proprietary software) but, like others, we're not. However, from
experience I'm not sure I'd want to pay Oracle anyway. Sun support went
really downhill in recent years (I go back to Sun 3s) and we have worse
problems now, especially since Oracle is essentially out of HPC, and Sun
HPC people are gone. I'm not suggesting this is anything to do with the
developers, of course, but if you can't get to experts past the
first-line people, support is mostly useless. The one thing I could
have got money for was `training', but I got nowhere with Sun trying to
organize a UK event involving non-trivial money and a possible sales
opportunity to industrials.

I hope that didn't sound unpleasant; it's just the way things are, and
not just for us. It's with a background of cooperative projects and
maintenance, including of software used by most pharmaceutical
companies, so I hope I'm reasonably sympathetic. Thanks for everyone's
efforts, anyway.

--
Dave Love
Advanced Research Computing, Computing Services, University of Liverpool
AKA ***@gnu.org

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276274

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
ron
2010-08-19 01:32:22 UTC
Permalink
--- On Thu, 8/19/10, reuti <***@staff.uni-marburg.de> wrote:
> Great. Will we also need to copy (if legal) this mailing
> list archive to somewhere else? AFAIK CollabNet is not free,
> but paid by someone - when it's shut down, all collected
> knowledge therein will be lost otherwise.

Seems like no one mentioned Markmail:

http://gridengine.markmail.org/

-Ron


>
> Maybe this would also be a good point to move to
> autotools/cmake for the build process at this cut, in favor
> of any precompiled binaries.
>
> -- Reuti
>
>
> > Rayson
> >
> >> -- Reuti
> >>
> >>> Rayson
> >>>
> >>> On Wed, Aug 18, 2010 at 12:23 AM, LaoTsao
> 老曹 <***@gmail.com>
> wrote:
> >>>>  may be just install vbox and install
> rocks5.3
> >>>>
> >>>> On 8/17/2010 11:50 PM, rayson wrote:
> >>>>>
> >>>>> 32-bit or 64-bit?
> >>>>>
> >>>>> I am running Fedora Core 13, which has
> newer versions of everything:
> >>>>> gcc 4.4.4, kernel
> 2.6.33.6-147.2.4.fc13.x86_64, glibc 2.12. I will see
> >>>>> if I can find an older machine.
> >>>>>
> >>>>> Rayson
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2010/8/17 jenny<***@genomics.org.cn>:
> >>>>>>
> >>>>>> Hi Rayson,
> >>>>>>
> >>>>>> I use rocks v5.3 distributed a
> cluster, with centos 5.4, gcc 4.1.2, and
> >>>>>> sge
> >>>>>> 6.2U4. Can the patch be built?
> >>>>>>
> >>>>>> thanks
> >>>>>>
> >>>>>> Jenny
> >>>>>> ________________________________
> >>>>>> 发件人: rayson
> >>>>>> 发送时间: 2010-08-18 
> 11:18:43
> >>>>>> 收件人: users
> >>>>>> 抄送:
> >>>>>> 主题: Re: Re: [GE users] Issue
> seen in 6.2U5 : memory values reported bySGE
> >>>>>> too low compared to top output on
> linux systems
> >>>>>> What is your machine's Linux
> distribution and version?? I will see if
> >>>>>> I can build the SGE source tree on
> a machine that has similar kernel&
> >>>>>> glibc version as yours.
> >>>>>> If I can find such a machine, or
> if you know how to build from source,
> >>>>>> then you can expect a patch from
> me later this week or early next
> >>>>>> week.
> >>>>>> Rayson
> >>>>>> On Mon, Aug 16, 2010 at 10:45 PM,
> jching<***@bbn.com> 
> wrote:
> >>>>>>>
> >>>>>>> Thanks Ron, makes sense to
> wait for Rayson :)
> >>>>>>>
> >>>>>>>
> ------------------------------------------------------
> >>>>>>>
> >>>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274841
> >>>>>>>
> >>>>>>> To unsubscribe from this
> discussion, e-mail:
> >>>>>>> [users-***@gridengine.sunsource.net].
> >>>>>>>
> >>>>>>
> ------------------------------------------------------
> >>>>>>
> >>>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275072
> >>>>>> To unsubscribe from this
> discussion, e-mail:
> >>>>>> [users-***@gridengine.sunsource.net].
> >>>>>> __________ Information from ESET
> NOD32 Antivirus, version of virus
> >>>>>> signature database 5374 (20100817)
> __________
> >>>>>> The message was checked by ESET
> NOD32 Antivirus.
> >>>>>> http://www.eset.com
> >>>>>
> >>>>>
> ------------------------------------------------------
> >>>>>
> >>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275078
> >>>>>
> >>>>> To unsubscribe from this discussion,
> e-mail:
> >>>>> [users-***@gridengine.sunsource.net].
> >>>>
> >>>
> >>>
> ------------------------------------------------------
> >>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275086
> >>>
> >>> To unsubscribe from this discussion, e-mail:
> [users-***@gridengine.sunsource.net].
> >>>
> >>
> >>
> ------------------------------------------------------
> >> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275135
> >>
> >> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
> >>
> >
> >
> ------------------------------------------------------
> > http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275196
> >
> > To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
> >
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275226
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275292

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
fx
2010-08-19 17:04:53 UTC
Permalink
ron <***@yahoo.com> writes:

> Seems like no one mentioned Markmail:
>
> http://gridengine.markmail.org/

It's also on Gmane (www.gmane.org), but I don't know how far back.

--
Dave Love
Advanced Research Computing, Computing Services, University of Liverpool
AKA ***@gnu.org

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275511

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
fx
2010-08-19 17:04:08 UTC
Permalink
[I've been out of the loop and am trying to catch up on all this.]

reuti <***@staff.uni-marburg.de> writes:

> Maybe this would also be a good point to move to autotools/cmake for
> the build process at this cut, in favor of any precompiled binaries.

I can autoconfiscate it. Binaries can appear for OS distributions in
the usual way, but supplying dpkg and rpm source package stuff would be
good.

--
Dave Love
Advanced Research Computing, Computing Services, University of Liverpool
AKA ***@gnu.org

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275510

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
opoplawski
2010-08-18 20:22:02 UTC
Permalink
On 08/17/2010 10:26 PM, rayson wrote:
> That's a good idea, but I don't have enough time to support each
> distro. It's 12:30am in Toronto and I am still up :(
>
> Someone interested in providing build support? I guess without Sun, we
> will need to handle many things ourselves!
>

I can update the Fedora gridengine packages if I have the source.

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane ***@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275263

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
ron
2010-08-18 21:28:02 UTC
Permalink
Great, and the "Open Grid Scheduler" project will also accept patches so that it will build smoothly on other distributions (I recall the "getline" bug that is maintained as a seperate patch for a few distributions).

I think we will be focused on bug fixing for the next few months, before we start anything big.

-Ron


--- On Thu, 8/19/10, opoplawski <***@cora.nwra.com> wrote:
> I can update the Fedora gridengine packages if I have the
> source.
>
> --
> Orion Poplawski
> Technical Manager           
>          303-415-9701 x222
> NWRA/CoRA Division           
>         FAX: 303-415-9702
> 3380 Mitchell Lane           
>       ***@cora.nwra.com
> Boulder, CO 80301           
>   http://www.cora.nwra.com
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275263
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275267

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
reuti
2010-08-18 23:13:14 UTC
Permalink
Am 18.08.2010 um 23:28 schrieb ron:

> Great, and the "Open Grid Scheduler" project will also accept patches so that it will build smoothly on other distributions (I recall the "getline" bug that is maintained as a seperate patch for a few distributions).

What license will apply to this product then? Can we include some GNU tools and libs now - i.e. a tight sshd for example. I would also like to use getops and getops_long for the arguments parsing to OGS. I'm sometimes trapped by using the combined style and leaving blanks out, which works for other applications but not OGS.


> I think we will be focused on bug fixing for the next few months, before we start anything big.

Yeah. Will we need to support all stuff which is right now in the package, or focus on the one that is most needed by the community?

I would also suggest to look into combining OGS with the "GNU Batch" scheduler - it would extend OGS with changable consumables depending on the result of a job, and use them to start another job and also cron-like features.

It was at one time advertised on the list here: http://wildfire.bii.a-star.edu.sg/index.php but I never got a reply when I contacted the developers. Some workflow tool would be nice. For now GEL is running completely outside of OGS, and submitting the jobs when it discovers that they should run - but then they have to wait again. And when the external daemons crashes, all workflow is lost.

-- Reuti


> -Ron
>
>
> --- On Thu, 8/19/10, opoplawski <***@cora.nwra.com> wrote:
>> I can update the Fedora gridengine packages if I have the
>> source.
>>
>> --
>> Orion Poplawski
>> Technical Manager
>> 303-415-9701 x222
>> NWRA/CoRA Division
>> FAX: 303-415-9702
>> 3380 Mitchell Lane
>> ***@cora.nwra.com
>> Boulder, CO 80301
>> http://www.cora.nwra.com
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275263
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275267
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275278

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
rayson
2010-08-18 23:22:29 UTC
Permalink
Keep in mind that in SISSL there is the "Standards body" thing, and if
we don't comply with it, then SISSL will be converted into a copyleft
license.

http://en.wikipedia.org/wiki/Sun_Industry_Standards_Source_License

May be it is not a bad thing to release everything under a copyleft
license, as we don't need to make money off Grid Engine or OGS, and
the BioTeam and anyone can continue to use Grid Engine for free.

Rayson



On Wed, Aug 18, 2010 at 7:13 PM, reuti <***@staff.uni-marburg.de> wrote:
> Am 18.08.2010 um 23:28 schrieb ron:
>
>> Great, and the "Open Grid Scheduler" project will also accept patches so that it will build smoothly on other distributions (I recall the "getline" bug that is maintained as a seperate patch for a few distributions).
>
> What license will apply to this product then? Can we include some GNU tools and libs now - i.e. a tight sshd for example. I would also like to use getops and getops_long for the arguments parsing to OGS. I'm sometimes trapped by using the combined style and leaving blanks out, which works for other applications but not OGS.
>
>
>> I think we will be focused on bug fixing for the next few months, before we start anything big.
>
> Yeah. Will we need to support all stuff which is right now in the package, or focus on the one that is most needed by the community?
>
> I would also suggest to look into combining OGS with the "GNU Batch" scheduler - it would extend OGS with changable consumables depending on the result of a job, and use them to start another job and also cron-like features.
>
> It was at one time advertised on the list here: http://wildfire.bii.a-star.edu.sg/index.php but I never got a reply when I contacted the developers. Some workflow tool would be nice. For now GEL is running completely outside of OGS, and submitting the jobs when it discovers that they should run - but then they have to wait again. And when the external daemons crashes, all workflow is lost.
>
> -- Reuti
>
>
>> -Ron
>>
>>
>> --- On Thu, 8/19/10, opoplawski <***@cora.nwra.com> wrote:
>>> I can update the Fedora gridengine packages if I have the
>>> source.
>>>
>>> --
>>> Orion Poplawski
>>> Technical Manager
>>>          303-415-9701 x222
>>> NWRA/CoRA Division
>>>         FAX: 303-415-9702
>>> 3380 Mitchell Lane
>>>       ***@cora.nwra.com
>>> Boulder, CO 80301
>>>   http://www.cora.nwra.com
>>>
>>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275263
>>>
>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275267
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275278
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275279

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
fx
2010-08-19 17:07:50 UTC
Permalink
rayson <***@gmail.com> writes:

> Keep in mind that in SISSL there is the "Standards body" thing, and if
> we don't comply with it, then SISSL will be converted into a copyleft
> license.
>
> http://en.wikipedia.org/wiki/Sun_Industry_Standards_Source_License
>
> May be it is not a bad thing to release everything under a copyleft
> license, as we don't need to make money off Grid Engine or OGS, and
> the BioTeam and anyone can continue to use Grid Engine for free.

This seems rather confused. SISSL is copyleft (but rather odd), and
copyleft code stays copyleft by design. I don't understand the point
about making money and Bioteam. Surely you explicitly want people to be
able to provide a support service.

Beware of software patent threats outside the coverage of the SISSL,
which I'm not sure is very clear.

--
Dave Love
Advanced Research Computing, Computing Services, University of Liverpool
AKA ***@gnu.org

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275514

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
rayson
2010-08-19 21:27:17 UTC
Permalink
On Thu, Aug 19, 2010 at 1:07 PM, fx <***@liverpool.ac.uk> wrote:
> This seems rather confused.  SISSL is copyleft (but rather odd), and
> copyleft code stays copyleft by design.  I don't understand the point
> about making money and Bioteam.  Surely you explicitly want people to be
> able to provide a support service.

I mean it is usually harder to make money off an application that is
licensed under a copyleft license, and I don't need to sell software
licenses to make a living.

And related to Bioteam and other people, I mean they can continue to
install SGE on clusters without worrying about paying first.


> Beware of software patent threats outside the coverage of the SISSL,
> which I'm not sure is very clear.

Most of the technologies in batch systems are really old. In fact, I
was reading the patents granted to Platform Computing, Cluster
Resources INC, and Sun (of course the SGE related subset), and found
that most of them (if not all? I need to go through them one by one
again) do not cover what we have in the core SGE codebase. However, I
don't have an understanding of the other add-on modules so they are
not part of the Open Grid Scheduler project yet.

Rayson





> --
> Dave Love
> Advanced Research Computing, Computing Services, University of Liverpool
> AKA ***@gnu.org
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275514
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275552

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
fx
2010-08-23 14:30:57 UTC
Permalink
rayson <***@gmail.com> writes:

> On Thu, Aug 19, 2010 at 1:07 PM, fx <***@liverpool.ac.uk> wrote:
>> This seems rather confused.  SISSL is copyleft (but rather odd), and
>> copyleft code stays copyleft by design.  I don't understand the point
>> about making money and Bioteam.  Surely you explicitly want people to be
>> able to provide a support service.

Sorry, I should have re-read the thing before commenting, because of the
rather ill-defined `standards' business (which refers to a location for
non-existent binaries with which you're supposed to inter-operate).
Presumably maintaining interoperability with 6.2u5 would count, but I
suspect that clause should just be ignored, especially as we're
specifically interested in free software.

> Most of the technologies in batch systems are really old.

Sure (I used OS\370), but there's no sanity in software patents and
legal threats, at least in the USA.

> In fact, I
> was reading the patents granted to Platform Computing, Cluster
> Resources INC, and Sun (of course the SGE related subset), and found
> that most of them (if not all? I need to go through them one by one
> again) do not cover what we have in the core SGE codebase. However, I
> don't have an understanding of the other add-on modules so they are
> not part of the Open Grid Scheduler project yet.

Everything in the gridengine.sunsource.net repo is under the SISSL as
far as I can tell, although I think some of the Java stuff it depends on
is non-free -- webconsole for a start, but also some required packages.
The SISSL has a patent licence, but the exact consequences of the
language are unclear to me.

--
Dave Love
Advanced Research Computing, Computing Services, University of Liverpool
AKA ***@gnu.org

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276271

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
fx
2010-08-19 17:06:47 UTC
Permalink
reuti <***@staff.uni-marburg.de> writes:

> What license will apply to this product then?

How can it be anything other than Sun's bizarre licence (SISSL)?

> Can we include some GNU tools and libs now - i.e. a tight sshd for
> example.

OpenSSH isn't a GNU package and has a more permissive licence than
SISSL. Anything in glibc is OK on a GNU system. LGPL and BSD-ish code
are OK to link. GPL code isn't (see http://www.gnu.org/licenses).

> I would also like to use getops and getops_long for the arguments
> parsing to OGS. I'm sometimes trapped by using the combined style and
> leaving blanks out, which works for other applications but not OGS.

The command arguments aren't consistent with getopt generally, are they?
`qconf -sfoo' would parse as four single-char args. Sanitizing that
would be good, of course, but incompatible.

> Yeah. Will we need to support all stuff which is right now in the
> package, or focus on the one that is most needed by the community?

What would you not support that currently gets built? However, it's not
just SGE, but also SDM and ARCo to consider. As far as I remember, not
all components of that are free software, unfortunately. It's not just
code, either, but documentation -- I have assorted fixes for that.

> I would also suggest to look into combining OGS with the "GNU Batch"
> scheduler - it would extend OGS with changable consumables depending
> on the result of a job, and use them to start another job and also
> cron-like features.

You can't combine SISSL code with GPL code.

--
Dave Love
Advanced Research Computing, Computing Services, University of Liverpool
AKA ***@gnu.org

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275513

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
reuti
2010-08-19 17:37:45 UTC
Permalink
Am 19.08.2010 um 19:06 schrieb fx:

> The command arguments aren't consistent with getopt generally, are they?
> `qconf -sfoo' would parse as four single-char args. Sanitizing that
> would be good, of course, but incompatible.

Or as -s with an optarg, which is set to "foo" then, when specified as "s:" in the list of possible arguments. Anyway, it was just one idea. I see, there are already too many long options with just a single dash in front.


>> Yeah. Will we need to support all stuff which is right now in the
>> package, or focus on the one that is most needed by the community?
>
> What would you not support that currently gets built? However, it's not
> just SGE, but also SDM and ARCo to consider.

Yep, this I was thinking about.


> As far as I remember, not
> all components of that are free software, unfortunately. It's not just
> code, either, but documentation -- I have assorted fixes for that.
>
>> I would also suggest to look into combining OGS with the "GNU Batch"
>> scheduler - it would extend OGS with changable consumables depending
>> on the result of a job, and use them to start another job and also
>> cron-like features.
>
> You can't combine SISSL code with GPL code.

This I feared... But: won't this target only any distribution of prebuild packages? When we ease the built process, and the end-user has to download several packages to be put here and there in the source tree on his own machine - it's still not possible? This is necessary for now already with the tight SSH integration.

-- Reuti

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275521

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
reuti
2010-08-22 12:53:29 UTC
Permalink
Am 19.08.2010 um 19:06 schrieb fx:

> <snip>
>> I would also suggest to look into combining OGS with the "GNU Batch"
>> scheduler - it would extend OGS with changable consumables depending
>> on the result of a job, and use them to start another job and also
>> cron-like features.
>
> You can't combine SISSL code with GPL code.

BTW: The right now available `qmake` is also based on the GNU make. In the source it's in the 3rdparty directory. So it should have never ever made it up to the binary package, as it must be available separately incl. it's source?

-- Reuti


> --
> Dave Love
> Advanced Research Computing, Computing Services, University of Liverpool
> AKA ***@gnu.org
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275513
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275946

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
rayson
2010-08-22 13:50:10 UTC
Permalink
On Sun, Aug 22, 2010 at 8:53 AM, reuti <***@staff.uni-marburg.de> wrote:
> BTW: The right now available `qmake` is also based on the GNU make. In the source it's in the 3rdparty directory. So it should have never ever made it up to the binary package, as it must be available separately incl. it's source?

qmake does not link against any SGE libraries - all it needs is to invoke qrsh.

Rayson



>
> -- Reuti
>
>
>> --
>> Dave Love
>> Advanced Research Computing, Computing Services, University of Liverpool
>> AKA ***@gnu.org
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275513
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275946
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275977

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
ron
2010-08-22 15:00:09 UTC
Permalink
Also, the qmake portion that was developed the CODINE/SGE developers is released under GPL - the reason is that qmake is > 90% based on gmake, which is licensed under the GPL.

However, as Rayson has already mentioned, those changes are small, as qmake just invokes qrsh, and not directly communicates via the SGE internal APIs, and thus not linked against any SGE libraries.

-Ron


--- On Sun, 8/22/10, rayson <***@gmail.com> wrote:
> reuti <***@staff.uni-marburg.de>
> wrote:
> > BTW: The right now available `qmake` is also based on
> the GNU make. In the source it's in the 3rdparty directory.
> So it should have never ever made it up to the binary
> package, as it must be available separately incl. it's
> source?
>
> qmake does not link against any SGE libraries - all it
> needs is to invoke qrsh.
>
> Rayson
>
>
>
> >
> > -- Reuti
> >
> >
> >> --
> >> Dave Love
> >> Advanced Research Computing, Computing Services,
> University of Liverpool
> >> AKA ***@gnu.org
> >>
> >>
> ------------------------------------------------------
> >> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275513
> >>
> >> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
> >
> >
> ------------------------------------------------------
> > http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275946
> >
> > To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
> >
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275977
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276003

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
fx
2010-08-23 14:31:51 UTC
Permalink
rayson <***@gmail.com> writes:

> qmake does not link against any SGE libraries - all it needs is to
> invoke qrsh.

Right, but note that there are problems elsewhere. [I don't mean to
suggest that rayson et al don't understand, but it's already apparently
been missed, as below.]

Specifically you can't use libdrmaa with, for instance, GPL'd code that
doesn't have a suitable licence exception. Thus the SGE DRMAA is
useless for a significant number of potential applications -- consider
building a qmake with it rather than using qrsh, if that's technically
feasible (I don't know).

This is a problem with at least one tarball on the gridengine site --
the Python DRMAA binding, which claims a straight GPL licence; likewise
the Perl binding, which isn't on sunsource. I only realized this fairly
recently when looking at DRMAA, and I guess it's now too late to do
anything about it and make SGE DRMAA generally useful. The OGE
situation is no better, of course.

Note that there was some of the licensing on some files made for the
Debian packaging -- see the copyright file on the Debian package, and
relevant posts on debian-legal (?). I think that was never resolved in
the source. Also note that the headers on the current files don't obey
the requirements of the licence, since they don't mention `the original
code', which I think Debian didn't pick up.

--
Dave Love
Advanced Research Computing, Computing Services, University of Liverpool
AKA ***@gnu.org

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276272

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
wagoodman
2010-08-25 15:34:47 UTC
Permalink
Hi all,

At my site we have a licensed SGE 6.2U5, I put in a service request to sun and I get the
same answer that everybody else is saying "it's fixed in release SGE 6.2U6". My only problem
is, we just completed an upgrade two weeks ago... I had to request a major outage. Is there
a quick fix or patch for this. I mean, my boss is going to blame me for not researching and
testing out new release (which I did thoroughly), but I guess like everyone else, I didn't notice
it. Also does that bug just effect reporting only or does it break functionality?

Bill

-----Original Message-----
From: fx [mailto:***@liverpool.ac.uk]
Sent: Monday, August 23, 2010 10:32 AM
To: ***@gridengine.sunsource.net
Subject: library licenses (was: Re: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE too low compared to top output on linux systems)

rayson <***@gmail.com> writes:

> qmake does not link against any SGE libraries - all it needs is to
> invoke qrsh.

Right, but note that there are problems elsewhere. [I don't mean to
suggest that rayson et al don't understand, but it's already apparently
been missed, as below.]

Specifically you can't use libdrmaa with, for instance, GPL'd code that
doesn't have a suitable licence exception. Thus the SGE DRMAA is
useless for a significant number of potential applications -- consider
building a qmake with it rather than using qrsh, if that's technically
feasible (I don't know).

This is a problem with at least one tarball on the gridengine site --
the Python DRMAA binding, which claims a straight GPL licence; likewise
the Perl binding, which isn't on sunsource. I only realized this fairly
recently when looking at DRMAA, and I guess it's now too late to do
anything about it and make SGE DRMAA generally useful. The OGE
situation is no better, of course.

Note that there was some of the licensing on some files made for the
Debian packaging -- see the copyright file on the Debian package, and
relevant posts on debian-legal (?). I think that was never resolved in
the source. Also note that the headers on the current files don't obey
the requirements of the licence, since they don't mention `the original
code', which I think Debian didn't pick up.

--
Dave Love
Advanced Research Computing, Computing Services, University of Liverpool
AKA ***@gnu.org

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276272

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276836

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
laotsao
2010-08-25 15:41:47 UTC
Permalink
U can always install u6 in addition to u5 on the same system by using
different PORT and SGE_ROOT
http://gridengine.sunsource.net/project/gridengine/62patches.txt
list the bug fixed in u6
regards



On 8/25/2010 11:34 AM, wagoodman wrote:
> Hi all,
>
> At my site we have a licensed SGE 6.2U5, I put in a service request to sun and I get the
> same answer that everybody else is saying "it's fixed in release SGE 6.2U6". My only problem
> is, we just completed an upgrade two weeks ago... I had to request a major outage. Is there
> a quick fix or patch for this. I mean, my boss is going to blame me for not researching and
> testing out new release (which I did thoroughly), but I guess like everyone else, I didn't notice
> it. Also does that bug just effect reporting only or does it break functionality?
>
> Bill
>
> -----Original Message-----
> From: fx [mailto:***@liverpool.ac.uk]
> Sent: Monday, August 23, 2010 10:32 AM
> To: ***@gridengine.sunsource.net
> Subject: library licenses (was: Re: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE too low compared to top output on linux systems)
>
> rayson<***@gmail.com> writes:
>
>> qmake does not link against any SGE libraries - all it needs is to
>> invoke qrsh.
> Right, but note that there are problems elsewhere. [I don't mean to
> suggest that rayson et al don't understand, but it's already apparently
> been missed, as below.]
>
> Specifically you can't use libdrmaa with, for instance, GPL'd code that
> doesn't have a suitable licence exception. Thus the SGE DRMAA is
> useless for a significant number of potential applications -- consider
> building a qmake with it rather than using qrsh, if that's technically
> feasible (I don't know).
>
> This is a problem with at least one tarball on the gridengine site --
> the Python DRMAA binding, which claims a straight GPL licence; likewise
> the Perl binding, which isn't on sunsource. I only realized this fairly
> recently when looking at DRMAA, and I guess it's now too late to do
> anything about it and make SGE DRMAA generally useful. The OGE
> situation is no better, of course.
>
> Note that there was some of the licensing on some files made for the
> Debian packaging -- see the copyright file on the Debian package, and
> relevant posts on debian-legal (?). I think that was never resolved in
> the source. Also note that the headers on the current files don't obey
> the requirements of the licence, since they don't mention `the original
> code', which I think Debian didn't pick up.
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276839

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
wagoodman
2010-08-25 15:46:54 UTC
Permalink
Yeah, that would fly in development and test but not in production. I guess I should
have waited a couple of months... Thank for the advice.

Bill

-----Original Message-----
From: LaoTsao 老曹 [mailto:***@gmail.com]
Sent: Wednesday, August 25, 2010 11:42 AM
To: users
Cc: Goodman, William
Subject: Re: library licenses

U can always install u6 in addition to u5 on the same system by using different PORT and SGE_ROOT http://gridengine.sunsource.net/project/gridengine/62patches.txt
list the bug fixed in u6
regards



On 8/25/2010 11:34 AM, wagoodman wrote:
> Hi all,
>
> At my site we have a licensed SGE 6.2U5, I put in a service request to sun and I get the
> same answer that everybody else is saying "it's fixed in release SGE 6.2U6". My only problem
> is, we just completed an upgrade two weeks ago... I had to request a major outage. Is there
> a quick fix or patch for this. I mean, my boss is going to blame me for not researching and
> testing out new release (which I did thoroughly), but I guess like everyone else, I didn't notice
> it. Also does that bug just effect reporting only or does it break functionality?
>
> Bill
>
> -----Original Message-----
> From: fx [mailto:***@liverpool.ac.uk]
> Sent: Monday, August 23, 2010 10:32 AM
> To: ***@gridengine.sunsource.net
> Subject: library licenses (was: Re: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE too low compared to top output on linux systems)
>
> rayson<***@gmail.com> writes:
>
>> qmake does not link against any SGE libraries - all it needs is to
>> invoke qrsh.
> Right, but note that there are problems elsewhere. [I don't mean to
> suggest that rayson et al don't understand, but it's already apparently
> been missed, as below.]
>
> Specifically you can't use libdrmaa with, for instance, GPL'd code that
> doesn't have a suitable licence exception. Thus the SGE DRMAA is
> useless for a significant number of potential applications -- consider
> building a qmake with it rather than using qrsh, if that's technically
> feasible (I don't know).
>
> This is a problem with at least one tarball on the gridengine site --
> the Python DRMAA binding, which claims a straight GPL licence; likewise
> the Perl binding, which isn't on sunsource. I only realized this fairly
> recently when looking at DRMAA, and I guess it's now too late to do
> anything about it and make SGE DRMAA generally useful. The OGE
> situation is no better, of course.
>
> Note that there was some of the licensing on some files made for the
> Debian packaging -- see the copyright file on the Debian package, and
> relevant posts on debian-legal (?). I think that was never resolved in
> the source. Also note that the headers on the current files don't obey
> the requirements of the licence, since they don't mention `the original
> code', which I think Debian didn't pick up.
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276844

To unsubscribe from this discussion, e-mail: [users-un
laotsao
2010-08-25 16:02:06 UTC
Permalink
On 8/25/2010 11:46 AM, wagoodman wrote:
> Yeah, that would fly in development and test but not in production.
Of course U need this concern, but the feature of GE allow U to run
multiple versions in the same cluster, production or dev/test , IMHO.
Just like one use_* module*_ to control various version/type of MPI U do
the same by using various version of _settings.*sh_
to control the version of GE
regards


> I guess I should
> have waited a couple of months... Thank for the advice.
>
> Bill
>
> -----Original Message-----
> From: LaoTsao 老曹 [mailto:***@gmail.com]
> Sent: Wednesday, August 25, 2010 11:42 AM
> To: users
> Cc: Goodman, William
> Subject: Re: library licenses
>
> U can always install u6 in addition to u5 on the same system by using different PORT and SGE_ROOT http://gridengine.sunsource.net/project/gridengine/62patches.txt
> list the bug fixed in u6
> regards
>
>
>
> On 8/25/2010 11:34 AM, wagoodman wrote:
>> Hi all,
>>
>> At my site we have a licensed SGE 6.2U5, I put in a service request to sun and I get the
>> same answer that everybody else is saying "it's fixed in release SGE 6.2U6". My only problem
>> is, we just completed an upgrade two weeks ago... I had to request a major outage. Is there
>> a quick fix or patch for this. I mean, my boss is going to blame me for not researching and
>> testing out new release (which I did thoroughly), but I guess like everyone else, I didn't notice
>> it. Also does that bug just effect reporting only or does it break functionality?
>>
>> Bill
>>
>> -----Original Message-----
>> From: fx [mailto:***@liverpool.ac.uk]
>> Sent: Monday, August 23, 2010 10:32 AM
>> To: ***@gridengine.sunsource.net
>> Subject: library licenses (was: Re: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE too low compared to top output on linux systems)
>>
>> rayson<***@gmail.com> writes:
>>
>>> qmake does not link against any SGE libraries - all it needs is to
>>> invoke qrsh.
>> Right, but note that there are problems elsewhere. [I don't mean to
>> suggest that rayson et al don't understand, but it's already apparently
>> been missed, as below.]
>>
>> Specifically you can't use libdrmaa with, for instance, GPL'd code that
>> doesn't have a suitable licence exception. Thus the SGE DRMAA is
>> useless for a significant number of potential applications -- consider
>> building a qmake with it rather than using qrsh, if that's technically
>> feasible (I don't know).
>>
>> This is a problem with at least one tarball on the gridengine site --
>> the Python DRMAA binding, which claims a straight GPL licence; likewise
>> the Perl binding, which isn't on sunsource. I only realized this fairly
>> recently when looking at DRMAA, and I guess it's now too late to do
>> anything about it and make SGE DRMAA generally useful. The OGE
>> situation is no better, of course.
>>
>> Note that there was some of the licensing on some files made for the
>> Debian packaging -- see the copyright file on the Debian package, and
>> relevant posts on debian-legal (?). I think that was never resolved in
>> the source. Also note that the headers on the current files don't obey
>> the requirements of the licence, since they don't mention `the original
>> code', which I think Debian didn't pick up.
>>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276844
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276850

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
m0zes
2010-08-25 15:45:04 UTC
Permalink
The only thing broken by this bug seems to be memory accounting. It is
more of an annoyance for me than anything else, as I like to be able
to keep memory utilization in the accounting file.

--
Adam Tygart

On Wed, Aug 25, 2010 at 10:34, wagoodman <***@jcvi.org> wrote:
> Hi all,
>
> At my site we have a licensed SGE 6.2U5, I put in a service request to sun and I get the
> same answer that everybody else is saying "it's fixed in release SGE 6.2U6". My only problem
> is, we just completed an upgrade two weeks ago... I had to request a major outage. Is there
> a quick fix or patch for this. I mean, my boss is going to blame me for not researching and
> testing out new release (which I did thoroughly), but I guess like everyone else, I didn't notice
> it. Also does that bug just effect reporting only or does it break functionality?
>
> Bill
>
> -----Original Message-----
> From: fx [mailto:***@liverpool.ac.uk]
> Sent: Monday, August 23, 2010 10:32 AM
> To: ***@gridengine.sunsource.net
> Subject: library licenses (was: Re: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE too low compared to top output on linux systems)
>
> rayson <***@gmail.com> writes:
>
>> qmake does not link against any SGE libraries - all it needs is to
>> invoke qrsh.
>
> Right, but note that there are problems elsewhere.  [I don't mean to
> suggest that rayson et al don't understand, but it's already apparently
> been missed, as below.]
>
> Specifically you can't use libdrmaa with, for instance, GPL'd code that
> doesn't have a suitable licence exception.  Thus the SGE DRMAA is
> useless for a significant number of potential applications -- consider
> building a qmake with it rather than using qrsh, if that's technically
> feasible (I don't know).
>
> This is a problem with at least one tarball on the gridengine site --
> the Python DRMAA binding, which claims a straight GPL licence; likewise
> the Perl binding, which isn't on sunsource.  I only realized this fairly
> recently when looking at DRMAA, and I guess it's now too late to do
> anything about it and make SGE DRMAA generally useful.  The OGE
> situation is no better, of course.
>
> Note that there was some of the licensing on some files made for the
> Debian packaging -- see the copyright file on the Debian package, and
> relevant posts on debian-legal (?).  I think that was never resolved in
> the source.  Also note that the headers on the current files don't obey
> the requirements of the licence, since they don't mention `the original
> code', which I think Debian didn't pick up.
>
> --
> Dave Love
> Advanced Research Computing, Computing Services, University of Liverpool
> AKA ***@gnu.org
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276272
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276836
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276842

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
wagoodman
2010-08-25 15:48:40 UTC
Permalink
Thanks, that's what I thought...

I have seen or my users haven't complained yet.

Bill
-----Original Message-----
From: m0zes [mailto:***@gmail.com]
Sent: Wednesday, August 25, 2010 11:45 AM
To: ***@gridengine.sunsource.net
Subject: Re: library licenses (was: Re: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE too low compared to top output on linux systems)

The only thing broken by this bug seems to be memory accounting. It is
more of an annoyance for me than anything else, as I like to be able
to keep memory utilization in the accounting file.

--
Adam Tygart

On Wed, Aug 25, 2010 at 10:34, wagoodman <***@jcvi.org> wrote:
> Hi all,
>
> At my site we have a licensed SGE 6.2U5, I put in a service request to sun and I get the
> same answer that everybody else is saying "it's fixed in release SGE 6.2U6". My only problem
> is, we just completed an upgrade two weeks ago... I had to request a major outage. Is there
> a quick fix or patch for this. I mean, my boss is going to blame me for not researching and
> testing out new release (which I did thoroughly), but I guess like everyone else, I didn't notice
> it. Also does that bug just effect reporting only or does it break functionality?
>
> Bill
>
> -----Original Message-----
> From: fx [mailto:***@liverpool.ac.uk]
> Sent: Monday, August 23, 2010 10:32 AM
> To: ***@gridengine.sunsource.net
> Subject: library licenses (was: Re: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE too low compared to top output on linux systems)
>
> rayson <***@gmail.com> writes:
>
>> qmake does not link against any SGE libraries - all it needs is to
>> invoke qrsh.
>
> Right, but note that there are problems elsewhere.  [I don't mean to
> suggest that rayson et al don't understand, but it's already apparently
> been missed, as below.]
>
> Specifically you can't use libdrmaa with, for instance, GPL'd code that
> doesn't have a suitable licence exception.  Thus the SGE DRMAA is
> useless for a significant number of potential applications -- consider
> building a qmake with it rather than using qrsh, if that's technically
> feasible (I don't know).
>
> This is a problem with at least one tarball on the gridengine site --
> the Python DRMAA binding, which claims a straight GPL licence; likewise
> the Perl binding, which isn't on sunsource.  I only realized this fairly
> recently when looking at DRMAA, and I guess it's now too late to do
> anything about it and make SGE DRMAA generally useful.  The OGE
> situation is no better, of course.
>
> Note that there was some of the licensing on some files made for the
> Debian packaging -- see the copyright file on the Debian package, and
> relevant posts on debian-legal (?).  I think that was never resolved in
> the source.  Also note that the headers on the current files don't obey
> the requirements of the licence, since they don't mention `the original
> code', which I think Debian didn't pick up.
>
> --
> Dave Love
> Advanced Research Computing, Computing Services, University of Liverpool
> AKA ***@gnu.org
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276272
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276836
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276842

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276845

To unsubscribe from this discussion, e
templedf
2010-08-25 17:48:44 UTC
Permalink
If you have a support contract and a critical issue, you can always ask
for relief binaries.

Daniel

On 8/25/10 8:48 AM, wagoodman wrote:
> Thanks, that's what I thought...
>
> I have seen or my users haven't complained yet.
>
> Bill
> -----Original Message-----
> From: m0zes [mailto:***@gmail.com]
> Sent: Wednesday, August 25, 2010 11:45 AM
> To: ***@gridengine.sunsource.net
> Subject: Re: library licenses (was: Re: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE too low compared to top output on linux systems)
>
> The only thing broken by this bug seems to be memory accounting. It is
> more of an annoyance for me than anything else, as I like to be able
> to keep memory utilization in the accounting file.
>
> --
> Adam Tygart
>
> On Wed, Aug 25, 2010 at 10:34, wagoodman<***@jcvi.org> wrote:
>
>> Hi all,
>>
>> At my site we have a licensed SGE 6.2U5, I put in a service request to sun and I get the
>> same answer that everybody else is saying "it's fixed in release SGE 6.2U6". My only problem
>> is, we just completed an upgrade two weeks ago... I had to request a major outage. Is there
>> a quick fix or patch for this. I mean, my boss is going to blame me for not researching and
>> testing out new release (which I did thoroughly), but I guess like everyone else, I didn't notice
>> it. Also does that bug just effect reporting only or does it break functionality?
>>
>> Bill
>>
>> -----Original Message-----
>> From: fx [mailto:***@liverpool.ac.uk]
>> Sent: Monday, August 23, 2010 10:32 AM
>> To: ***@gridengine.sunsource.net
>> Subject: library licenses (was: Re: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE too low compared to top output on linux systems)
>>
>> rayson<***@gmail.com> writes:
>>
>>
>>> qmake does not link against any SGE libraries - all it needs is to
>>> invoke qrsh.
>>>
>> Right, but note that there are problems elsewhere. [I don't mean to
>> suggest that rayson et al don't understand, but it's already apparently
>> been missed, as below.]
>>
>> Specifically you can't use libdrmaa with, for instance, GPL'd code that
>> doesn't have a suitable licence exception. Thus the SGE DRMAA is
>> useless for a significant number of potential applications -- consider
>> building a qmake with it rather than using qrsh, if that's technically
>> feasible (I don't know).
>>
>> This is a problem with at least one tarball on the gridengine site --
>> the Python DRMAA binding, which claims a straight GPL licence; likewise
>> the Perl binding, which isn't on sunsource. I only realized this fairly
>> recently when looking at DRMAA, and I guess it's now too late to do
>> anything about it and make SGE DRMAA generally useful. The OGE
>> situation is no better, of course.
>>
>> Note that there was some of the licensing on some files made for the
>> Debian packaging -- see the copyright file on the Debian package, and
>> relevant posts on debian-legal (?). I think that was never resolved in
>> the source. Also note that the headers on the current files don't obey
>> the requirements of the licence, since they don't mention `the original
>> code', which I think Debian didn't pick up.
>>
>> --
>> Dave Love
>> Advanced Research Computing, Computing Services, University of Liverpool
>> AKA ***@gnu.org
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276272
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276836
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>
>>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276842
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276845
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276863

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
reuti
2010-08-25 15:59:57 UTC
Permalink
Am 25.08.2010 um 17:34 schrieb wagoodman:

> Hi all,
>
> At my site we have a licensed SGE 6.2U5, I put in a service request to sun and I get the
> same answer that everybody else is saying "it's fixed in release SGE 6.2U6". My only problem
> is, we just completed an upgrade two weeks ago... I had to request a major outage. Is there
> a quick fix or patch for this.

After you tested 6.2u6 (either on different ports or in a different cluster): you can patch a live system when it's only a minor update:

http://gridengine.sunsource.net/install62patch.txt

When it's working for the open source addition, it might also work for the commercial one (do on your own risk).

-- Reuti


> I mean, my boss is going to blame me for not researching and
> testing out new release (which I did thoroughly), but I guess like everyone else, I didn't notice
> it. Also does that bug just effect reporting only or does it break functionality?
>
> Bill
>
> -----Original Message-----
> From: fx [mailto:***@liverpool.ac.uk]
> Sent: Monday, August 23, 2010 10:32 AM
> To: ***@gridengine.sunsource.net
> Subject: library licenses (was: Re: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE too low compared to top output on linux systems)
>
> rayson <***@gmail.com> writes:
>
>> qmake does not link against any SGE libraries - all it needs is to
>> invoke qrsh.
>
> Right, but note that there are problems elsewhere. [I don't mean to
> suggest that rayson et al don't understand, but it's already apparently
> been missed, as below.]
>
> Specifically you can't use libdrmaa with, for instance, GPL'd code that
> doesn't have a suitable licence exception. Thus the SGE DRMAA is
> useless for a significant number of potential applications -- consider
> building a qmake with it rather than using qrsh, if that's technically
> feasible (I don't know).
>
> This is a problem with at least one tarball on the gridengine site --
> the Python DRMAA binding, which claims a straight GPL licence; likewise
> the Perl binding, which isn't on sunsource. I only realized this fairly
> recently when looking at DRMAA, and I guess it's now too late to do
> anything about it and make SGE DRMAA generally useful. The OGE
> situation is no better, of course.
>
> Note that there was some of the licensing on some files made for the
> Debian packaging -- see the copyright file on the Debian package, and
> relevant posts on debian-legal (?). I think that was never resolved in
> the source. Also note that the headers on the current files don't obey
> the requirements of the licence, since they don't mention `the original
> code', which I think Debian didn't pick up.
>
> --
> Dave Love
> Advanced Research Computing, Computing Services, University of Liverpool
> AKA ***@gnu.org
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276272
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276836
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276848

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
andy
2010-08-23 08:19:01 UTC
Permalink
Hi,

> Am 19.08.2010 um 19:06 schrieb fx:
>
>> <snip>
>>> I would also suggest to look into combining OGS with the "GNU Batch"
>>> scheduler - it would extend OGS with changable consumables depending
>>> on the result of a job, and use them to start another job and also
>>> cron-like features.
>> You can't combine SISSL code with GPL code.
> BTW: The right now available `qmake` is also based on the GNU make. In the source it's in the 3rdparty directory. So it should have never ever made it up to the binary package, as it must be available separately incl. it's source?

You need to have a close look how qmake, based on gmake is built: It
does not link with any SGE code, no SGE libs, nothing else. The gmake
code just received a few lines of code changes to call "qrsh -inherit",
which as an external program. So the SGE code is not "tainted" with GPL
code.

In addition for sure the GPL code is made available: it's part of the
gridengine source code repository and when you download SGE or get a DVD
you find the GPL code as part of it.

The gmake GPL copyright and legal disclaimers are retained in the source
code and the third party copyright file which is part if any binary SGE
distribution contains all of the legal disclaimers as well.

Yepp, keeping correctly track of all of the third party code is sth. you
need to do very carefully.

Andy


> -- Reuti
>
>
>> --
>> Dave Love
>> Advanced Research Computing, Computing Services, University of Liverpool
>> AKA ***@gnu.org
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275513
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275946
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276168

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
fx
2010-08-19 17:05:39 UTC
Permalink
opoplawski <***@cora.nwra.com> writes:

> I can update the Fedora gridengine packages if I have the source.

The problem with the Fedora packages (and Debian ones) is that they
assume several things, like non-shared $SGE_ROOT and default cell. I
have a modified Fedora-ish SRPM I've been meaning to sanitize and make
available.

--
Dave Love
Advanced Research Computing, Computing Services, University of Liverpool
AKA ***@gnu.org

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275512

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
rayson
2010-08-23 04:43:57 UTC
Permalink
On Wed, Aug 18, 2010 at 4:22 PM, Orion Poplawski <***@cora.nwra.com> wrote:
> I can update the Fedora gridengine packages if I have the source.

What version is the Grid Engine package in Fedora?

I finally checked in the compilation error fix today into revision 3:

http://sourceforge.net/projects/gridscheduler/

Rayson


>
> --
> Orion Poplawski
> Technical Manager                     303-415-9701 x222
> NWRA/CoRA Division                    FAX: 303-415-9702
> 3380 Mitchell Lane                  ***@cora.nwra.com
> Boulder, CO 80301              http://www.cora.nwra.com
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276136

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
fx
2010-08-23 14:38:13 UTC
Permalink
rayson <***@gmail.com> writes:

> What version is the Grid Engine package in Fedora?

It's 6.2u5, but that doesn't matter much when you have a useful SRPM and
can usually drop in a new tarball by -- typically -- deleting a few
patches. Note that it doesn't build (for trivial reasons) on the
RHEL-derived systems that most people are probably running if they have
something RH-ish.

It would be nice to concoct a common SRPM that

* Supports the different RPM-based distributions (Fedora, RHEL,
(Open)SuSE, Mandriva?);

* Supports both shared and local SGE_ROOT;

* Doesn't make assumptions about SGE_CELL and controlling the relevant
daemons on updates.

I think that's practical, but I've only done some of the work, which I'm
happy to contribute, of course.

The situation is similar for dpkg, as far as I can tell, but I don't get
to run a Debian-based system, unfortunately.

By the way, I'm not convinced by the need for a project like this to
build and distribute binaries, as people seem to be suggesting. Why is
it any different from other things you either just get from your
distro's repo or build packages of yourself?

--
Dave Love
Advanced Research Computing, Computing Services, University of Liverpool
AKA ***@gnu.org

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276277

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
opoplawski
2010-08-23 22:42:09 UTC
Permalink
On 08/22/2010 10:43 PM, rayson wrote:
> On Wed, Aug 18, 2010 at 4:22 PM, Orion Poplawski<***@cora.nwra.com> wrote:
>> I can update the Fedora gridengine packages if I have the source.
>
> What version is the Grid Engine package in Fedora?
>
> I finally checked in the compilation error fix today into revision 3:
>
> http://sourceforge.net/projects/gridscheduler/
>

That was patched in the Fedora package back on Apr 6 2009.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane ***@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276413

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
rayson
2010-09-10 04:18:33 UTC
Permalink
On Mon, Aug 23, 2010 at 6:42 PM, opoplawski <***@cora.nwra.com> wrote:
> That was patched in the Fedora package back on Apr 6 2009.

The idea is to not include & maintain external patches.

Also, the vmem problem is fixed in revision 4:

http://sourceforge.net/projects/gridscheduler/

Rayson




>
>
> --
> Orion Poplawski
> Technical Manager                     303-415-9701 x222
> NWRA/CoRA Division                    FAX: 303-415-9702
> 3380 Mitchell Lane                  ***@cora.nwra.com
> Boulder, CO 80301              http://www.cora.nwra.com
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276413
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=280884

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
ron
2010-09-10 12:50:27 UTC
Permalink
Anyone interested in testing the fix? It's a simple workaround and all you need is to compile the execd and run it on a node that can run jobs with greater than 4GB vmem.

-Ron


--- On Fri, 9/10/10, rayson <***@gmail.com> wrote:
> Also, the vmem problem is fixed in revision 4:
>
> http://sourceforge.net/projects/gridscheduler/
>
> Rayson
>
>
>
>
> >
> >
> > --
> > Orion Poplawski
> > Technical Manager                    
> 303-415-9701 x222
> > NWRA/CoRA Division                    FAX:
> 303-415-9702
> > 3380 Mitchell Lane                  ***@cora.nwra.com
> > Boulder, CO 80301              http://www.cora.nwra.com
> >
> >
> ------------------------------------------------------
> > http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276413
> >
> > To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
> >
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=280884
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=280955

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
hawson
2010-09-10 13:15:58 UTC
Permalink
Oh, h--- yes!


On Fri, Sep 10, 2010 at 08:50:27AM -0400, ron wrote:
>Anyone interested in testing the fix? It's a simple workaround and all you need is to compile the execd and run it on a node that can run jobs with greater than 4GB vmem.
>
> -Ron
>
>
>--- On Fri, 9/10/10, rayson <***@gmail.com> wrote:
>> Also, the vmem problem is fixed in revision 4:
>>
>> http://sourceforge.net/projects/gridscheduler/
>>
>> Rayson
>>
>>
>>
>>
>> >
>> >
>> > --
>> > Orion Poplawski
>> > Technical Manager ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
>> 303-415-9701 x222
>> > NWRA/CoRA Division ?? ?? ?? ?? ?? ?? ?? ?? ?? ??FAX:
>> 303-415-9702
>> > 3380 Mitchell Lane ?? ?? ?? ?? ?? ?? ?? ?? ??***@cora.nwra.com
>> > Boulder, CO 80301 ?? ?? ?? ?? ?? ?? ??http://www.cora.nwra.com
>> >
>> >
>> ------------------------------------------------------
>> > http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276413
>> >
>> > To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>> >
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=280884
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>
>
>------------------------------------------------------
>http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=280955
>
>To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

--
Jesse Becker
NHGRI Linux support (Digicon Contractor)

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=280960

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
rayson
2010-09-15 14:29:14 UTC
Permalink
Just to clarify, the fix is really small, as it is just a workaround.

We will continue to fix the code's lUlong & lLong issue, but that will
be in later releases.

In summary, what GridScheduler 6.2u5 patch 1 includes:

- everything in the SGE6.2u5 tree
- compilation fix on Fedora and later Linux distributions
- vmem accounting fix

Rayson



On Fri, Sep 10, 2010 at 9:15 AM, hawson <***@mail.nih.gov> wrote:
> Oh, h--- yes!
>
>
> On Fri, Sep 10, 2010 at 08:50:27AM -0400, ron wrote:
>>Anyone interested in testing the fix? It's a simple workaround and all you need is to compile the execd and run it on a node that can run jobs with greater than 4GB vmem.
>>
>> -Ron
>>
>>
>>--- On Fri, 9/10/10, rayson <***@gmail.com> wrote:
>>> Also, the vmem problem is fixed in revision 4:
>>>
>>> http://sourceforge.net/projects/gridscheduler/
>>>
>>> Rayson
>>>
>>>
>>>
>>>
>>> >
>>> >
>>> > --
>>> > Orion Poplawski
>>> > Technical Manager ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
>>> 303-415-9701 x222
>>> > NWRA/CoRA Division ?? ?? ?? ?? ?? ?? ?? ?? ?? ??FAX:
>>> 303-415-9702
>>> > 3380 Mitchell Lane ?? ?? ?? ?? ?? ?? ?? ?? ??***@cora.nwra.com
>>> > Boulder, CO 80301 ?? ?? ?? ?? ?? ?? ??http://www.cora.nwra.com
>>> >
>>> >
>>> ------------------------------------------------------
>>> > http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=276413
>>> >
>>> > To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>> >
>>>
>>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=280884
>>>
>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>
>>
>>------------------------------------------------------
>>http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=280955
>>
>>To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>
> --
> Jesse Becker
> NHGRI Linux support (Digicon Contractor)
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=280960
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=281896

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
fx
2010-09-15 13:44:21 UTC
Permalink
rayson <***@gmail.com> writes:

> On Mon, Aug 23, 2010 at 6:42 PM, opoplawski <***@cora.nwra.com> wrote:
>> That was patched in the Fedora package back on Apr 6 2009.
>
> The idea is to not include & maintain external patches.

It doesn't seem terribly useful if you won't accept contributions or use
a complete repo -- I have a pile of doc fixes, for instance.

I'm putting together a comprehensive repo to which I've added several
patches, including from Fedora and Debian, with more to check. It will
include Hedeby et al too, but I haven't done work on those, and I'm not
sure there are any post-u5 changes available for them currently.

It's currently held up sorting out hosting here and by some issues with
converting from CVS well. (The local hosting is to ensure I can run
alternative distributed version control systems and sync between them,
since I'm not sure which one is best.) If anyone is planning something
similar, please get in touch.

--
Dave Love
Advanced Research Computing, Computing Services, University of Liverpool
AKA ***@gnu.org

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=281891

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
rayson
2010-09-15 14:18:08 UTC
Permalink
On Wed, Sep 15, 2010 at 9:44 AM, fx <***@liverpool.ac.uk> wrote:
> rayson <***@gmail.com> writes:
>
>> On Mon, Aug 23, 2010 at 6:42 PM, opoplawski <***@cora.nwra.com> wrote:
>>> That was patched in the Fedora package back on Apr 6 2009.
>>
>> The idea is to not include & maintain external patches.
>
> It doesn't seem terribly useful if you won't accept contributions or use
> a complete repo -- I have a pile of doc fixes, for instance.

You got me wrong!! The idea of gridscheduler is to integrate external
(stable) patches into the tree.

And what we don't want to do is to include *seperate external* patches
together in the Fedora package. Also we also don't want to further
fork SGE or gridscheduler.

Can someone please test gridscheduler that has the vmem fix, and then
we can declare the current version as gridscheduler 6.2u5 patch 1, and
then can accept external contributions.

Rayson


>
> I'm putting together a comprehensive repo to which I've added several
> patches, including from Fedora and Debian, with more to check.  It will
> include Hedeby et al too, but I haven't done work on those, and I'm not
> sure there are any post-u5 changes available for them currently.
>
> It's currently held up sorting out hosting here and by some issues with
> converting from CVS well.  (The local hosting is to ensure I can run
> alternative distributed version control systems and sync between them,
> since I'm not sure which one is best.)  If anyone is planning something
> similar, please get in touch.
>
> --
> Dave Love
> Advanced Research Computing, Computing Services, University of Liverpool
> AKA ***@gnu.org
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=281891
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=281895

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
ron
2010-09-15 14:38:24 UTC
Permalink
Hi Dave,

Please don't further fork Grid Engine. While the Open Grid Scheduler has some interests in terms of contributors, we don't have enough testers to testdrive the first fix, which is supposed to affect a lot of SGE 6.2u4 & u5 users.

I think Sun complained about the lack of interest in testing beta releases of Grid Engine before, and since the Open Grid Scheduler does not offer binary packages yet, I am not surprised to see that the interest in testing the OGS code is low.

*However*, we do need people to test and use the code, otherwise the project will grow in a very slow speed.

-Ron


--- On Wed, 9/15/10, rayson <***@gmail.com> wrote:
> You got me wrong!! The idea of gridscheduler is to
> integrate external
> (stable) patches into the tree.
>
> And what we don't want to do is to include *seperate
> external* patches
> together in the Fedora package. Also we also don't want to
> further
> fork SGE or gridscheduler.
>
> Can someone please test gridscheduler that has the vmem
> fix, and then
> we can declare the current version as gridscheduler 6.2u5
> patch 1, and
> then can accept external contributions.
>
> Rayson
>
>
> >
> > I'm putting together a comprehensive repo to which
> I've added several
> > patches, including from Fedora and Debian, with more
> to check.  It will
> > include Hedeby et al too, but I haven't done work on
> those, and I'm not
> > sure there are any post-u5 changes available for them
> currently.
> >
> > It's currently held up sorting out hosting here and by
> some issues with
> > converting from CVS well.  (The local hosting is to
> ensure I can run
> > alternative distributed version control systems and
> sync between them,
> > since I'm not sure which one is best.)  If anyone is
> planning something
> > similar, please get in touch.
> >
> > --
> > Dave Love
> > Advanced Research Computing, Computing Services,
> University of Liverpool
> > AKA ***@gnu.org
> >
> >
> ------------------------------------------------------
> > http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=281891
> >
> > To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
> >
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=281895
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=281900

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
ffoertter
2010-09-15 15:02:44 UTC
Permalink
one could argue "why bother beta testing when fixes don't happen" ;)
it's a round-robin argument hehe

we could do like couples do: agree to disagree, kiss and make up and move on with renewed commitment that we can help so assuming we feel bugs are being prioritized and fixed :)

FF

On Sep 15, 2010, at 9:38 AM, ron wrote:

> Hi Dave,
>
> Please don't further fork Grid Engine. While the Open Grid Scheduler has some interests in terms of contributors, we don't have enough testers to testdrive the first fix, which is supposed to affect a lot of SGE 6.2u4 & u5 users.
>
> I think Sun complained about the lack of interest in testing beta releases of Grid Engine before, and since the Open Grid Scheduler does not offer binary packages yet, I am not surprised to see that the interest in testing the OGS code is low.
>
> *However*, we do need people to test and use the code, otherwise the project will grow in a very slow speed.
>
> -Ron
>
>
> --- On Wed, 9/15/10, rayson <***@gmail.com> wrote:
>> You got me wrong!! The idea of gridscheduler is to
>> integrate external
>> (stable) patches into the tree.
>>
>> And what we don't want to do is to include *seperate
>> external* patches
>> together in the Fedora package. Also we also don't want to
>> further
>> fork SGE or gridscheduler.
>>
>> Can someone please test gridscheduler that has the vmem
>> fix, and then
>> we can declare the current version as gridscheduler 6.2u5
>> patch 1, and
>> then can accept external contributions.
>>
>> Rayson
>>
>>
>>>
>>> I'm putting together a comprehensive repo to which
>> I've added several
>>> patches, including from Fedora and Debian, with more
>> to check. It will
>>> include Hedeby et al too, but I haven't done work on
>> those, and I'm not
>>> sure there are any post-u5 changes available for them
>> currently.
>>>
>>> It's currently held up sorting out hosting here and by
>> some issues with
>>> converting from CVS well. (The local hosting is to
>> ensure I can run
>>> alternative distributed version control systems and
>> sync between them,
>>> since I'm not sure which one is best.) If anyone is
>> planning something
>>> similar, please get in touch.
>>>
>>> --
>>> Dave Love
>>> Advanced Research Computing, Computing Services,
>> University of Liverpool
>>> AKA ***@gnu.org
>>>
>>>
>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=281891
>>>
>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=281895
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=281900
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=281905

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
rayson
2010-09-15 15:09:48 UTC
Permalink
May be we set the expectations too high :(

I think the major goal is to have a vey stable Grid Engine release --
Sun's approach of fixing bugs and introducing new features in the same
release sometimes can cause issues to the end users.

And by testing, we mean to have the fix tested outside of our lab's
machines. Grid Engine (Grid Scheduler) runs on many different
platforms, and testing on 1 or 2 is just not good enough!

Rayson



On Wed, Sep 15, 2010 at 11:02 AM, ffoertter <***@gmail.com> wrote:
> one could argue "why bother beta testing when fixes don't happen" ;)
> it's a round-robin argument hehe
>
> we could do like couples do: agree to disagree, kiss and make up and move on with renewed commitment that we can help so assuming we feel bugs are being prioritized and fixed :)
>
> FF
>
> On Sep 15, 2010, at 9:38 AM, ron wrote:
>
>> Hi Dave,
>>
>> Please don't further fork Grid Engine. While the Open Grid Scheduler has some interests in terms of contributors, we don't have enough testers to testdrive the first fix, which is supposed to affect a lot of SGE 6.2u4 & u5 users.
>>
>> I think Sun complained about the lack of interest in testing beta releases of Grid Engine before, and since the Open Grid Scheduler does not offer binary packages yet, I am not surprised to see that the interest in testing the OGS code is low.
>>
>> *However*, we do need people to test and use the code, otherwise the project will grow in a very slow speed.
>>
>> -Ron
>>
>>
>> --- On Wed, 9/15/10, rayson <***@gmail.com> wrote:
>>> You got me wrong!! The idea of gridscheduler is to
>>> integrate external
>>> (stable) patches into the tree.
>>>
>>> And what we don't want to do is to include *seperate
>>> external* patches
>>> together in the Fedora package. Also we also don't want to
>>> further
>>> fork SGE or gridscheduler.
>>>
>>> Can someone please test gridscheduler that has the vmem
>>> fix, and then
>>> we can declare the current version as gridscheduler 6.2u5
>>> patch 1, and
>>> then can accept external contributions.
>>>
>>> Rayson
>>>
>>>
>>>>
>>>> I'm putting together a comprehensive repo to which
>>> I've added several
>>>> patches, including from Fedora and Debian, with more
>>> to check.  It will
>>>> include Hedeby et al too, but I haven't done work on
>>> those, and I'm not
>>>> sure there are any post-u5 changes available for them
>>> currently.
>>>>
>>>> It's currently held up sorting out hosting here and by
>>> some issues with
>>>> converting from CVS well.  (The local hosting is to
>>> ensure I can run
>>>> alternative distributed version control systems and
>>> sync between them,
>>>> since I'm not sure which one is best.)  If anyone is
>>> planning something
>>>> similar, please get in touch.
>>>>
>>>> --
>>>> Dave Love
>>>> Advanced Research Computing, Computing Services,
>>> University of Liverpool
>>>> AKA ***@gnu.org
>>>>
>>>>
>>> ------------------------------------------------------
>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=281891
>>>>
>>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>>
>>>
>>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=281895
>>>
>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=281900
>>
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=281905
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=281908

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
fx
2010-09-20 23:33:11 UTC
Permalink
rayson <***@gmail.com> writes:

> I think the major goal is to have a vey stable Grid Engine release --
> Sun's approach of fixing bugs and introducing new features in the same
> release sometimes can cause issues to the end users.

Right. The recent regressions are a reason (a) to have a decent VCS to
help, and maintain useful branches and (b) have history in the repo to
assist with fixing them. It seems even the 5.3 source might be useful
if transfer queues need to be revived.

> And by testing, we mean to have the fix tested outside of our lab's
> machines. Grid Engine (Grid Scheduler) runs on many different
> platforms, and testing on 1 or 2 is just not good enough!

I suspect the number of interesting platforms is relatively small -- how
many people are interested in updates for Irix? -- and is dominated by
GNU/Linux. Anyhow, platform-specific issues are clearly dominated by
those due to different usage patterns.

--
Dave Love
Advanced Research Computing, Computing Services, University of Liverpool
AKA ***@gnu.org

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=282711

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
fx
2010-09-20 23:31:26 UTC
Permalink
ffoertter <***@gmail.com> writes:

> one could argue "why bother beta testing when fixes don't happen" ;)
> it's a round-robin argument hehe

Right. Sorry to be slow to provide anything more, but you can at least
try the gridengine CVS head (if you can build it) which will fix the
crashing qmaster issue, at least.

> we could do like couples do:

You're likely to have more freedom with free software :-/.

--
Dave Love
Advanced Research Computing, Computing Services, University of Liverpool
AKA ***@gnu.org

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=282713

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
fx
2010-09-20 23:29:48 UTC
Permalink
ron <***@yahoo.com> writes:

> Hi Dave,
>
> Please don't further fork Grid Engine.

I already have done, and I don't see why I shouldn't share the result.
I guess if it's useful to me, it'll be useful to others, and I'm happy
to assemble useful patches from gridscheduler or wherever. I'd rather
join a project doing what I need, and save some effort, but there isn't
one, and the whole point of using free software is that I can work on it
and share it as necessary, in line with the rationale on the gridengine
site.

> While the Open Grid Scheduler has some interests in terms of
> contributors, we don't have enough testers to testdrive the first fix,
> which is supposed to affect a lot of SGE 6.2u4 & u5 users.

It would be pointless to test something which would crash many times a
day (in our case).

> *However*, we do need people to test and use the code, otherwise the
> project will grow in a very slow speed.

I think the sine qua non is trivial installation on a current RedHat-ish
system (whatever one might think of it technically). It really needs to
be workable without having to drain the cluster in most cases, and
prospective testers need to know what they can get away with without
understanding the code -- particularly has the protocol changed. (I
should have said so in publishing patches.) As it is, the current code
won't actually build on recent GNU/Linux without at least hacking the
horrible aimk.

I'm currently trying to understand the build requirements on Debian and
RedHat outside the existing dkpg and rpm, especially for the Java bits
(ugh), and amend the instructions, which I hope will be useful.

--
Dave Love
Advanced Research Computing, Computing Services, University of Liverpool
AKA ***@gnu.org

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=282712

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
fx
2010-09-20 23:26:11 UTC
Permalink
"Olesen, Mark" <***@faurecia.com> writes:

> I've been using git for a few years now (I started off using it with
> OpenFOAM and it just spread from there).

Thanks, but I wasn't really after opinions. (Darcs has the nicest
model, but it doesn't currently do too well at this scale,
unfortunately.) This does definitely deserve a distributed system,
though, and needs to avoid gotchas like conflicts on the current style
of changelog maintenance. That's one reason not to put it on what might
otherwise be obvious hosting in UK academia.

Unfortunately I'm still held up with the new host I was going to use for
this and other things, but hope to get it going this week.

Maybe a name is important. `Sun of Grid Engine' is compatible, and
reasonably in line with hacker names for follow-ons.

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=282710

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
joelandman
2010-08-19 14:59:30 UTC
Permalink
rayson wrote:
> That's a good idea, but I don't have enough time to support each
> distro. It's 12:30am in Toronto and I am still up :(
>
> Someone interested in providing build support? I guess without Sun, we
> will need to handle many things ourselves!

Sorry I am late to this ... what do we need for build support?

--
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics Inc.
email: ***@scalableinformatics.com
web : http://scalableinformatics.com
http://scalableinformatics.com/jackrabbit
phone: +1 734 786 8423 x121
fax : +1 866 888 3112
cell : +1 734 612 4615

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275482

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
reidac
2010-08-19 16:04:16 UTC
Permalink
On Thu, Aug 19, 2010 at 10:59:30AM -0400, joelandman wrote:
> rayson wrote:
> > That's a good idea, but I don't have enough time to support each
> > distro. It's 12:30am in Toronto and I am still up :(
> >
> > Someone interested in providing build support? I guess without Sun, we
> > will need to handle many things ourselves!
>
> Sorry I am late to this ... what do we need for build support?

I'm not in a position to help directly, but I'm an enthusiastic
user of the Debian-packaged SGE.

There are already package maintainers for Debian, they're
listed on the package pages, e.g. here
<http://packages.debian.org/lenny/gridengine-client>, and those
guys should have access to Debian build-support resources.

Of course I do not speak for these guys, or whether they'd
continue supporting the new version, I just wanted to
point out that some support infrastructure already exists.

I would imagine that the situation is similar for other
Linux distros for which SGE is already packaged.

-- A.
--
Dr. Andrew C. E. Reid
Computer Operations Administrator
Center for Theoretical and Computational Materials Science
National Institute of Standards and Technology, Mail Stop 8910
Gaithersburg MD 20899 USA
***@nist.gov

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275492

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
rems0
2010-08-19 17:03:01 UTC
Permalink
On 08/18/2010 06:26 AM, rayson wrote:
> That's a good idea, but I don't have enough time to support each
> distro. It's 12:30am in Toronto and I am still up :(
>
> Someone interested in providing build support? I guess without Sun, we
> will need to handle many things ourselves!

What about using the openSUSE Build Service?
See https://build.opensuse.org/ .

Quote from https://build.opensuse.org/ :
"The openSUSE Build Service provides software developers with a
convenient and easy to use tool to create and release open source
software for openSUSE and other Linux distributions like Ubuntu, Fedora,
Mandriva and Debian on different hardware architectures and for a broad
user audience."


I never used it myself though.

regards,
Richard


--
Richard Ems mail: ***@Cape-Horn-Eng.com

Cape Horn Engineering S.L.
C/ Dr. J.J. Dómine 1, 5º piso
46011 Valencia
Tel : +34 96 3242923 / Fax 924
http://www.cape-horn-eng.com

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275508

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
hawson
2010-08-18 16:27:49 UTC
Permalink
On Tue, Aug 17, 2010 at 11:50:27PM -0400, rayson wrote:
>32-bit or 64-bit?
>
>I am running Fedora Core 13, which has newer versions of everything:
>gcc 4.4.4, kernel 2.6.33.6-147.2.4.fc13.x86_64, glibc 2.12. I will see
>if I can find an older machine.

I try to help building on Centos 5.x, 64bit systems.

Having a dedicated set of VMs for building (mentioned elsewhere on the
list) is a good idea.



>
>Rayson
>
>
>
>2010/8/17 jenny <***@genomics.org.cn>:
>> Hi Rayson,
>>
>> I use rocks v5.3 distributed a cluster, with centos 5.4, gcc 4.1.2, and sge
>> 6.2U4. Can the patch be built?
>>
>> thanks
>>
>> Jenny
>> ________________________________
>> ???????????? rayson
>> ??????????????? 2010-08-18 11:18:43
>> ???????????? users
>> ?????????
>> ????????? Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE
>> too low compared to top output on linux systems
>> What is your machine's Linux distribution and version?? I will see if
>> I can build the SGE source tree on a machine that has similar kernel &
>> glibc version as yours.
>> If I can find such a machine, or if you know how to build from source,
>> then you can expect a patch from me later this week or early next
>> week.
>> Rayson
>> On Mon, Aug 16, 2010 at 10:45 PM, jching <***@bbn.com> wrote:
>>> Thanks Ron, makes sense to wait for Rayson :)
>>>
>>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=274841
>>>
>>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275072
>> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>> __________ Information from ESET NOD32 Antivirus, version of virus signature database 5374 (20100817) __________
>> The message was checked by ESET NOD32 Antivirus.
>> http://www.eset.com
>
>------------------------------------------------------
>http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275078
>
>To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

--
Jesse Becker
NHGRI Linux support (Digicon Contractor)

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=275229

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
wagoodman
2010-10-05 14:40:38 UTC
Permalink
I have downloaded and installed the O|SGE 6.2 Update 6 and I'm still experiencing the same issue about O|SGE reporting memory is too low. Has anyone experience this also? BTW I have a licensed version. Even though I still should have 90 days evaluation (bug free) anyone?

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=285990

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
ron
2010-10-06 04:29:17 UTC
Permalink
--- On Tue, 10/5/10, wagoodman <***@jcvi.org> wrote:
> I have downloaded and installed the
> O|SGE 6.2 Update 6 and I'm still experiencing the same issue
> about O|SGE reporting memory is too low. Has anyone
> experience this also?

Did you compare with the output from top? I am sure OGE 6.2u6 has the fix for this issue. Are both the output of qacct and the output of the online info of "qstat -j <job id>" low?


> BTW I have a licensed version. Even
> though I still should have 90 days evaluation (bug free)
> anyone?

If you have paid then you don't need to worry, and if you have a support contract with Sun/Oracle that has not expired yet, then you don't need to worry about the 90-day evaluation thing, nor need to worry about the license change that we ranted about!

Otherwise, you can use SGE 6.2u5, and download & compile the source of OGS (Open Grid Scheduler), and then replace the execd with the one built from the OGS source.

Note that OGS is only a bug fixed version of SGE 6.2u5. It's for poor/cheap people (like me) who can't/don't want to pay (or for whatever reasons need to compile from source).

In case you did not follow the discussions, when Oracle open sources OGE again then we will merge the changes of OGS back to OGE, but if Oracle continues to keep OGE closed, then we will continue to develop OGS.

-Ron


>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=285990
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=286086

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
wagoodman
2010-10-06 17:28:57 UTC
Permalink
Ron,

I did not check the qacct -j <job_id> because that wouldn't give me the information real time.
However the way we upgrade here is only to the qmaster, (copying over the new binaries) we never
upgrade the execution hosts, are you saying that the execd needs to be upgraded? Oracle told me
that the fix was in SGE 6.2u6. So what you saying is I have to do a fresh install? not an upgrade
to fix it.

Bill

-----Original Message-----
From: ron [mailto:***@yahoo.com]
Sent: Wednesday, October 06, 2010 12:29 AM
To: ***@gridengine.sunsource.net
Subject: RE: [GE users] Re: Re: Re: [GE users] Issue seen in 6.2U5 : memory values reported bySGE too low compared to top output on linux systems

--- On Tue, 10/5/10, wagoodman <***@jcvi.org> wrote:
> I have downloaded and installed the
> O|SGE 6.2 Update 6 and I'm still experiencing the same issue
> about O|SGE reporting memory is too low. Has anyone
> experience this also?

Did you compare with the output from top? I am sure OGE 6.2u6 has the fix for this issue. Are both the output of qacct and the output of the online info of "qstat -j <job id>" low?


> BTW I have a licensed version. Even
> though I still should have 90 days evaluation (bug free)
> anyone?

If you have paid then you don't need to worry, and if you have a support contract with Sun/Oracle that has not expired yet, then you don't need to worry about the 90-day evaluation thing, nor need to worry about the license change that we ranted about!

Otherwise, you can use SGE 6.2u5, and download & compile the source of OGS (Open Grid Scheduler), and then replace the execd with the one built from the OGS source.

Note that OGS is only a bug fixed version of SGE 6.2u5. It's for poor/cheap people (like me) who can't/don't want to pay (or for whatever reasons need to compile from source).

In case you did not follow the discussions, when Oracle open sources OGE again then we will merge the changes of OGS back to OGE, but if Oracle continues to keep OGE closed, then we will continue to develop OGS.

-Ron


>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=285990
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=286086

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=286231

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
ron
2010-10-07 03:19:23 UTC
Permalink
--- On Thu, 10/7/10, wagoodman <***@jcvi.org> wrote:
> However the way we upgrade here is only to the qmaster,
> (copying over the new binaries) we never
> upgrade the execution hosts, are you saying that the execd
> needs to be upgraded?

Right, the memory bug is in the execd. You will need to make sure that the execution hosts are running SGE 6.2u6.

-Ron



> Oracle told me
> that the fix was in SGE 6.2u6. So what you saying is I have
> to do a fresh install? not an upgrade
> to fix it.
>
> Bill
>
> -----Original Message-----
> From: ron [mailto:***@yahoo.com]
>
> Sent: Wednesday, October 06, 2010 12:29 AM
> To: ***@gridengine.sunsource.net
> Subject: RE: [GE users] Re: Re: Re: [GE users] Issue seen
> in 6.2U5 : memory values reported bySGE too low compared to
> top output on linux systems
>
> --- On Tue, 10/5/10, wagoodman <***@jcvi.org>
> wrote:
> > I have downloaded and installed the
> > O|SGE 6.2 Update 6 and I'm still experiencing the same
> issue
> > about O|SGE reporting memory is too low. Has anyone
> > experience this also?
>
> Did you compare with the output from top? I am sure OGE
> 6.2u6 has the fix for this issue. Are both the output of
> qacct and the output of the online info of "qstat -j <job
> id>" low?
>
>
> > BTW I have a licensed version. Even
> > though I still should have 90 days evaluation (bug
> free)
> > anyone?
>
> If you have paid then you don't need to worry, and if you
> have a support contract with Sun/Oracle that has not expired
> yet, then you don't need to worry about the 90-day
> evaluation thing, nor need to worry about the license change
> that we ranted about!
>
> Otherwise, you can use SGE 6.2u5, and download &
> compile the source of OGS (Open Grid Scheduler), and then
> replace the execd with the one built from the OGS source.
>
> Note that OGS is only a bug fixed version of SGE 6.2u5.
> It's for poor/cheap people (like me) who can't/don't want to
> pay (or for whatever reasons need to compile from source).
>
> In case you did not follow the discussions, when Oracle
> open sources OGE again then we will merge the changes of OGS
> back to OGE, but if Oracle continues to keep OGE closed,
> then we will continue to develop OGS.
>
> -Ron
>
>
> >
> >
> ------------------------------------------------------
> > http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=285990
> >
> > To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
> >
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=286086
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=286231
>
> To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
>

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=286360

To unsubscribe from this discussion, e-mail: [users-***@gridengine.sunsource.net].
Loading...