system response issue

David Timms dtimms at iinet.net.au
Tue Jul 14 12:13:56 UTC 2015


On 14/07/15 07:42, jd1008 wrote:
> 
> 
> On 07/13/2015 03:13 PM, Patrick O'Callaghan wrote:
>> On Mon, 2015-07-13 at 13:50 -0600, jd1008 wrote:
>>> I started a tar command from
>>> one external eSATA drive (ext4), connected to eSATA port,
>>> out to a USB flash drive (with vfat). The USB stick is touted
>>> to support 50MB/s write, 160MB/s read.
>> Have you actually measured its real write speed for large files? Try
>> something like:
>>
>> time dd if=/dev/zero of=/the/usb/drive count=1000 bs=1M
>>
>> You might be surprised.
>>
>> poc
> As  I just replied with the actual read/write performance data
> on this USB 3.0 SUperTalentExpress Drive (256GB), I am
> much more surprised by the fact that while tarring a large
> dir to it from a fast eSATA drive, the system becomes nearly
> unusable!!!
> So, if this "shtick" is so slow, why is writing to it killing the response
> time for everything else?

I see the same sort of issue (F21, cinnamon desktop). If the disk write
or read is getting "backed up" with a queue of info, then that should
mean the desktop UI is more responsive, since the CPU is idle. But it
doesn't seem to work that way. It quite often seems to be waiting on a
large disk IO to complete.

On mine, possibly having once connected to a windows7 machine and copied
a mpg file from it to mine, but leaving the nemo window open might be a
trigger. And an hour after boot, the prelink operation runs (again,
should be set for tinniest priority, and rest of OS should be normal
especially given / is on an SSD (with modified time writing disabled).

Love to hear some things to try...


More information about the users mailing list