Re: Bad fs performance, IO freezes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2015-10-27 10:43, cheater00 . wrote:
I have remounted without autodefrag and the issue keeps on happening.
OK, that at least narrows things down further. My guess is the spikes are utorrent getting a bunch of blocks at once from one place, and then trying to write all of them at the same time, which could theoretically cause a latency spike on any filesystem, and BTRFS may just be making it worse.

On Tue, Oct 27, 2015 at 3:30 PM, cheater00 . <cheater00@xxxxxxxxx> wrote:
Feel free to suggest a good 1.5m USB3 cable, too. Let's get rid of all
the unknowns.
When it comes to external cables, I've had really good success with Amazon's 'Amazon Basics' branded stuff. It's usually some of the best quality you can find for the price. The 'Cable Matters' and 'Pluggable' brands also tend to be really good quality for the price.
On Tue, Oct 27, 2015 at 3:26 PM, cheater00 . <cheater00@xxxxxxxxx> wrote:
If you can suggest a dual (or better yet quad) USB3 bay that can be
bought on Amazon, I'll buy it now, and once that arrives, we can be
sure it's not the JMicron chipset.
I don't really have any suggestions here. Usually when I hook up an external drive, it's to recover data from a friends computer, so I don't typically use a enclosure, but just use a simple adapter cable. I would suggest looking for one advertising 'UAS' or 'UASP' support, as that's a relatively new standard for USB storage devices, and newer hardware should be more reliable. It's also notoriously hard to determine what chipset a given model of external drive bay has (there are people I know who bought multiples of the same model and each one had a different chipset internally), and to complicate matters, quite often the exact same hardware gets marketed under half a dozen different names. JMicron is popular because their chips are comparatively inexpensive, and while I've not had good results with them, that doesn't mean that they are all bad (especially considering that they are highly configurable based on how they are wired into the device, and not everyone who designs hardware around them properly understands the implications of some of the features).

On Tue, Oct 27, 2015 at 3:22 PM, cheater00 . <cheater00@xxxxxxxxx> wrote:
The (dual) HDD bay and the chipset are, according to lsusb:
Bus 002 Device 005: ID 152d:0551 JMicron Technology Corp. / JMicron
USA Technology Corp.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Not sure how to find out specific model numbers? I could open up the
bay. OK I'll open up the bay.
Good thing I have just the right screwdriver. It's a JMS551, and just
for records sake, here's the manufacture info:

JMS551
1120 LGAA2 A
572QV0024

The laptop manual says it's either "Intel HM65 Express chipset with
NEC USB 3.0 (select models only)" or "Intel HM65 Express chipset".
Here are technical documents for my model:
Manual: http://docdro.id/hG627JM
"Intel chipset datasheet": http://docdro.id/yKRupYO
Service guide: http://docdro.id/AuDgUdE
Service guide, alt. ver.: http://docdro.id/WwQRpsH
From what I can tell, you've got the one with the NEC USB 3.0 chip, I'm pretty cure that the HM65 doesn't have USB 3.0 itself. FWIW, I've never personally had issues with NEC's USB 3.0 chips, but I've not had much experience using systems with them either.

FWIW I'm using one of the USB3 ports on the left. The ones on the
right are USB2.

I've never used docdro.id so if it's not good let me know where to
upload the PDFs to.

autodefrag is on, yes. But I have been having issues before turning it
on - I turned it on as a measure towards fixing the issues. I will
turn it off and remount, then report. But I don't think that should be
it. As you see the transfer speeds are minimal. They're *all* that's
happening on the disk. Right now that's under 100 KB/sec and I'm still
getting freezes albeit less. Also why would I be getting freezes when
the transfer speeds jump up - just for them to drop again? Hmm, maybe
utorrent has some sort of scheduler that gets preempted while the
spike is happening, and some algorithm in it gets the wrong idea and
turns some sort of flow control on, because it thinks it's hit some
sort of physical transfer speed barrier. Also notice the upload and
download both scale together, but that just might be how torrent
works, maybe it just tries to be fair i.e. only uploads as much as it
downloaded (scaled by a constant).
Yeah, utorrent defaults to trying for a 1:1 ratio of uploads to downloads (so in terms of viewing the group of clients downloading a torrent as a network, it defaults to contributing as much bandwidth as it uses). This is pretty typical behavior for most torrent clients, and in fact downloading more than you upload for a torrent is generally considered bad etiquette.

