Re: Nasty ext2fs bug!
On Aug 01, 2002 12:54 -0400, [EMAIL PROTECTED] wrote: Summary: When using lftp with the pget -n option for large files, once the file is complete the problem begins. If you try to copy, ftp, or pretty much anything that involves reading the file, it is stuck at a rate of 800KB/s to 1600KB/s. The problem is obvious - there are many threads writing to the same file, and the filesystem cannot really do a good job of allocating blocks for these threads. When you are reading the file back, the disk is seeking like crazy to read the data from the disk. It would be possible, even desirable, to have the block allocation algorithm try and keep enough empty space on the disk for sparsely written files, but this is a rather uncommon usage. If you copy from this fragmented file to a new file, then the new file is layed out contiguously on disk so readahead works and no seeking is involved when reading the new file. Problem: The pget -n feature of lftp is very nice if you want to maximize your download bandwidth, however, if getting a large file, such as the one I am getting, once the file is successfully retrived, transferring it to another HDD or FTPing it to another computer is very slow (800KB-1600KB/s). I find it hard to believe that this would actually make a huge difference, except in the case where the source is throttling bandwidth on a per-connection basis. Either your network is saturated by the transfer, or some point in between is saturated. I could be wrong, of course, and it would be interesting to hear the reasoning behind the speedup. Cheers, Andreas PS - thanks for the very detailed bug report - if only all bug reports were so full of useful information... -- Andreas Dilger http://www-mddsp.enel.ucalgary.ca/People/adilger/ http://sourceforge.net/projects/ext2resize/
Re: Nasty ext2fs bug!
On Thu, Aug 01, 2002 at 11:48:56AM -0600, Andreas Dilger wrote: Problem: The pget -n feature of lftp is very nice if you want to maximize your download bandwidth, however, if getting a large file, such as the one I am getting, once the file is successfully retrived, transferring it to another HDD or FTPing it to another computer is very slow (800KB-1600KB/s). I find it hard to believe that this would actually make a huge difference, except in the case where the source is throttling bandwidth on a per-connection basis. Either your network is saturated by the transfer, or some point in between is saturated. I could be wrong, of course, and it would be interesting to hear the reasoning behind the speedup. If some link is saturated with 1000 connections, you will get 1% of the bandwith instead of 0.1% if you use 10 concurrent connections. right? -- Ragnar Kjørstad
Re: Nasty ext2fs bug!
On Thu, Aug 01, 2002 at 08:27:18PM +0200, Ragnar Kj?rstad wrote: On Thu, Aug 01, 2002 at 11:48:56AM -0600, Andreas Dilger wrote: I find it hard to believe that this would actually make a huge difference, except in the case where the source is throttling bandwidth on a per-connection basis. Either your network is saturated by the transfer, or some point in between is saturated. I could be wrong, of course, and it would be interesting to hear the reasoning behind the speedup. If some link is saturated with 1000 connections, you will get 1% of the bandwith instead of 0.1% if you use 10 concurrent connections. right? wrong, you'll get 1% of the connections instead of 0.1%. So you'll be more responsible for the saturation of some active equipments which are sensible to connections, but this has nothing to do with the bandwidth, nor the link. It may be usefull only if you have a very high latency and a small TCP window, I think. Cheers, Willy
Re: Nasty ext2fs bug!
The remote link is an un-utilized T3. The downlink is a 3MBIT cable modem. Ragnar Kjørstad wrote: On Thu, Aug 01, 2002 at 11:48:56AM -0600, Andreas Dilger wrote: Problem: The pget -n feature of lftp is very nice if you want to maximize your download bandwidth, however, if getting a large file, such as the one I am getting, once the file is successfully retrived, transferring it to another HDD or FTPing it to another computer is very slow (800KB-1600KB/s). I find it hard to believe that this would actually make a huge difference, except in the case where the source is throttling bandwidth on a per-connection basis. Either your network is saturated by the transfer, or some point in between is saturated. I could be wrong, of course, and it would be interesting to hear the reasoning behind the speedup. If some link is saturated with 1000 connections, you will get 1% of the bandwith instead of 0.1% if you use 10 concurrent connections. right? -- Ragnar Kjørstad
Re: Nasty ext2fs bug!
My ISP = Adelphia. The area in which I live in has many problems, simply check: http://www.dslreports.com/forum/adelphia The post with 700+ threads is where I am. Basically, each thread from their service only gives you 10-20KB/s. To get any decent speed while downloading, you must download in parallel or split the file up. Willy Tarreau wrote: On Thu, Aug 01, 2002 at 08:27:18PM +0200, Ragnar Kj?rstad wrote: On Thu, Aug 01, 2002 at 11:48:56AM -0600, Andreas Dilger wrote: I find it hard to believe that this would actually make a huge difference, except in the case where the source is throttling bandwidth on a per-connection basis. Either your network is saturated by the transfer, or some point in between is saturated. I could be wrong, of course, and it would be interesting to hear the reasoning behind the speedup. If some link is saturated with 1000 connections, you will get 1% of the bandwith instead of 0.1% if you use 10 concurrent connections. right? wrong, you'll get 1% of the connections instead of 0.1%. So you'll be more responsible for the saturation of some active equipments which are sensible to connections, but this has nothing to do with the bandwidth, nor the link. It may be usefull only if you have a very high latency and a small TCP window, I think. Cheers, Willy
Re: Nasty ext2fs bug!
Since you CC'd yourself on your own mail, I'm assuming you want CC's on this. If you really do, you should probably add a Mail-Followup-To header. It'd be nice if you'd include your name in your From, so we have something other than jpiszcz to refer to you as, by the way. :) On Thu, Aug 01, 2002 at 12:54:06PM -0400, [EMAIL PROTECTED] wrote: Topic: Nasty ext2fs bug. Summary: When using lftp with the pget -n option for large files, once the file is complete the problem begins. If you try to copy, ftp, or pretty much anything that involves reading the file, it is stuck at a rate of 800KB/s to 1600KB/s. Problem: The pget -n feature of lftp is very nice if you want to maximize your download bandwidth, however, if getting a large file, such as the one I am getting in the example, once the file is successfully retrived, transferring it to another HDD or FTPing it to another computer is very slow (800KB-1600KB/s). I wonder if making lftp delay writes until it has a given amount of data would help. (This wouldn't be very good for link-link transfers, and might slow down link-drive transfers if it was set too high--a normal block size for writing to disk is typically 4k--but in this case it might be interesting to see if 128k helps.) That aside, ext2 shouldn't be fragmenting badly, even if we *are* doing that. It's designed to avoid that. However, writing to a file this way may be more than it can handle. a) [war@p300 x]$ /usr/bin/time cp 1GB /x2 0.41user 29.79system 1:33.19elapsed 32%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (97major+14minor)pagefaults 0swaps b) ftp get 1GB 1073741824 bytes received in 98.4 secs (1.1e+04 Kbytes/sec) You didn't include a comparison: FTPing the file normally to this host and copying it out, to show that it's actually substantially faster when you don't use pget. -- Glenn Maynard
Re: Nasty ext2fs bug!
Glenn Maynard wrote: Since you CC'd yourself on your own mail, I'm assuming you want CC's on this. If you really do, you should probably add a Mail-Followup-To header. It'd be nice if you'd include your name in your From, so we have something other than jpiszcz to refer to you as, by the way. :) On Thu, Aug 01, 2002 at 12:54:06PM -0400, [EMAIL PROTECTED] wrote: Topic: Nasty ext2fs bug. Summary: When using lftp with the pget -n option for large files, once the file is complete the problem begins. If you try to copy, ftp, or pretty much anything that involves reading the file, it is stuck at a rate of 800KB/s to 1600KB/s. Problem: The pget -n feature of lftp is very nice if you want to maximize your download bandwidth, however, if getting a large file, such as the one I am getting in the example, once the file is successfully retrived, transferring it to another HDD or FTPing it to another computer is very slow (800KB-1600KB/s). I wonder if making lftp delay writes until it has a given amount of data would help. (This wouldn't be very good for link-link transfers, and might slow down link-drive transfers if it was set too high--a normal block size for writing to disk is typically 4k--but in this case it might be interesting to see if 128k helps.) That aside, ext2 shouldn't be fragmenting badly, even if we *are* doing that. It's designed to avoid that. However, writing to a file this way may be more than it can handle. a) [war@p300 x]$ /usr/bin/time cp 1GB /x2 0.41user 29.79system 1:33.19elapsed 32%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (97major+14minor)pagefaults 0swaps b) ftp get 1GB 1073741824 bytes received in 98.4 secs (1.1e+04 Kbytes/sec) You didn't include a comparison: FTPing the file normally to this host and copying it out, to show that it's actually substantially faster when you don't use pget. What I tried to show is: after I get a file with pget -n 20, anything I do with it is slow. If I get a file any other way, I get 10MB/s+. -- Glenn Maynard
