[EMAIL PROTECTED] wrote:
> I need a program that simultaneously can copy a single file (1 GB) from
> my pc to multiple USB-harddrives.
Why not just use:
copy c:\file.ext u:\file.exe
in one shell and in another
copy c:\file.ext v:\file.exe
where u: and v: are the USB drives?
There is usually not
> I need a program that simultaneously can copy a single file (1
> GB) from my pc to multiple USB-harddrives.
Sounds like a pretty simple simple python script:
---
#!/bin/env python
def spew(source_file_name,
output_file_names,
On Mon, 21 Mar 2005 00:17:05 +0100, rumours say that Heiko Wundram
<[EMAIL PROTECTED]> might have written:
>Well, 430 MB/s is only for USB 2.0.
It's 480 Mb/s (megabit or mebibit, I am not sure... :), so it maxes at
about 60 MB/s (or MiB/s) for all devices on the same controller.
--
TZOTZIOY, I
On Sun, 20 Mar 2005 22:06:03 +0100, rumours say that Rolf Zwart
<[EMAIL PROTECTED]> might have written:
>On Unixes I know, only 1 process is needed:
>/dev/null
>It does work!
Of course it does. Why wouldn't it? Or are you referring to the fact
that redirection can appear anywhere on the command
On Mon, 21 Mar 2005 17:53:34 +0100, Jacek Trzmiel <[EMAIL PROTECTED]> wrote:
>
>> > This is small tool I've wrote, that does use large memory buffers with
>> > asynchronous I/O to copy file.
>
>Claudio Grondi wrote:
>> Thank you!
>> This (with a drawback of blocking the entire system) does it!
>>
> > This is small tool I've wrote, that does use large memory buffers with
> > asynchronous I/O to copy file.
Claudio Grondi wrote:
> 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 )
:)
> From
> 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 py
> Well, 430 MB/s is only for USB 2.0. AFAIK, most devices (esp. storage
> devices) are still only USB 1.1 compliant, which makes this rate go down
> to a mere 40 MB/s or something close.
I think it is 430 MBit(!), so about 50MB per second. The old usb 1.1 has
12MBits. So I don't think that Claudio
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
> slo
Am Sonntag, 20. März 2005 23:16 schrieb Claudio Grondi:
> 2) if I understand it right, an USB controller is connected to
> to the PCI bus and there can be many separate USB
> controller on one PC
Yes, there may be more than one USB-controller in a PC, but this doesn't
matter, they are all connect
>
> Nope. Or yes. Here comes into play why Heiko said think of what USB stands
> for. While the devices appear to be responsive concurrently (the bus
> arbitration and multiplexing/demultiplexing is tranparent to the user), it
> still is a serial bus, so at a given point in time you can only writ
> 2) if I understand it right, an USB controller is connected to
> to the PCI bus and there can be many separate USB
> controller on one PC
True.
> 3) the theoreticall speed of USB (430 MByte/s?) is much
> higher as the experienced 15 MByte/s, probably due to slow
> controller on the side of the
I don't know any deep details about USB, except that
I _know_ that it is a serial bus, but considering
following:
1) I can read/write 45 MByte/s from harddrive to harddrive
on the E-IDE bus (theoretically 100 MByte/s), so the
speed of the harddrive I read/write from/to is probably the
bottleneck.
Swaroop C H wrote:
[...]
If you are using *nix, maybe you can use the `tee` command[1] and
redirect the file to different places.
For example,
cat | tee file1 | tee file2 > file3
On Unixes I know, only 1 process is needed:
/dev/null
It does work!
** Rolf
I haven't tried it out but it should work.
On Sunday 20 March 2005 17:16, Claudio Grondi wrote:
> Is there maybe a way to use a direct DMA
> transfer to multiple target destinations
> (I copy to drives connected via USB ports) ?
Think about what USB stands for. Then reconsider whether you'll ever have the
chance of writing truly simultane
means your message, that you think, that
the consecutive copy is the fastest possible
method if using Windows 2000?
Claudio
"Grant Edwards" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
news:[EMAIL PROTECTED]
> On 2005-03-20, Claudio Grondi <[EMAIL PROTECTED]> wrote:
>
> > Is there maybe a way to u
On 2005-03-20, Claudio Grondi <[EMAIL PROTECTED]> wrote:
> Is there maybe a way to use a direct DMA
> transfer to multiple target destinations
> (I copy to drives connected via USB ports) ?
Sure, but you'll have to throw away your OS, and write a
program that runs on the bare metal.
> Can someon
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:
si
Claudio Grondi wrote:
>
> I would like to save time copying the same file
> (>6 GByte) to various different target storage
> media connected to the system via USB.
>
> Is there a (Python or other) tool able to help me
> to do this, so that I don't need to copy the
> source file first to the fir
On Sun, 20 Mar 2005 11:41:10 -, Claudio Grondi
<[EMAIL PROTECTED]> wrote:
> I would like to save time copying the same file
> (>6 GByte) to various different target storage
> media connected to the system via USB.
>
> Is there a (Python or other) tool able to help me
> to do this, so that I do
20 matches
Mail list logo
