On Mon, 5 Aug 2019 at 19:49, Warren Young <warren@xxxxxxxxxxx> wrote:
> On Aug 5, 2019, at 11:25 AM, Stephen John Smoogen <smooge@xxxxxxxxx>
> wrote:
> >
> > On Mon, 5 Aug 2019 at 13:17, Jerry Geis <jerry.geis@xxxxxxxxx> wrote:
> >
> >> Why is it that "all" I am really doing at the moment is copying things
> to
> >> an external SSD disk USB3 connected and the machine "freezes"... Why is
> >> that?
> >>
> > You may have a motherboard which is routing a lot through a single USB
> > controller. When that happens your graphical workstation will slow down
> > because your keyboard and mouse events and some other polling has to
> > complete before it can do the next thing.
>
> Ridiculous if true. Modern OSes solved the blocking I/O problem decades
> ago.
>
>
The OS can only do as much as the hardware allows. USB is usually given a
higher connection on the hardware because people get grumpy about mouse
jerkiness. Some motherboards will give you multiple USB controllers where
you have one which is highest priority so keyboard/mouse doesn't stop and
the other is on a lower priority bus for disk transfers. Other motherboards
stick them all on the same controller and you end up with everything frozen
while a large USB transfer occurs. It doesn't matter the OS you are running
when this happens the problems are in the hardware IO controllers and
usually can only be 'fixed' by firmware (if you are lucky). [Which is why
you can have 2 people with the 'same' motherboard unable to replicate each
others issues until you burn them all to the same firmware all through out
(and hope the manufacturer didn't change the MB somewhere in the runs.).
My next suggestion was similar to what you have below. See if plugging in a
different USB port mitigates the issue. If the mother board has a 2-3
vertical stacks, they sometimes have the furthest one from the keyboard on
a different bus. Also see what the lsusb and lspci commands say.. they can
sometimes point out a helpful hint.
> Consider: you may have a gigabit Ethernet connection to the Internet, and
> it is probably throttled to a small fraction of that speed by your ISP, yet
> you can be pumping hundreds of giga*bytes* per second to your SSD while
> your browser is blocked waiting for the remote server to respond. Further,
> while one site is being slow to respond, another background Internet task
> can use the idled Internet connection.
>
> This is a symptom of a real problem, and it may be well worth chasing it
> to the ground.
>
> Jerry: Try another I/O channel for the same copy. For example, what
> happens if you rsync the same file set to a remote machine, with the USB
> SSD connected to *that* machine? Or, if you have a Thunderbolt or FireWire
> option, try that instead. It might even be worth dropping a PCIe card into
> the machine for an alternative I/O path just to help diagnose this. If
> nothing else, it might solve the problem.
>
> USB is a terrible standard, emblematic of everything wrong with the PC
> world. We were sold USB-C as the grand unification of Thunderbolt and
> classic USB, but what we actually got are 6+ different and partially
> incompatible flavors of USB-C!
>
>
> https://people.kernel.org/bleung/how-many-kinds-of-usb-c-to-usb-c-cables-are-there
> https://news.ycombinator.com/item?id=20444326
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> https://lists.centos.org/mailman/listinfo/centos
>
--
Stephen J Smoogen.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
