am i the only one who has the problem that while i copy large files (vmware-images) on an external USB disk that kde most of the time stucks for some seconds?
switch to a terminal with CTRL+ALT+F2 works fine without any delays, switching back to GUI also but it does not get refreshed - only the mouspointer is available
ehis feels like with F14 on this hardware where this freezes happnde dpermanently without any reason
really frustrating on a Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz with 16 GB RAM because on this hardware freezes are unexpected
[root@srv-rhsoft:~]$ smbios-sys-info Libsmbios version: 2.2.28 Product Name: HP Compaq 8200 Elite CMT PC Vendor: Hewlett-Packard BIOS Version: J01 v02.14
[root@srv-rhsoft:~]$ lspci 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04) 00:1a.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4) 00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b4) 00:1c.6 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 7 (rev b4) 00:1c.7 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 8 (rev b4) 00:1d.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a4) 00:1f.0 ISA bridge: Intel Corporation Q67 Express Chipset Family LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 04) 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04) 01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 02:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) 03:00.0 Mass storage controller: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01)
2011/11/19 Reindl Harald h.reindl@thelounge.net:
am i the only one who has the problem that while i copy large files (vmware-images) on an external USB disk that kde most of the time stucks for some seconds?
switch to a terminal with CTRL+ALT+F2 works fine without any delays, switching back to GUI also but it does not get refreshed - only the mouspointer is available
Seen it before. Can't put the finger as for the possible reason. Copy from command line w/o KDE, and the machine is responsive. Copy from dolphin, and KDE is slow as molasses.
- Gilboa
Am 19.11.2011 16:23, schrieb Gilboa Davara:
2011/11/19 Reindl Harald h.reindl@thelounge.net:
am i the only one who has the problem that while i copy large files (vmware-images) on an external USB disk that kde most of the time stucks for some seconds?
switch to a terminal with CTRL+ALT+F2 works fine without any delays, switching back to GUI also but it does not get refreshed - only the mouspointer is available
Seen it before. Can't put the finger as for the possible reason. Copy from command line w/o KDE, and the machine is responsive. Copy from dolphin, and KDE is slow as molasses.
no, i am speaking from have a rsync running on TTY3 far away from KDE and KDE freezes the whole time, becomes shortly responsive until it freezes again what happens so often that it is unuseable until the USB-I/O is finished
+1 ! Mine is sometimes completely frozen and nothing can come it back :/ But mostly, openning System Activity with Ctrl + Esc is fixin it, as a workaround.
________________________________ From: Reindl Harald h.reindl@thelounge.net To: kde@lists.fedoraproject.org Sent: Saturday, November 19, 2011 5:29 PM Subject: Re: kde-freezes while large USB copy
Am 19.11.2011 16:23, schrieb Gilboa Davara:
2011/11/19 Reindl Harald h.reindl@thelounge.net:
am i the only one who has the problem that while i copy large files (vmware-images) on an external USB disk that kde most of the time stucks for some seconds?
switch to a terminal with CTRL+ALT+F2 works fine without any delays, switching back to GUI also but it does not get refreshed - only the mouspointer is available
Seen it before. Can't put the finger as for the possible reason. Copy from command line w/o KDE, and the machine is responsive. Copy from dolphin, and KDE is slow as molasses.
no, i am speaking from have a rsync running on TTY3 far away from KDE and KDE freezes the whole time, becomes shortly responsive until it freezes again what happens so often that it is unuseable until the USB-I/O is finished
_______________________________________________ kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
On Saturday 19 November 2011 08:00:43 Tayfun Kayhan wrote:
+1 ! Mine is sometimes completely frozen and nothing can come it back :/ But mostly, openning System Activity with Ctrl + Esc is fixin it, as a workaround.
From: Reindl Harald h.reindl@thelounge.net To: kde@lists.fedoraproject.org Sent: Saturday, November 19, 2011 5:29 PM Subject: Re: kde-freezes while large USB copy
Am 19.11.2011 16:23, schrieb Gilboa Davara:
2011/11/19 Reindl Harald h.reindl@thelounge.net:
am i the only one who has the problem that while i copy large files (vmware-images) on an external USB disk that kde most of the time stucks for some seconds?
switch to a terminal with CTRL+ALT+F2 works fine without any delays, switching back to GUI also but it does not get refreshed - only the mouspointer is available
Seen it before. Can't put the finger as for the possible reason. Copy from command line w/o KDE, and the machine is responsive. Copy from dolphin, and KDE is slow as molasses.
no, i am speaking from have a rsync running on TTY3 far away from KDE and KDE freezes the whole time, becomes shortly responsive until it freezes again what happens so often that it is unuseable until the USB-I/O is finished
Hi,
On the test list there was a threat with a comparable issue, see [1]. May be it's the same as what you see.
Martin Kho
[1] http://lists.fedoraproject.org/pipermail/test/2011-November/104368.html
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
To be more helpful, for my system, what i see is that any process might lead to making system unresponsive or pretty slow, sometimes it is watching a movie or downloading sth or reading a file, that causes it.
________________________________ From: Martin Kho lists.kho@gmail.com To: KDE on Fedora discussion kde@lists.fedoraproject.org Sent: Saturday, November 19, 2011 6:09 PM Subject: Re: kde-freezes while large USB copy
On Saturday 19 November 2011 08:00:43 Tayfun Kayhan wrote:
+1 ! Mine is sometimes completely frozen and nothing can come it back :/ But mostly, openning System Activity with Ctrl + Esc is fixin it, as a workaround.
From: Reindl Harald h.reindl@thelounge.net To: kde@lists.fedoraproject.org Sent: Saturday, November 19, 2011 5:29 PM Subject: Re: kde-freezes while large USB copy
Am 19.11.2011 16:23, schrieb Gilboa Davara:
2011/11/19 Reindl Harald h.reindl@thelounge.net:
am i the only one who has the problem that while i copy large files (vmware-images) on an external USB disk that kde most of the time stucks for some seconds?
switch to a terminal with CTRL+ALT+F2 works fine without any delays, switching back to GUI also but it does not get refreshed - only the mouspointer is available
Seen it before. Can't put the finger as for the possible reason. Copy from command line w/o KDE, and the machine is responsive. Copy from dolphin, and KDE is slow as molasses.
no, i am speaking from have a rsync running on TTY3 far away from KDE and KDE freezes the whole time, becomes shortly responsive until it freezes again what happens so often that it is unuseable until the USB-I/O is finished
Hi,
On the test list there was a threat with a comparable issue, see [1]. May be it's the same as what you see.
Martin Kho
[1] http://lists.fedoraproject.org/pipermail/test/2011-November/104368.html
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
_______________________________________________ kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
Am 19.11.2011 17:09, schrieb Martin Kho:
On Saturday 19 November 2011 08:00:43 Tayfun Kayhan wrote:
+1 ! Mine is sometimes completely frozen and nothing can come it back :/ But mostly, openning System Activity with Ctrl + Esc is fixin it, as a workaround.
On the test list there was a threat with a comparable issue, see [1]. May be it's the same as what you see.
[1] http://lists.fedoraproject.org/pipermail/test/2011-November/104368.html
i can not say this in general
only if the I/O goes to USB2 or USB3 while the last seems to have a kernel-bug with my controller and tends to damage filesystmes and lsoe connection but thats off-topic
"inertnal I/O" doe snot make any problem here are runnign 4x2 TB as RAID10 and a bundle of guests in VMware-Workstation and even on the highest disk-usage i see kde not freezing, but if i start large USB-backups i can turn off the monitor and go to bed :-(
On 11/19/2011 11:16 AM, Reindl Harald wrote:
Am 19.11.2011 17:09, schrieb Martin Kho:
On Saturday 19 November 2011 08:00:43 Tayfun Kayhan wrote:
+1 ! Mine is sometimes completely frozen and nothing can come it back :/ But mostly, openning System Activity with Ctrl + Esc is fixin it, as a workaround.
On the test list there was a threat with a comparable issue, see [1]. May be it's the same as what you see.
[1] http://lists.fedoraproject.org/pipermail/test/2011-November/104368.html
i can not say this in general
only if the I/O goes to USB2 or USB3 while the last seems to have a kernel-bug with my controller and tends to damage filesystmes and lsoe connection but thats off-topic
I've seen something like this, too, but am not sure if it is KDE-related or controller related. But trying to copy lots of data to a USB2 stick here is very, very slow. It works at first just fine, but then slows down as things proceed. Copying, say, 4GB can take 2-3 hours. I guess I should at least try it under another WM.
Richard
Am 20.11.2011 03:38, schrieb Richard Heck:
On 11/19/2011 11:16 AM, Reindl Harald wrote:
Am 19.11.2011 17:09, schrieb Martin Kho:
On Saturday 19 November 2011 08:00:43 Tayfun Kayhan wrote:
+1 ! Mine is sometimes completely frozen and nothing can come it back :/ But mostly, openning System Activity with Ctrl + Esc is fixin it, as a workaround.
On the test list there was a threat with a comparable issue, see [1]. May be it's the same as what you see.
[1] http://lists.fedoraproject.org/pipermail/test/2011-November/104368.html
i can not say this in general
only if the I/O goes to USB2 or USB3 while the last seems to have a kernel-bug with my controller and tends to damage filesystmes and lsoe connection but thats off-topic
I've seen something like this, too, but am not sure if it is KDE-related or controller related. But trying to copy lots of data to a USB2 stick here is very, very slow. It works at first just fine, but then slows down as things proceed. Copying, say, 4GB can take 2-3 hours. I guess I should at least try it under another WM.
i am also not sure if other WM would show a different behavior
that it slows down until buffers are full is clear but what is not acceptable is that the whole computer in a class few years ago clusters did not have is unuseable while data transfer to an usb-drive while this never happens to eSATA, but not uch drives have eSATA :-(
I can explain this, as I see it too. Well, I can partially explain.
It's caused by the kernel allocating large write buffers that can represent many minutes (or hours) of write time for a slow USB device. You copy that file from a higher performing storage device, and you end up with many GB buffered writes. KDE (or something in the UI render path) decides to stop while doing an fsync ( I'm not sure exactly what), and you need to wait for that to complete. Worst case for me was filling a class 4 micro SD with 32GB of music. My machine has 16GB of RAM, and a quite fast HDD, so it soon had a few GB queued, which drains at about 1MB/sec (due to some issues on the other end of the USB, with a similar root cause).
2 work arounds I found:
1. If it's a FAT filesystem (as your USB stick may be), mount it with the sync option, which can be done with something like this (after KDE has mounted): udisks --mount /dev/disk/by-uuid/XXXXX --mount-options sync
It's slow, but at least you can work while it copies
2. Limit the kernel write buffers to some appropriate value, using /proc/sys/vm/dirty_background_bytes and/or dirty_bytes. This is a bit messy, and has some side-effects on other drive performance, so you trade latency for throughput. . There is also dirty_background_ratio and dirty_ratio - you use bytes or ratio, setting one clears the other, but they basically set thresholds as to when the kernel will start flushing, and when user process blocks while write flushes (I think).
Apparently it defaults (as a ratio) to about 20% of RAM, which can be a lot these days, and it also has some minimum value, which is still very large for a 16GB machine (or even a 4GB machine). For me, something on the order of 8MB was OK for that slow flash, but that killed the HDD raid I have. I currently run dirty_bytes at 128MB and dirty_background_bytes at 32MB. It still kills me occasionally, but has minimal impact on the HDD performance. 128MB is about 2x the disks internal buffer in my case.
It's probably a default Fedora may want to tweak based on machine config, and I understand there has been some healthy discussion in kernel lists about it. To me it seems the kernel needs to become acutely aware of what the real throughput of a device is, not what the device claims, and allow the user to set minimum write latency. Almost like tcp's windowing system (with slow start). Filesystems matter too apparently, and ext4 is renowned for latency issues (btrfs more so)
Cheers
Darren
2011/11/20 Reindl Harald h.reindl@thelounge.net
Am 20.11.2011 03:38, schrieb Richard Heck:
On 11/19/2011 11:16 AM, Reindl Harald wrote:
Am 19.11.2011 17:09, schrieb Martin Kho:
On Saturday 19 November 2011 08:00:43 Tayfun Kayhan wrote:
+1 ! Mine is sometimes completely frozen and nothing can come it back
:/ But
mostly, openning System Activity with Ctrl + Esc is fixin it, as a workaround.
On the test list there was a threat with a comparable issue, see [1].
May be
it's the same as what you see.
[1]
http://lists.fedoraproject.org/pipermail/test/2011-November/104368.html
i can not say this in general
only if the I/O goes to USB2 or USB3 while the last seems to have a kernel-bug with my controller and tends to damage filesystmes and lsoe connection but thats off-topic
I've seen something like this, too, but am not sure if it is KDE-related or controller related. But trying to copy lots of data to a USB2 stick here is very, very slow. It works at first just fine, but then slows down as things proceed. Copying, say, 4GB can take 2-3 hours. I guess I should at least try it under another WM.
i am also not sure if other WM would show a different behavior
that it slows down until buffers are full is clear but what is not acceptable is that the whole computer in a class few years ago clusters did not have is unuseable while data transfer to an usb-drive while this never happens to eSATA, but not uch drives have eSATA :-(
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
Am 20.11.2011 06:20, schrieb Darren Steven:
I can explain this, as I see it too. Well, I can partially explain.
It's caused by the kernel allocating large write buffers that can represent many minutes (or hours) of write time for a slow USB device. You copy that file from a higher performing storage device, and you end up with many GB buffered writes. KDE (or something in the UI render path) decides to stop while doing an fsync ( I'm not sure exactly what), and you need to wait for that to complete. Worst case for me was filling a class 4 micro SD with 32GB of music. My machine has 16GB of RAM, and a quite fast HDD, so it soon had a few GB queued, which drains at about 1MB/sec (due to some issues on the other end of the USB, with a similar root cause).
if you are right this is simply a dumb behavior since on a machone with a quad-core CPU with HT and 16 GB memory there has NOTHING to wait and destroy optimizings for VMware/RAID10 using every day to get les freezes in the UI is not a solution
on a TTY there is no hang, no impact and so there goes something TERRIBLE wrong what should be fixed somehow
On Sunday 20 November 2011 16:20:14 Darren Steven wrote:
It's caused by the kernel allocating large write buffers that can represent many minutes (or hours) of write time for a slow USB device. You copy that file from a higher performing storage device, and you end up with many GB buffered writes. KDE (or something in the UI render path) decides to stop while doing an fsync ( I'm not sure exactly what), and you need to wait for that to complete.
[snip]
It's probably a default Fedora may want to tweak based on machine config, and I understand there has been some healthy discussion in kernel lists about it. To me it seems the kernel needs to become acutely aware of what the real throughput of a device is, not what the device claims, and allow the user to set minimum write latency. Almost like tcp's windowing system (with slow start). Filesystems matter too apparently, and ext4 is renowned for latency issues (btrfs more so)
Thanks for the explanation, it's very interesting. Can you post a link to the thread (I guess on LKML) with that discussion?
Best, :-) Marko
On 11/19/2011 03:17 PM, Reindl Harald wrote:
am i the only one who has the problem that while i copy large files (vmware-images) on an external USB disk that kde most of the time stucks for some seconds?
switch to a terminal with CTRL+ALT+F2 works fine without any delays, switching back to GUI also but it does not get refreshed - only the mouspointer is available
ehis feels like with F14 on this hardware where this freezes happnde dpermanently without any reason
really frustrating on a Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz with 16 GB RAM because on this hardware freezes are unexpected
[root@srv-rhsoft:~]$ smbios-sys-info Libsmbios version: 2.2.28 Product Name: HP Compaq 8200 Elite CMT PC Vendor: Hewlett-Packard BIOS Version: J01 v02.14
[root@srv-rhsoft:~]$ lspci 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04) 00:1a.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4) 00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b4) 00:1c.6 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 7 (rev b4) 00:1c.7 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 8 (rev b4) 00:1d.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a4) 00:1f.0 ISA bridge: Intel Corporation Q67 Express Chipset Family LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 04) 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04) 01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 02:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) 03:00.0 Mass storage controller: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01)
Could it be the problem described in the link below?
Huge pages, slow drives, and long delays
https://lwn.net/Articles/467328/
I saw this last week but I have been slowly cleaning my my mail backlog.
Am 24.11.2011 23:55, schrieb José Matos:
On 11/19/2011 03:17 PM, Reindl Harald wrote:
am i the only one who has the problem that while i copy large files (vmware-images) on an external USB disk that kde most of the time stucks for some seconds?
switch to a terminal with CTRL+ALT+F2 works fine without any delays, switching back to GUI also but it does not get refreshed - only the mouspointer is available
really frustrating on a Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz with 16 GB RAM because on this hardware freezes are unexpected
[root@srv-rhsoft:~]$ smbios-sys-info Libsmbios version: 2.2.28 Product Name: HP Compaq 8200 Elite CMT PC Vendor: Hewlett-Packard BIOS Version: J01 v02.14
Could it be the problem described in the link below?
Huge pages, slow drives, and long delays
https://lwn.net/Articles/467328/
I saw this last week but I have been slowly cleaning my my mail backlog.
yes, sounds exactly like what i am seeing not that i use usb-drives often, but if i do it is frustrating
btw: for me it seems that mount the usb-drive with "commit=1" make the behavior much smoother, on the other hand i would not expect such freezes on modern top-hardware thinking back where hughe clusters did not have such performance than now
-
Darren Steven -
Gilboa Davara -
José Abílio Matos -
Marko Vojinovic -
Martin Kho -
Reindl Harald -
Richard Heck -
Tayfun Kayhan