Re: External USB2 HDD affects speed hda

[David Brownell]

On Wednesday 01 June 2005 11:25 am, Rene Herman wrote:
> Pavel Machek wrote:
> > On Út 31-05-05 01:21:37, Rene Herman wrote:
> 
> [ internal IDE HDD slowdown after switching on external USB2 HDD ]
> 
> > USB controller generating extra DMA load? Try rmmoding usb to see if
> > it goes away.
> 
> I was sceptical about this since the drive is idle (or even switched off 
> again) but I recompiled EHCI modular and rmmodding ehci_hcd does in fact 
> bring back my 50 MB/s:
> 
> 				: hdparm -t /dev/hda = 50 MB/s
> 1. modprobe ehci_hcd		: hdparm -t /dev/hda = 50 MB/s
> 2. switch on USB2 drive	: hdparm -t /dev/hda = 42 MB/s
> 3. switch off USB drive	: hdparm -t /dev/hda = 42 MB/s
> 4. modprobe -r ehci_hcd	: hdparm -t /dev/hda = 50 MB/s

So it's as if the controller remembers that the drive was once turned
on, and then chews up 8+ MB/sec of bus bandwidth somehow until its driver
is removed -- right?  Unplugging the drive (vs just poweroff), same?

One more experiment to try:  with CONFIG_USB_DEBUG, have a look at
the relevant /sys/class/usb_host/usbN/registers file.  Here's what
one looks like on one system:

	bus pci, device 0000:00:02.2 (driver 10 Dec 2004)
	nVidia Corporation nForce2 USB Controller
	EHCI 1.00, hcd state 1
	ownership 01000001 linux
	SMI sts/enable 0xe0080000
	structural params 0x00102486
	capability params 0x0000a086
	status 0008 FLR
	command 010009 (park)=0 ithresh=1 period=256 RUN
	intrenable 37 IAA FATAL PCD ERR INT
	uframe 0e1e
	port 1 status 001000 POWER sig=se0
	port 2 status 001005 POWER sig=se0 PE CONNECT
	port 3 status 001000 POWER sig=se0
	port 4 status 001000 POWER sig=se0
	port 5 status 003802 POWER OWNER sig=j CSC
	port 6 status 001000 POWER sig=se0
	irq normal 28 err 1 reclaim 18 (lost 0)
	complete 29 unlink 0

So there's a USB2 disk on port 2, a full speed device on port 5,
and the controller isn't doing anything much at all ... the RUN
command bit is set, which means it's sending out SOF tokens on
all enabled port(s).  (And it's not suspended, so there's probably
a clock at 48 MHz or so.)  But no transactions are active -- the
"periodic" and "async" schedules are empty, ditto the Periodic
and Async command bits are clear -- so it should be staying away
from PCI, no DMA load at all.

The experiment:  verify that only the RUN bit is set on your
machine too.  If "Periodic" and/or "Async" bits are set, then
the controller is _supposed_ to be issuing DMA transfers over
PCI, so less bandwidth will be available.  Otherwise, not.


> There would not seem to be any extra DMA load with a drive that's idle 
> or switched off again though? Is the (VIA) USB2 controller playing bus 
> monopolizing tricks or something sinister like that? (the speed doesn't 
> drop immediately after loading ehci_hcd though, only after switching on 
> the USB2 HDD)

VIA's EHCI has been more consistently wierd than any other vendor's
implementation.  The VT6202 (initial implementation) has never seemed
to work right.  And although the newer implementations appear to work
OK with the current driver, that's largely due to workarounds that
address some fairly important IRQ dropouts.  I've always suspected
they have strange things going on with their DMA, too; performance
patterns were just too wierd to explain otherwise.


> More detail --- it's a VIA VT6212L EHCI controller, on unshared IRQ3. 
> IDE0 is AMD756 on unshared IRQ14/15. The USB2 HDD does 30 MB/s (after a 
> hdparm -a 1024; with the default 256 it's 25MB/s) which I did think was 
> a very good speed.

The VT6212 never showed me any problems the last time I tested with it,
other than the IRQ lossage I've seen with all VIA EHCI silicon.  And
yes, 30 MB/sec is pretty good; not all disks, or hosts, will do that.

A more hardware-oriented experiment would be to see if a non-VIA card
does the same thing ... most NEC cards won't get you that same data
transfer rate (newer ones might), maybe ALI will.

The most hardware-oriented experiment is to stick a logic analyser on
your PCI bus and see what's up.  Maybe it's not doing DMA, but it's
still arbitrating for the bus or something.  And maybe the AMD PCI is
fighting with the VIA PCI somehow; I seem to recall problems of that
ilk from chips of that era.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/