Re: usb2 port gets very slow on 2-gig Flash Drive.
The Thursday 24 July 2008 15:27:01 Martin McCormick, you wrote :
> I needed to reload the flash drive on a Zenstone 2-gig mp3
> player. I have noticed that when the drive is full, operations
> all still work, but take much longer than one might expect which
> probably has something to do with the fat32 file system and size
> of the FAT table.
>
> I started by doing rm -r -f music which is the one and
> only main directory. That took about 2 hours to complete and
> then it was time to reload it from the Linux computer.
>
> The Linux computer is a 500-MHZ Pentium running a 2.6.5
> kernel and the usb2 port is, by definition 13 Mb so it is slow,
> about 10-meg Ethernet slow under normal conditions.
>
> What actually happens is much worse. After doing the rm
> -r -f, I started with an empty drive but the tar program started
> running very slowly. It takes at times, 10 minutes to load one
> tune that would normally play in 2 or 3 minutes.
>
> Just for fun, I let it plod slowly along and it has been
> running now for about 36 hours and is 75% complete but what is
> happening?
>
> If I look at the health of the system, it isn't that bad
> all be it busy.
>
> $ uptime
>
> 07:21:58 up 2 days, 23:37, 2 users, load average: 4.00, 4.13, 4.19
Wow, a load average of 4 ? It should be that CPU hungry I think. It shouldn't
need lots of CPU to make a transfert. Did you try with another key ? Try the
dd command suggested by Elijah. If it's fast, then you'll be sure it's not a
USB problem. Maybe a badly written driver ? I don't know, I never heard of
something like that.
>
> It is July 24 and ps ax -Olstart shows me that tar has
> been running a very long time:
>
> 22986 Tue Jul 22 23:35:01 2008 D pts/13 00:00:40 tar xf
> /home/martin/musicmain.tar
>
> I tried renic-ing tar and the usb mass storage daemon
> which has had no effect, either good or bad.
>
> I do remember once that if there is a time lapse of
> several minutes between the rm -r -f command to wipe the FAT
> table clean and the tar command that initial performance is much
> better so there must be a cleanup routine going on somewhere.
>
> This is also true if you unmount the drive and remount it empty.
> I seem to remember that it only took a couple of hours to reload
> the entire drive when I did things that way.
>
> I did a top command and I am either missing something or nothing
> much is wrong:
>
> Tasks: 42 total, 2 running, 40 sleeping, 0 stopped, 0 zombie
> Cpu(s): 0.3% us, 0.0% sy, 0.0% ni, 0.0% id, 99.7% wa, 0.0% hi, 0.0%
> si Mem: 126424k total, 124572k used, 1852k free, 1604k buffers
> Swap: 377488k total, 0k used, 377488k free, 102308k cached
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 23560 martin 16 0 2160 1084 1880 R 0.3 0.9 0:00.03 top
> 1 root 16 0 1492 528 1336 S 0.0 0.4 0:07.26 init
> 2 root 34 19 0 0 0 S 0.0 0.0 0:12.13 ksoftirqd/0
> 3 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 events/0
> 4 root 5 -10 0 0 0 S 0.0 0.0 0:04.02 kblockd/0
> 10 root 7 -10 0 0 0 S 0.0 0.0 0:00.00 aio/0
> 9 root 15 0 0 0 0 S 0.0 0.0 0:22.06 kswapd0
> 11 root 25 0 0 0 0 S 0.0 0.0 0:00.00 jfsIO
>
> I plan to let this tar command run its natural course to see
> what happens, but is there anything I can do with the existing
> system to optimise the performance?
>
> Thanks.
>
> Martin McCormick WB5AGZ Stillwater, OK
> Systems Engineer
> OSU Information Technology Department Network Operations Group
--
Thomas Preud'homme
Why debian : http://www.debian.org/intro/why_debian
Reply to: