Various discussions regarding Iomega Ditto drive speed have been held -
mostly centered around the host-unfriendly way that the DOS and/or Win
drivers manage to achieve the performance that they do. Ftape authors were
not prepared to break the principles of Unix application friendliness, so
we are stuck with slower (if more reliable) speeds. The real alternative
is to junk the (now obsolete) Ditto drives and swap to an OnStream drive
(native support in Ftape), or one of the many other IDE or SCSI drives.
In my setup, I restrict Ftape at initialisation in order to avoid those
time consuming repositions that occur after an overrun - the relevant
excerpts of my conf.modules follows:
alias char-major-27 zftape
options ftape -f ft_fdc_driver=ftape-internal,none,none,none
ft_tracings=3,3,3,3,3
options zftape -f ft_major_device_number=27
options ftape-internal -f ft_fdc_fc10=0 ft_fdc_mach2=0 ft_fdc_base=0x210
ft_fdc_irq=9 ft_fdc_dma=3 ft_fdc_rate_limit=2000
Hope this helps, Andy Corteen
"Fabio Lissandrini" <[EMAIL PROTECTED]>@vger.rutgers.edu
Sent by: [EMAIL PROTECTED]
29/11/99 10:36 CET
To:
<[EMAIL PROTECTED]>
cc:
Subject:
Overrun errors
After a few trial, I've been able to drive my ditto max with the Sept 11th
version (unstable) of ftape.
Now, I observe that the speed is very slow. I got, on the average, about
2Mbytes/minute: this means that, for a backup that is expected to fill a
5MB
tape, it will be necessary more than 41 hours!!! This fact seems strange.
So, I had a look at the system log, and I saw that very often there is an
"overrun error" followed by a retry that writes ok. Each overrun is
accompanied by a audible tape rewind of about a few 100ms. It's obvious
that
such a lot of mechanical rewinds increases the total time needed for a
backup, so slowing down the entire process.
I made a trial on the same pc, booted with dos, running the "ditto tools"
program furnished by Iomega. Doing a backup with this, there is no audible
rewinds, and the backup completes at a speed that is not revolutionary,
but
is almost three times faster than the linux trial.
So, it's clear to me that the problem is not hardware. The documentation
states that in order to avoid overruns, the parameter ft_fdc_threshold
should be put at 15. But this doesn't bring to any improvement.
Is there a way to avoid the overruns?
P.S. the configuration of the EZ board is quite correct. The same
io/irq/dma
found by isapnp has been used for the ftape initialization; they are not
used by another application; the ft_fdc_threshold is 15.
Thank you in advance.
Fabio Lissandrini
