Ken Lowther wrote:
> Jean-David Beyer wrote:
>
> >
> > For this line, the ...rate_limit is 2000 by default. While the tape drive and
> > controller are capable of that, my P166 is not reliably capable of keeping up,
> > so I slowed it down to 1000 (! Mb) and it works fine. I suggest you try that
> > speed first. With a P90, you just might have to go to 500, but I would not try
> > it unless 1000 does not work. Mine may restart a block once per entire pass of
> > the tape.
> >
>
> Actually, now that I think about it, the native "speed" of this drive is
> around 10 M/min. It claimed "Up to 20 M/min" in advertising. I used to
> wonder why it would 'write' faster than it would 'read'. Verifies
> always reported speeds around 9.xx M/min. Once while watching a backup
> I noticed that the software would start reporting higher backup rates as
> data compression rates went up. I concluded that the inherent speed of
> the device was around the 10 M/min. Anything above that was actually the
> software reporting speeds based on data compression transfer rates.
> This may account for the 'discrepency'. Yes, compression can make the
> data transfer faster, but the drive can only write the compressed data
> at 10 M/min. Could be a matter of whether you are measuring speed at
> the front end, data being transferred, or at the back end, where data is
> written. I would guess the numbers you are showing above would be based
> on hardware capability and has nothing at all to do with what else your
> system is doing. The hardware may never have been capable of any higher
> transfer rates (ie the 2000/1000 settings). My p90 can keep up under
> windoze (based on advertized claims), so I don't think it has anything
> to do with processor speed.
>
> I have a feeling that backing up the same material using both operating
> systems would probably bear this out. Not sure it is worth my trouble
> however. :)
I am quite sure the reason this goes faster in Windows than in Linux is because the
Windows software hijacks the Windows process scheduler and does not run other tasks
very well while the dinky-tape is in use. Writers of the driver for Linux refused
to violate the integrity of the Linux process scheduler to achieve higher tape
performance. That is why you can achieve the higher speeds in Windows, and why I
conjecture that the dinky-tape rate is more sensitive to CPU power/CPU load with
Linux than it is in Windows.
--
Jean-David Beyer .~.
Shrewsbury, New Jersey /V\
/( )\
Registered Linux User 85642. ^^-^^
S/MIME Cryptographic Signature
