 |
 |
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 __________________________________________