[Swift-devel] CPU usage with provider-deef
Mike Wilde
wilde at mcs.anl.gov
Tue Jun 19 07:10:13 CDT 2007
Ioan, I feel that documenting the message flow is key to
understanding the system, and that such documentation will be
indispensable for you (and the Swift team) to make progress with Falkon.
If its the case, as you stated to me, that you dont have the time to
fully support Falkon for end-user use, which I accept, then the only
way to enable the Swift team to provide this support is for us to
understand the tool.
The three things you propose to communicate to us in a face-to-face
meeting (organization of the code, the message flow diagram,
configuration options) are exactly the things that need to be
documented.
But you and Ian together need to decide and propose how you want to
see Falkon used and how you intend to make it supportable for that
purpose.
For Swift's goals, we *know* we need Falkon's capabilities to
succeed, and the question is how much and how long can we use
Falkon, and when would we need to start improving or rewriting it.
- Mike
Mihael Hategan wrote, On 6/19/2007 3:22 AM:
> On Mon, 2007-06-18 at 16:37 -0500, Ioan Raicu wrote:
>> There is a diagram in the SC paper that has the flow of messages, and
>> what each does; these messages also map to the WSDL of the Falkon
>> service. Mihael, Ben, or whoever else wants to start digging through
>> the Falkon code, maybe a meeting might be good to go over the
>> organization of the code, the message flow diagram, configuration
>> options, etc... I would prefer a meeting over drafting up more
>> documents, I think it would be more time effective for me for now.
>
> It might be the reverse for us. It's unlikely that faced with a lot of
> new information, we will consistently retain all of it. Something of
> reference might be handy.
>
>> Ioan
>>
>> Ben Clifford wrote:
>>> The WSDL should describe part of the web services bit of the protocol.
>>> That might be a good place to start. The WSDL should already describe the
>>> messages that go over the wire in something vaguely readable to a human.
>>> Probably what would be needed would be the extra info to say which order
>>> messages are sent.
>>>
>>> On Sat, 16 Jun 2007, Mike Wilde wrote:
>>>
>>>
>>>> I think a nice clean message sequence chart describing Falkon's various
>>>> activities would be very useful, as its the backbone of its logic.
>>>>
>>>> I tried to create this for the SC paper by asking Ioan to describe the
>>>> protocol to me, but I dod not succeed.
>>>>
>>>> I think this would be a very useful description to maintain, as a UML sequence
>>>> chart, and that Ioan this would be a very important part of your thesis or of
>>>> future papers.
>>>>
>>>> Its up to you and Ian to weigh whether this would be valuable to your
>>>> research. I think its invaluable for design, review and debugging.
>>>>
>>>> - Mike
>>>>
>>>>
>>>>
>>>>
>>>> Mihael Hategan wrote, On 6/16/2007 3:15 PM:
>>>>
>>>>> On Sat, 2007-06-16 at 19:52 +0000, Ian Foster wrote:
>>>>>
>>>>>> I wasn't suggesting (at least in the first instance) that Mihael take the
>>>>>> prototype and turn it into production, but that Mihael and Ioan sit down
>>>>>> together and do a code walkthrough. I think that this would likely
>>>>>> identify bugs and opportunities for simplification.
>>>>>>
>>>>> It's somewhat on the same in level of fun :). From the experience I've
>>>>> accumulated so far, design is hard. Understanding prototype design is
>>>>> probably even harder (not only do you need to understand the problem,
>>>>> you also need to understand why many non-obvious things are done the way
>>>>> they are done).
>>>>>
>>>>> Mihael
>>>>>
>>>>>
>>>>>> Ian
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sent via BlackBerry from T-Mobile
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Ben Clifford <benc at hawaga.org.uk>
>>>>>>
>>>>>> Date: Sat, 16 Jun 2007 19:36:17 To:Mihael Hategan <hategan at mcs.anl.gov>
>>>>>> Cc:swift-devel at ci.uchicago.edu
>>>>>> Subject: Re: [Swift-devel] CPU usage with provider-deef
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, 16 Jun 2007, Mihael Hategan wrote:
>>>>>>
>>>>>>
>>>>>>> On Sat, 2007-06-16 at 12:03 -0500, Mike Wilde wrote:
>>>>>>>
>>>>>>>> This should be fun, and a nice break from the I2U2 work that you've
>>>>>>>> been immersed in, Mihael.
>>>>>>>>
>>>>>>> I have my reservations towards the amount of fun it involves.
>>>>>>>
>>>>>> Right, taking prototypes and turning them into production isn't
>>>>>> necessarily fun - in fact, a lot of the fun already happened with the
>>>>>> making of the prototype and the rest is some what drugery. (to an extent
>>>>>> that's the same situation i2u2 cosmic was/is in).
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Swift-devel mailing list
>>>>> Swift-devel at ci.uchicago.edu
>>>>> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel
>>>>>
>>>>>
>>>>>
>>> _______________________________________________
>>> Swift-devel mailing list
>>> Swift-devel at ci.uchicago.edu
>>> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel
>>>
>>>
>> --
>> ============================================
>> Ioan Raicu
>> Ph.D. Student
>> ============================================
>> Distributed Systems Laboratory
>> Computer Science Department
>> University of Chicago
>> 1100 E. 58th Street, Ryerson Hall
>> Chicago, IL 60637
>> ============================================
>> Email: iraicu at cs.uchicago.edu
>> Web: http://www.cs.uchicago.edu/~iraicu
>> http://dsl.cs.uchicago.edu/
>> ============================================
>> ============================================
>> _______________________________________________
>> Swift-devel mailing list
>> Swift-devel at ci.uchicago.edu
>> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel
>
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel
>
>
--
Mike Wilde
Computation Institute, University of Chicago
Math & Computer Science Division
Argonne National Laboratory
Argonne, IL 60439 USA
tel 630-252-7497 fax 630-252-1997
More information about the Swift-devel
mailing list