> Try this: > http://mastermind.com.pl/multicopy/ > > This is small tool I've wrote, that does use large memory buffers with > asynchronous I/O to copy file.
Thank you! This (with a drawback of blocking the entire system) does it! ( dzień dobry i dziękuję za tą konstruktywną odpowiedź na moje pytanie ) At least I know, that it works and you explain how it works, so I am now quite sure, that it will be also possible to have a Python tool which does the same thing. This way the discussion going towards driver hacking for the USB access was in my case just the wrong way, but anyway, thanks also for that to the contributors, because it sharpened my understanding of USB. Here my current test results on my Windows 2000 system with a 2.8 GHz P4 CPU and two 5 1/4" IDE-USB 2.0 casings (I have got from http://www.computeruniverse.net/ a German online shop, article no.: 90052509) by the way: does someone know an IDE-USB case able to perform data transfer faster than the max. 20 MByte/s I experience with one of my another IDE-USB 5 1/4" casings? ? ) : Single file copy: USB-1 to USB-2 = 11 MB/s, max. 70% CPU USB-2 to USB-1 = 11 MB/s, max. 70% CPU E-IDE to USB-1 = 12 MB/s, max. 70% CPU (first time) E-IDE to USB-1 = 13 MB/s, max. 70% CPU (second time same file) E-IDE to E-IDE = max. 45 MB/s (two physical drives) Simultaneous file copy: USB-1 to USB-2 = 5 MB/s USB-2 to USB-1 = 7 MB/s ------- 12 MB/s, max. 80% CPU Simultaneous file copy using http://mastermind.com.pl/multicopy/release/1.0.0/multicopy.exe : E-IDE to USB-1 = 10 MB/s E-IDE to USB-2 = 10 MB/s ------- 20 MB/s, unknown CPU load (1) (1) work with the PC during copying not possible, system "hangs" from 5 to 15 seconds between e.g. displaying current system time (with Windows clock). >From my point of view this thread has reached its end (I have a solution I can live with), except if someone would like to contribute or point to a better multicopy.exe which does not block the system or best to contribute or point to a _Python_ script or module which is able to find out the optimal buffer size for copying on the current system (and the best way of copying files), so that after this information is saved in an .INI file the tool is best adopted to the system it works on. I am quite sure, that there is a perfect ready-to-use solution out there (up to now I just only failed to find one by Googling, e.g. the tee.exe provided by http://unxutils.sourceforge.net/ doesn't work with large files at all), so please don't hesitate to provide it, so, that I don't need to "reinvent the wheel". Claudio "Jacek Trzmiel" <[EMAIL PROTECTED]> schrieb im Newsbeitrag news:[EMAIL PROTECTED] > > Claudio Grondi wrote: > > I am on a Widows 2000 box using the NTFS file system. > > Both up to now suggested approaches as > > - tee.exe (where I used the http://david.tribble.com/dos/tee.exe > > DOS-port with redirecting stdout to NULL) and > > - parallel copy (hoping caching does the job) are by far > > slower than the consecutive copy: > > single copy speed 12-15 MByte/s > > which gives effectively > > 6-7 MByte/s, > > tee.exe or twice copy in parallel > > 1-3 MByte/s. > > > > Any other suggestions except writing an own > > optimised version of tee.exe > > Try this: > http://mastermind.com.pl/multicopy/ > > This is small tool I've wrote, that does use large memory buffers with > asynchronous I/O to copy file. > > Following command: > multicopy c:\testfile d:\testfile e:\testfile f:\testfile > will copy c:\testfile to d, e and f disks. > > With four separate IDE disks I can copy file at about 30MB/s, which > means 120MB/s total I/O. You can give it a try, but I don't know if it > will work fast with USB drives. > > HTH, > sc0rp. -- http://mail.python.org/mailman/listinfo/python-list
