Steve,
Regarding your topics B and C: i tried to explain these points 2 times in this
thread.
We thought about where to put it in the user's guide, but we didn't find a good
spot yet,
as most of this is rather technical and might confuse a normal user (who is
probably not
interested in gsiftp channels, hold states and notification messages).
> B) By default, globusrun-ws opens gsiftp channels to handle
> standard I/O. It does this when run from a simple command line.
No, by default globusrun-ws does not open gsiftp channels, only if the
streaming option
is specified (-s).
See http://www.globus.org/mail_archive/gt-user/2008/07/msg00196.html
> C) Probably, globusrun-ws does some unnecessary communications.
> At least some of these, for some purposes, the user does not want.
See http://www.globus.org/mail_archive/gt-user/2008/07/msg00196.html
Which ones are unnecessary if streaming is not specified?
Martin
Steve White wrote:
Charles,
Very good!
However, the documentaion only touches on point (1) of the three points
I made in the report.
It only mentions the issue with xinetd, but says nothing about the other
things that make globusrun-ws so slow, or what to do about them.
Keep up the good work!
On 30.07.08, Charles Bacon wrote:
I see that they have added documentation about the latency to the
current docs:
http://www.globus.org/toolkit/docs/4.2/4.2.0/data/gridftp/admin/gridftp-troubleshooting.html#gridftp-troubleshooting-latency
Additionally I removed the USERID/etc. entries from the example in the
2.4.3 docs that were being referenced.
Charles
On Jul 25, 2008, at 11:28 AM, Steve White wrote:
Hi,
Progress has been made in this long discussion, but it has gotten
rather
complicated.
Find attached a technical summary, including the observed problems,
diagnosis, and remedies, as well as further suggestions.
Let me address the question: is latency an important issue?
I contend that it is a matter of degree and of application. How big
is
the latency? What latency is required by the user and application?
How small a latency could be expected from grid job submission?
In some cases, the latency has been so bad that a user might wonder if
something was wrong, while they get a coffee.
On the other hand, if an application really demands very fast
interchange
of small messages, maybe the grid (and a wide-area network in
general) is
not a good environment for it. Maybe a cluster is called for.
Currently, at best globusrun-ws imposes a delay on small jobs some
five
times longer than that incurred by gsissh. That still amounts to a
humanly-palpable delay of several seconds.
Even if a code has been streamlined, it often in time picks up
baggage;
code streamlined for one purpose could be unnecessarily slow for
another.
In any case, it behooves us to strive for the best latency we can
get with
reasonable effort.
Some suggestions are in the report.
Cheers!
| - - - - - - - - - - - - - - - - - - - - - -
- - -
| Steve White
+49(331)7499-202
| e-Science / AstroGrid-D Zi. 35
Bg. 20
| - - - - - - - - - - - - - - - - - - - - - -
- - -
| Astrophysikalisches Institut Potsdam (AIP)
| An der Sternwarte 16, D-14482 Potsdam
|
| Vorstand: Prof. Dr. Matthias Steinmetz, Peter A. Stolz
|
| Stiftung privaten Rechts, Stiftungsverzeichnis Brandenburg: III/
7-71-026
| - - - - - - - - - - - - - - - - - - - - - -
- - -
<latency-globusrun_ws.txt>
