ok.. i seems that's the case. that seems kind of selfdefeating though. Ananth T Sarathy
On Thu, Aug 20, 2009 at 12:31 PM, Scott Carey <sc...@richrelevance.com>wrote: > If it always takes a very long time to start transferring data, get a few > stack dumps (jstack or kill -e) during this period to see what it is doing > during this time. > > Most likely, the client is doing nothing but waiting on the remote side. > > > On 8/20/09 8:02 AM, "Ananth T. Sarathy" <ananth.t.sara...@gmail.com> > wrote: > > > it's not really 1 mbps so much it takes 2 minutes to start doing the > > reads..... > > > > Ananth T Sarathy > > > > > > On Wed, Aug 19, 2009 at 4:30 PM, Scott Carey <sc...@richrelevance.com > >wrote: > > > >> > >> On 8/19/09 10:58 AM, "Raghu Angadi" <rang...@yahoo-inc.com> wrote: > >> > >>> Edward Capriolo wrote: > >>>>> On Wed, Aug 19, 2009 at 11:11 AM, Edward Capriolo > >>>>> <edlinuxg...@gmail.com>wrote: > >>>>> > >>>>>>>> It would be as fast as underlying filesystem goes. > >>>>>> I would not agree with that statement. There is overhead. > >>> > >>> You might be misinterpreting my comment. There is of course some over > >>> head (at the least the procedure calls).. depending on you underlying > >>> filesystem, there could be extra buffer copies and CRC overhead. But > >>> none of that explains transfer as slow as 1 MBps (if my interpretation > >>> of of results is correct). > >>> > >>> Raghu. > >> > >> > >> Yes, there is nothing about distributing work for parallel execution > that > >> is > >> going to make a single 20MB file transfer faster. That is very slow, > and > >> should be on the order of a second or so, not multiple minutes. > >> Something else is wrong. > >> > >> > >> > > > >
