 |
 |
Hi Pete, yes, you are right. Those messages are regular kXR_ok, which, if the client is able to find a pending request for them, are treated as unsolicited responses. The client does that by using the data structures built upon XrdOucRash, which are supposed to give quite little overhead. Hence the debugging of that infrastructure is complete. Async responses (or messages treated that way) are internally dispatched to the entities which are interested in them, in a way which is concurrent, since it's triggered by the receiver thread in XrdClientPhysicalConnection. While this is in progress, the app is free to process, and should be even able to issue other requests. If some day an unsolicited response will come, I have "only" to write a handler for that. I had a mail exchange with Gerri, and now with Ulrich, from which it became clear to me how I have to modify the policy for requesting a big block in advance (without causing brutal processing overhead). Also, expecially under ROOT, there are some situations in which such a mechanism must be switched temporarily off. I will take care of this in these days, after my furious debugging sessions (not on XrdClient...). Fabrizio Peter Elmer wrote: > Hi Fabrizio, > > Ah, the responses from the server here are implemented effectively as > unsolicited responses? (Or at least the client is handling them that way, > so at least some debugging of that infrastructure has now been done?) > > One small detail: could you add something to the debugging printout: > > >>050503 14:08:04 27096 Xrd: ConnectionMgr Processing unsolicited response >>050503 14:08:04 27096 Xrd: LogConnection Processing unsolicited response > > > so that it prints also the kXR_async* code for the response received? (Staying > at less than 80 characters, of course ;-) > > Pete > > On Tue, May 03, 2005 at 02:17:47PM +0200, Ulrich Schwickerath wrote: > >>Hi, Fabrizio, >> >>Sure. The numbers I just sent were NON-InfiniBand, it is the unchanged code >>compiled without patch and run over GE ethernet (no IPoIB or any other fancy >>stuff involved). For InfiniBand the degradation of the performance is >>smaller. Sorry for being unprecise here. >> >>So, here is the ethernet output: >>$time bin/arch/xrdcp -np -DIDebugLevel 1 >>root://iwrcgtest.fzk.de//tmp/testfile.dat /dev/null >& ethernet.log >> >>real 0m28.277s >>user 0m1.400s >>sys 0m0.290s >> >>gives: >>Overriding 'DebugLevel' with value 1. Final value: 1 >>050503 14:08:04 001 Xrd: main (C) 2004 SLAC INFN xrdcp 0.2 beta >>050503 14:08:04 001 Xrd: Create (C) 2004 SLAC INFN XrdClient 0.3 >>050503 14:08:04 001 Xrd: XrdClientUrlSet List of servers to connect to is >>[iwrcgop028.fzk.de] >>050503 14:08:04 001 Xrd: ShowUrls The converted URLs count is 1 >>050503 14:08:04 001 Xrd: ShowUrls URL n.1: iwrcgop028.fzk.de:1094//. >>050503 14:08:04 001 Xrd: Create Access to server granted. >>050503 14:08:04 001 Xrd: Create Opening the remote file /tmp/testfile.dat >>050503 14:08:04 001 Xrd: Create File opened succesfully. >>050503 14:08:04 001 Xrd: main root://iwrcgop028.fzk.de//tmp/testfile.dat >>--> /dev/null >>050503 14:08:04 27096 Xrd: ConnectionMgr Processing unsolicited response >>050503 14:08:04 27096 Xrd: LogConnection Processing unsolicited response >>050503 14:08:04 27096 Xrd: ConnectionMgr Processing unsolicited response >>050503 14:08:04 27096 Xrd: LogConnection Processing unsolicited response >>050503 14:08:04 27096 Xrd: ConnectionMgr Processing unsolicited response >>050503 14:08:04 27096 Xrd: LogConnection Processing unsolicited response >>050503 14:08:04 27096 Xrd: ConnectionMgr Processing unsolicited response >>050503 14:08:04 27096 Xrd: LogConnection Processing unsolicited response >>050503 14:08:04 27096 Xrd: ConnectionMgr Processing unsolicited response >>050503 14:08:04 27096 Xrd: LogConnection Processing unsolicited response >>050503 14:08:04 27096 Xrd: ConnectionMgr Processing unsolicited response >>050503 14:08:04 27096 Xrd: LogConnection Processing unsolicited response >>050503 14:08:04 27096 Xrd: ConnectionMgr Processing unsolicited response >>050503 14:08:04 27096 Xrd: LogConnection Processing unsolicited response >>050503 14:08:04 27096 Xrd: ConnectionMgr Processing unsolicited response >>050503 14:08:04 27096 Xrd: LogConnection Processing unsolicited response >>050503 14:08:04 27096 Xrd: ConnectionMgr Processing unsolicited response >>050503 14:08:04 27096 Xrd: LogConnection Processing unsolicited response >>050503 14:08:04 27096 Xrd: ConnectionMgr Processing unsolicited response >>050503 14:08:04 27096 Xrd: LogConnection Processing unsolicited response >>050503 14:08:04 27096 Xrd: ConnectionMgr Processing unsolicited response >>050503 14:08:04 27096 Xrd: LogConnection Processing unsolicited response >>050503 14:08:04 27096 Xrd: ConnectionMgr Processing unsolicited response >>050503 14:08:04 27096 Xrd: LogConnection Processing unsolicited response >>050503 14:08:04 27096 Xrd: ConnectionMgr Processing unsolicited response >>050503 14:08:04 27096 Xrd: LogConnection Processing unsolicited response >>050503 14:08:04 27096 Xrd: ConnectionMgr Processing unsolicited response >>050503 14:08:04 27096 Xrd: LogConnection Processing unsolicited response >>050503 14:08:04 27096 Xrd: ConnectionMgr Processing unsolicited response >>.... (repeated in total 41984 times for my 1GB test file) >>050503 14:08:32 27096 Xrd: LogConnection Processing unsolicited response >>Caching info: MissRate=0.611176 MissCount=2625 ReadsCounter=4295 >>Caching info: BytesUsefulness=0.198375 BytesSubmitted=3280128680 >>BytesHit=650623344 >> >>If I apply my InfiniBand patch, it looks quite similar. Please let me know if >>this helps. >> >>Thank's, >>Ulrich >> >>Am Dienstag 03 Mai 2005 01:34 nachmittags/abends schrieb Fabrizio Furano: >> >>>Hi, >>> >>> maybe you don't miss anything. I suspect that you found a way (Infiniband) >>>to greatly confuse the trivial async read ahead algorithm I coded for the >>>first version of the async read ahead. I may be wrong, of course. >>>In any case xrdcp does not need read ahead at all so it's better if I make >>>it an option, as it's needed in other cases also. Async read ahead could be >>>a help if you have an application which processes the data, otherwise it's >>>useless. >>> >>> If you set the debug level to a higher value (-DI DebugLevel 1), 1 should >>>be sufficient, xrdcp will print you the cache statistics, so we can learn >>>something to tune this strange async thing if that is the source of the >>>overhead. Would you do this on your setup please? >>> >>>Fabrizio >>> >>>On Tuesday 03 May 2005 12:00 pm, Ulrich Schwickerath wrote: >>> >>>>Hi, >>>> >>>>I made a quick first test running the new version on an GB Ethernet link. >>>>I just copy a 1GByte file from my server to local /dev/null. While with >>>>20050413-0433 I got >>>> >>>>$ time bin/arch/xrdcp root://iwrcgtest.fzk.de//tmp/testfile.dat >>>>/dev/null >>>> >>>>real 0m10.909s >>>>user 0m1.150s >>>>sys 0m0.720s >>>> >>>>with the new version I get: >>>> >>>>[schwicke@iwrcgop027:/home/schwicke/Progamming/xrootd]$ time >>>>bin/arch/xrdcp root://iwrcgtest.fzk.de//tmp/testfile.dat /dev/null >>>>[xrootd] Total 1024.00 MB |====================| 100.00 % [36.6 >>>>Mb/s] >>>> >>>>real 0m29.377s >>>>user 0m1.670s >>>>sys 0m1.190s >>>> >>>>Going to quiet mode does not help (my first thought since I work >>>>remotely): $ time bin/arch/xrdcp -s >>>>root://iwrcgtest.fzk.de//tmp/testfile.dat /dev/null >>>> >>>>real 0m28.147s >>>>user 0m1.150s >>>>sys 0m0.380s >>>> >>>>The test is done on Sun V20z dual Opterons, both for server and client, >>>>using the onboard GE link. >>>> >>>>Did I miss something ? >>>> >>>>Thank's, >>>>Ulrich >>>> >>>>On Monday 02 May 2005 17:04, Peter Elmer wrote: >>>> >>>>> Hi All, >>>>> >>>>> There is now a new development version of xrootd (20050502-0000). >>>>>This version contains a lot of new code, so it is meant for testing >>>>>rather than production use. For production use, please try version >>>>>20050328-0656 instead. >>>>> >>>>> The changes include: >>>>> >>>>> o compilation fixes for gcc4 >>>>> o updates to XrdClient for async read-ahead >>>>> o updates to xrdcp from Andreas Peters >>>>> o Many updates to scripts in XrdMon package >>>>> o Code cleanup fixes (from Gregory Sharp) >>>>> o Several fixes for minor bugs, etc. >>>>> >>>>> We should start testing this (including compilation on the full set >>>>>of ROOT platforms) as I'd like to try to turn out a new production >>>>>release in the next week or two. >>>>> >>>>> For the full set of changes and links to rpms/tarballs to download >>>>>see the the xrootd web page and/or version history: >>>>> >>>>> http://xrootd.slac.stanford.edu >>>>> http://xrootd.slac.stanford.edu/xrootd.History >>>>> >>>>>Let us know if there are problems. >>>>> >>>>> thanks, >>>>> Pete >>>>> >>>>>----------------------------------------------------------------------- >>>>>-- Peter Elmer E-mail: [log in to unmask] Phone: +41 (22) >>>>>767-4644 Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, >>>>>Switzerland >>>>>----------------------------------------------------------------------- >>>>>-- >> >>-- >>__________________________________________ >>Dr. Ulrich Schwickerath >>Forschungszentrum Karlsruhe >>GRID-Computing and e-Science >>Institut for Scientific Computing (IWR) >>P.O. Box 36 40 >>76021 Karlsruhe, Germany >> >>Tel: +49(7247)82-8607 >>Fax: +49(7247)82-4972 >> >>e-mail: [log in to unmask] >>PGP DH/DSS Key: ID 0xCEB9826F >>Fingerprint: 5537 8473 CD26 507E 8EE2 BAAF 98E2 FD16 CEB9 826F >>__________________________________________ > > > > > ------------------------------------------------------------------------- > Peter Elmer E-mail: [log in to unmask] Phone: +41 (22) 767-4644 > Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland > -------------------------------------------------------------------------