ooops - sent to wrong adress first, here we go:

> Your problem sounds very similar to one that came up not too long ago. 
> In that case it turned out that the USB-IDE interface was unable to
> handle data flows that were too fast.  As more and more data was
> transferred, the interface would just crash and require time-consuming
> error recovery.  The transfers just slowed down to a crawl, while
> unwritten buffers filled up the memory.

Thanks for the information :)
That indeed is not totally unlikely. After a new test I did today, I
noticed that my kernel does indeed not totally crash, but this happens:
The transfer indeed slows down very much, and at some point (with about 2
MB of Ram left ;) ) it stopped. My drive signaled no more activity. I
could still switch consoles on my linux, but none of them would accept
keyboard input. MagicSysRq Key still worked.
I will compile a 2.6.0-test kernel and try for the rsync and bandwidth
limiting, just to see if that is the problem.
Thanks for the hint. 

Indeed, I just did that(compile and try with rsync), but this does not
really seem to help. It (rsync bandwith throtteling) just slows down the
process, making buffers in memory increase slower. I can see when commands
are sent to the device (which are not a continuing stream, but more like a
series of commands, pausing in between due to the bandwidth limiting.
Maybe I need to lower it a lot more - I tried with rsync and between 50 kb
and 20 kb), seeing it work in turn with those bursts and pausing in
between.
When the transfer begins, for a time nothing happens. I suspect the
buffers of the USB to IDE connector, or of the HDD itself first fill - and
then the commands are sent to the device. :(
Is there anything I could do about it? (heh - maybe I have to learn to
write my own driver... or just sell this stupid thing :( )

-- 
Today is Setting Orange, the 54th day of Confusion in the YOLD 3169

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to