system response issue

[jd1008]

On 07/14/2015 06:13 AM, David Timms wrote:
> 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...
I wish I knew ...
I find that the desktop kernel and scheduler are tuned more
to server operations where FS buffers for all the threads are
given priority as the desktop is either non-existent or not in operatio.
memory is used mostly for these buffers (aka pagecache).