On 7/7/2011 7:56 AM, Rugxulo wrote: > Hi, > (yes, I tried trimming the quote, but it almost all seems vaguely > relevant, ugh) > > At risk of embarrassing myself (again) by showing my ignorance ... > > Mike, you said this: "Disk becomes the major bottleneck on the faster > machines." > > Doesn't FTP know the filesize of file-to-be-downloaded ahead of time? > If so, then perhaps you can try Eric's idea: > > * create/open, seek to end-1 (in the empty output file), write a > single byte, close, reopen > > This apparently avoids having to update the FAT over and over again > redundantly. See the following thread for some examples (esp. nidud's > comment about Doszip: "This reduced the compression time from 455 to > 180 sec."). > > http://www.bttr-software.de/forum/board_entry.php?id=8862#p8879 > > I may be seriously off-base here (no surprise), but I felt I should > mention it "just in case"! >
Interesting, and probably part of the reason why 8KB writes were much more efficient than 1KB writes. Since DOS is adjusting the FAT each time the file grows there is more work to do for the smaller block sizes. The mTCP client does not query the file size before starting a download; it requires another command to be inserted before the GET, kind of the way that PORT and PASV commands are inserted. It's an involved change, but if it has the potential to make the disk writes faster I'd be happy to try it. (I'll see if it makes a noticeable difference first by receiving to a file that is already created and is at the right size. In theory that transfer will happen faster than if the file is not created yet.) For error recovery you would not want to leave a full sized by half written file laying around. It looks like chsize is the right way to truncate the file to the correct size after the TCP socket is closed. Mike ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
