Ok,
as probably you have seen, I just committed an XrdClient test version able to
do async reads. Here are some considerations:
- async read ahead is enabled iff async mode is enabled (GO_ASYNC param)
- note that from now on, xrootd streamIDs and Logical Connection IDs are not
the same anymore, but they are linked through the XrdClientSid stuff. A
Logical connection can have as many stream ids it wants, and can treat them
together.
- XrdClient is able to handle max 65535 pending operations at a time
- a pending operation is a "normal" sync command stream or a pending async
request. At this time only reads are async-implemented.
- any application can request the server to send data (which will go into the
client side cache) through the Read_Async(offs, len) method. So, this is the
right path to follow if you have a long prefetch list. The result code will
tell you if you run out of streamids.
- you don't know when the async requested data will be delivered, neither the
order in which a prefetch list will be delivered. They are all parallel and
quite random even in simple apps.
Here are some other considerations:
- the actual read ahead algorithm is too trivial, smart apps like xrdcp (which
runs at optimal speed with its own big buffer) generate some network
overhead.
- slow apps, which "think" between consecutive reads will hopefully get the
maximum benefit, because the data will arrive while they think.
What to do now?
If you are curious you can play with the current version. In the meantime I
will integrate the latest patch for xrdcp and think about a readahead
algorithm which has to be smarter but not too much complex.
Fabrizio
--
--------
Fabrizio Furano
INFN - Istituto Nazionale di Fisica Nucleare
[log in to unmask]
|