David Campbell (campbell@gear.torque.net)
Fri, 6 Feb 1998 07:58:27 +0000
> From: "Bas Mevissen" <sgm@stack.nl>
> : From: Andrea Arcangeli <arcangeli@mbox.queen.it>
> : On Thu, 5 Feb 1998, Riley Williams wrote:
> :
> : > > There is a known "feature" (problem) with VFAT/UMSDOS/MSDOS
> : > > partitions on ZIP disks. It has to do with MSDOS <=> UNIX text
> : > > file translation.
>
> Can that be fixed without too much trouble? I don't need any translation,
> don't I? I want my files to stay exactly the same, regardless of the OS.
Check linux/fs/fat/misc.c (top 20 lines). Apparently it is done on file
names so it should be quick. All I know is about six months ago I had a
report saying that disk access was slow. A "dd" showed 30+MB/min hinting
that the problem was fs related. I had a work around which fixed the speed
issue while retaining the translation ability. (suspect this has made it
to the 2.1.x kernels).
> : >Before you ask, on my computer, the EPP mode produces corrupted
> : >ZipDisks but the ECP mode works fine. On a friend's computer, EPP
> : >mode works fine. Both machines are P166's.
*make notes about EPP problems*
Draft notes on speed improvements available at
http://www.torque.net/~campbell/speed.html
> : Maybe the increased scheduling in the latest ppa driver can slowdown a bit
> : the performance but I think that is better goes a bit slower than have the
> : machine high loaded in loop polling cycles.
>
> That's a good offer. CPU consumption reported by 'time' is about 4% now.
Sometimes I think "time" needs to be taken out and shot. For some unknown
reason the kernel with EPP mode does not notice the time used by ppa. But
I have done a lot of work to ensure that ppa is NOT a CPU hog.
*bing* (lightbulb appears)
I think what your talking about here is the "yield" code which allows
other processes to run after 1 full timer tick has elapsed in the ppa
driver. This COULD be tuned for your own personal preference with a
performance improvement of approx 10-20%.
That was around ppa-1.34.
> : This is using the parport version that should be slower that the
> : monolithic one.
>
> I'm just using the monolithic one :-)
The parport version is only about 5% slower since I implemented a port
caching method.
> : arca:/usr/doc/mesag# /usr/bin/time dd if=/dev/sda of=/dev/null bs=1024
> : count=40960
> : 40960+0 records in
> : 40960+0 records out
> : 0.01user 0.02system 1:30.78elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
> : 0inputs+0outputs (88major+12minor)pagefaults 0swaps
> :
> : If you really see a big performance flaw in latest ppa driver it can be
> : useful to know wich ppa version begin to show that flow.
> Somewhere where the SW/HW direction code came in. 'll take a look at it
> this weekend.
Ehh??? EPP SW/HW direction code was the FIRST change from the old
Athena code. That was around 1.09 from memory. Surely you don't want to go
back THAT far!!!
(I don't know if my archive is that good...)
David Campbell
=======================================================
campbell@torque.net (Parallel port device related mail)
dcampbel@p01.as17.honeywell.com.au (For all other mail)
"All parallel ports are equal - Some are more equal than others"
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:17:25 EST