The system is 32 bit because I installed ubuntu 6 one day and just
kept on upgrading. I keep on telling myself I'll update to 64 bits,
one of these days. But this laptop only has 8 gigs of ram, so no real
reason to upgrade to 64 bit anyways. It's not like I need firefox to
be able to eat 8 gb of ram whereas right now it can only eat 4. There
is no simple upgrade path that I know of so it's either a fresh
install or doing something like this: http://www.ewan.cc/?q=node/132
-- I keep telling myself /one of these days/...
That's entirely understandable. It's never been easy to do an in-place upgrade from 32 to 64 bit. It's worth noting that while it's not easy to do a full upgrade to 64-bit, it is relatively easy to run a 32-bit userspace on a 64-bit kernel (at least, it should be, it's been so long since I used Ubuntu for anything that I really don't have much frame of reference regarding it beyond the fact that it's based on Debian).

On Tue, Oct 27, 2015 at 2:30 PM, Austin S Hemmelgarn
<ahferroin7@xxxxxxxxx> wrote:
On 2015-10-27 09:00, Henk Slager wrote:

I don't have a lot experience with autodefrag, but as indicated by
Austin, expect a lot of full rewrites of files that are relatively
slowly filled up by a torrent client, starting with a sparse file. So
1st advice would be to remove this option and run it as crontask at
particular times.

What SATA-USB bridge is between the harddisk and the PC motherboard ?

I hadn't thought of this, but the specific adapter being used for the disk
can have a lot of impact on how it preforms.  I've personally had lots of
issues with JMicron chipsets (ranging from latency issues like what you are
seeing to sever data corruption), but have found that ASMedia ones tend to
be pretty much rock solid reliable and have good performance (although I
think they only do USB 3.0 adapters).

Also what USB host chipset is on the PC motherboard ?

If it's a Intel motherboard, the USB 2.0 ports are probably routed through
on-board hubs to the ports provided by whatever Intel calls their equivalent
of the south bridge these days, and the USB 3.0 ports are probably a mix of
Intel and ASMedia XHCI controllers (ASMedia was one of the first companies
to do an inexpensive standalone XHCI chip, so they're relatively popular for
extra USB 3.0 ports).  FWIW, the first generation of Intel XHCI chips had
some issues with older Linux kernels, although IIRC those issues were along
the lines of a port just disappearing after disconnecting whatever was
connected to it.

Why don't you run 64-bit Ubuntu on this core i7 ?

64 versus 32 bit shouldn't cause anything like this to happen (although, if
it can be proven that it does, then that is a serious bug that needs to be
fixed).  That said, unless you have some desperate need to be running 32-bit
only, you should seriously look into updating to a 64-bit version, your
whole system should run faster, and Ubuntu has really good 32-bit
compatibility in the 64-bit version (which is part of why it's popular as a
support target for third party software like Steam).



On Tue, Oct 27, 2015 at 12:44 PM, Austin S Hemmelgarn
<ahferroin7@xxxxxxxxx> wrote:

On 2015-10-26 22:00, cheater00 . wrote:


Hello,
currently my computer freezes every several seconds for half a second
or so. Using it feels like I'm playing musical chairs with the kernel.
I have just one download happening on utorrent right now - this is
what the graph looks like:
http://i.imgur.com/LqhMtrJ.png
and every time a new spike happens, a freeze happens just before
that... that's the only time those freezes happen, too.

Do you have the 'autodefrag' mount option enabled?  If it is turned on,
then
that may be the problem.  Most bittorrent clients pre-allocate the space
for
a download, then write each block directly into the location it's
supposed
to be in the resultant download, which means depending on how it's
pre-allocating the space, that you end up with a large number of randomly
ordered writes into a single file, which in turn will trigger the
autodefrag
code, which can cause latency spikes when you're also hitting the disk at
the same time.


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux