 |
 |
Uhm, thank you. Your results clearly show that a simple minded policy is not enough for that task. In the next couple of days i'll come up both with the ability to switch it off (for really fast apps not needing it) and with a more decent lookahead policy. Fabrizio On Tuesday 03 May 2005 02:17 pm, 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 > > > > --------------------------------------------------------------------- > > > >-- -- -- -------- Fabrizio Furano INFN - Istituto Nazionale di Fisica Nucleare [log in to unmask]