Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I'm using Ubuntu Hardy Heron, and since a system update back in June or July, I've had horribly slow USB write speeds. I can read from external HDDs and Flash drives at normal USB2.0 speeds, but write speeds are painfully slow, as in less than 5MB/s.
I've been reading up on this since I first noticed the problem. Not everybody seems to have this problem, and for every person that does have the problem, everybody has their own fix ideas that might work for them but don't seem to work for anyone else.
The problem doesn't seem to be distro-specific, nor does it seem to be tied to any one kernel or driver version. Some forum posts go back as far as the introduction of USB2.0. I've seen this exact problem - normal read speeds/slow write speeds - reported here in LQ, as well as on forums for Ubuntu, Mint, Arch, Suse, Fedora, and Debian (and probably some others I may have missed).
Launchpad has a bug report that claims GVFS is the culprit, and lists adding "pci=routeirq" to the kernel boot options in /boot/grub/menu.lst, but this solution does nothing for me except make my GUI sluggish and barely responsive while file transfers are happening. Another post I read somewhere suggests adding "irqpoll" to the boot options, but this has no effect for me.
I can definitively say that GVFS is not the problem. I've done multiple un-/re-installs of Ubuntu Hardy, Kubuntu Hardy, Xubuntu Hardy, and even Ubuntu Intrepid Ibex - all of them start out with blazing fast (approaching 30MB/s write speeds) for USB device writes, but eventually end up writing at 8MB/s, and the speed always tapers off as the file is written. A typical 700MB .avi file transfer to an external HDD will take me up to six solid minutes, when copying a file from the same HDD will take 30 or so seconds.
During my various Ubuntu installs, from inside Synaptic, I've locked the versions for GVFS, Nautilus, and the Kernel before ever connecting to the internet. The problem always arises.
Hopefully, this can end up being one thread where those of us who are experiencing this problem can get together and find a common cause. That being said, here's a ton of info that should get us started.
I'm running a Toshiba Satelliet a135 Laptop.
Output of lspci-v:
Code:
zero@zero-laptop:~$ lspci -v
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
Subsystem: Toshiba America Info Systems Unknown device ff00
Flags: bus master, fast devsel, latency 0
Capabilities: <access denied>
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
Subsystem: Toshiba America Info Systems Unknown device ff02
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at dc100000 (32-bit, non-prefetchable) [size=512K]
I/O ports at 1800 [size=8]
Memory at c0000000 (32-bit, prefetchable) [size=256M]
Memory at dc200000 (32-bit, non-prefetchable) [size=256K]
Capabilities: <access denied>
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
Subsystem: Toshiba America Info Systems Unknown device ff02
Flags: bus master, fast devsel, latency 0
Memory at dc180000 (32-bit, non-prefetchable) [size=512K]
Capabilities: <access denied>
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
Subsystem: Toshiba America Info Systems Unknown device ff01
Flags: bus master, fast devsel, latency 0, IRQ 21
Memory at dc440000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 00002000-00002fff
Memory behind bridge: d6000000-d7ffffff
Prefetchable memory behind bridge: 00000000d0000000-00000000d1ffffff
Capabilities: <access denied>
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
I/O behind bridge: 00003000-00003fff
Memory behind bridge: d8000000-d9ffffff
Prefetchable memory behind bridge: 00000000d2000000-00000000d3ffffff
Capabilities: <access denied>
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=05, subordinate=05, sec-latency=0
I/O behind bridge: 00004000-00004fff
Memory behind bridge: da000000-dbffffff
Prefetchable memory behind bridge: 00000000d4000000-00000000d5ffffff
Capabilities: <access denied>
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI])
Subsystem: Toshiba America Info Systems Unknown device ff00
Flags: bus master, medium devsel, latency 0, IRQ 19
I/O ports at 1820 [size=32]
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI])
Subsystem: Toshiba America Info Systems Unknown device ff00
Flags: bus master, medium devsel, latency 0, IRQ 20
I/O ports at 1840 [size=32]
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI])
Subsystem: Toshiba America Info Systems Unknown device ff00
Flags: bus master, medium devsel, latency 0, IRQ 18
I/O ports at 1860 [size=32]
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02) (prog-if 00 [UHCI])
Subsystem: Toshiba America Info Systems Unknown device ff00
Flags: bus master, medium devsel, latency 0, IRQ 17
I/O ports at 1880 [size=32]
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI])
Subsystem: Toshiba America Info Systems Unknown device ff00
Flags: bus master, medium devsel, latency 0, IRQ 19
Memory at dc444000 (32-bit, non-prefetchable) [size=1K]
Capabilities: <access denied>
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) (prog-if 01 [Subtractive decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=06, subordinate=0a, sec-latency=56
Memory behind bridge: dc000000-dc0fffff
Capabilities: <access denied>
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
Subsystem: Toshiba America Info Systems Unknown device ff00
Flags: bus master, medium devsel, latency 0
Capabilities: <access denied>
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02) (prog-if 80 [Master])
Subsystem: Toshiba America Info Systems Unknown device ff00
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 20
I/O ports at 01f0 [size=8]
I/O ports at 03f4 [size=1]
I/O ports at 0170 [size=8]
I/O ports at 0374 [size=1]
I/O ports at 18b0 [size=16]
Capabilities: <access denied>
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
Subsystem: Toshiba America Info Systems Unknown device ff00
Flags: medium devsel, IRQ 11
I/O ports at 18c0 [size=32]
04:00.0 Ethernet controller: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)
Subsystem: Askey Computer Corp. Unknown device 7106
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at d8000000 (64-bit, non-prefetchable) [size=64K]
Capabilities: <access denied>
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E PCI Express Fast Ethernet controller (rev 01)
Subsystem: Toshiba America Info Systems Unknown device ff00
Flags: bus master, fast devsel, latency 0, IRQ 220
I/O ports at 4000 [size=256]
Memory at da000000 (64-bit, non-prefetchable) [size=4K]
[virtual] Expansion ROM at d4000000 [disabled] [size=64K]
Capabilities: <access denied>
06:04.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
Subsystem: Toshiba America Info Systems Unknown device ff00
Flags: bus master, medium devsel, latency 168, IRQ 17
Memory at dc006000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=06, secondary=07, subordinate=0a, sec-latency=176
Memory window 0: 50000000-53fff000 (prefetchable)
Memory window 1: 54000000-57fff000
I/O window 0: 00001400-000014ff
I/O window 1: 00001c00-00001cff
16-bit legacy interface ports at 0001
06:04.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller (prog-if 10 [OHCI])
Subsystem: Toshiba America Info Systems Unknown device ff00
Flags: bus master, medium devsel, latency 32, IRQ 16
Memory at dc005000 (32-bit, non-prefetchable) [size=2K]
Memory at dc000000 (32-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
06:04.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
Subsystem: Toshiba America Info Systems Unknown device ff00
Flags: bus master, medium devsel, latency 57, IRQ 18
Memory at dc004000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
06:04.3 SD Host controller: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller (prog-if 01)
Subsystem: Toshiba America Info Systems Unknown device ff00
Flags: bus master, medium devsel, latency 57, IRQ 20
Memory at dc005800 (32-bit, non-prefetchable) [size=256]
Capabilities: <access denied>
USB is not meant to be use for storage. It is meant to replace communication ports and PS/2 connections. USB can not handle high speed data all the time because it is too software dependent. Using GUI programs will always tries to sync the data to figure the difference of size. If you use IEEE-1394 (aka Firewire or i.Link) or even better SATA, your storage device will be a lot faster. I suggest do not use a program that gauges how long to copy or move files because you get lower performance. When mounting external USB drives, do not use sync as a mount option.
Everybody has this problem. It is just how USB works in any operating system.
The utility hdparm is not a benchmark tool because it only calculates raw performance.
Everybody has this problem. It is just how USB works in any operating system.
For over two years, it wasn't a problem for me until this past summer. That's across four versions of Ubuntu (Edgy, Feisty, Gutsy, and Hardy), Slax, Slackware, Backtrack, Debian, DreamLinux, and Mint. It certainly isn't a problem on any of the Vista or XP installs I have laying around, either. Not only do I have slow speeds (never higher than 8MB/s) when transferring files to an external hard disk, but doing that causes my GUI to become sluggish. If USB wasn't meant for storage purposes, flash drives and external hard disks wouldn't exist.
How do I change the automount options for the half-dozen or so USB storage devices I use regularly? I've yet to see any definitive answer on how to make these changes, and I've been searching on this problem for four months now.. All that shows up in my fstab is my root partition, home partition, and swap space.
I recommend turn off automount so those utilities do not automatically mount them. If you insist of using them, look up hal and dbus. I do not use them because I prefer not adding a line to /etc/fstab to ease mounting external storage devices instead I mount them manually. This takes more time, but I can mount it as read-only if I want to just browse the files with out editing them.
For me it is always a problem with USB. It is not meant to be used with storage devices. Intel pushed this interface to developers throats to make devices while Apple did not get any chance to provide IEEE-1394 for Intel or AMD systems until many years later.
A sluggish GUI means your distribution have set the kernel to preemptive for desktop use which is OK for normal daily use. In some cases preemptive for desktop use will make the kernel to take more time processing programs while sacrificing bandwidth. I prefer voluntary preemptive for server use for higher bandwidth which works quite nicely.
Windows 2000/XP and Windows Vista has a complete different infrastructure for USB compared to Linux. The USB storage module, usbstorage, in Linux is reversed engineer. The USB low performance storage module, uba, is supposedly replace usbstorage but it seems it will not. I strongly recommend use IEEE-1394 for the best possible performance for external storage.
When will you learn that GUI programs like that will not provide you accurate results. Also USB is a very, very limited connection, so throughput will be affected when trying to sync data. Again GUI programs that gauges the length of time and throughput will sync the data to get a before and after values then it calculate the difference between the values to get a result for write performance.
USB is just slow period. I strongly recommend you use IEEE-1394 or SATA for external storage. When using either IEEE-1394 or SATA for external data storage, you will get equal performance as internal storage drives.
You could use IOzone, Bonnie++, or other storage benchmark utilities to figure out the throughput. It should not be any different.
USB is just slow period. I strongly recommend you use IEEE-1394 or SATA for external storage. When using either IEEE-1394 or SATA for external data storage, you will get equal performance as internal storage drives.
I don't currently own any 1394 or SATA devices. What I do own is an external USB hard disk and a handful of thumb drives.
I know they're not as fast as other storage devices, but my entire point is that until a system update in a few months back - all the way from my days towards the end of Edgy Efts' life cycle (early Spring of 2007), through Feisty Fawn, clear through Gutsy Gibbon and on into my first couple months of using Hardy Heron - I had USB read and write speeds that approached and sometimes hit 30MB/s.
If that's not a technically-accurate measure, as you say, then let me put it this way:
Writing three or four gigs of movie (.avi) files to my external hard disk - as recent as a few months ago - used to take no more than a few minutes, and now it takes almost ONE FULL HOUR to make it happen. How's that for a scientific analysis?
When I first bought this Toshiba Satellite a135 laptop brand-new in April of '07, the first thing I did when I got it home was resize the default Vista install and slap Feisty Fawn into it. I had 20 to 30MB/s transfer speeds. It is capable of it. It used to do it.
Since I first noticed this problem back in June or July, I've re-installed Ubuntu almost ten times trying to track this down (One Feisty, one Gutsy, and Hardy KDE, Gnome, and XFCE twice each). I could re-install it right now and get those transfer speeds again but the performance would die again after the first update.
I shouldn't have to re-install an entire OS from scratch and lock version numbers on every single installed package in order to fix this. The problem should be identifiable and correctable. I shouldn't have to go out and blow a couple hundred bucks on new hardware when I know for a fact that there's nothing wrong with what I already own. (Everything works fine under Vista on the same computer. Everything works fine when I boot the same computer off of a live-cd by any distro that has one.) These same devices have always automounted and there never used to be a problem. Everybody says "manually mount without sync", but as I showed, my automount isn't using sync so that's obviously not the problem. And it's not "just how USB works on any system" - because it used to work completely differently on this very same system.
Please - If you have no advice to offer or a practical method for me to hunt down this problem, unsubscribe this thread and let me try to get help from someone who does.
Right. Electro doesn't know what he's talking about. IEEE 1394 tops out at 786 Mbit/sec and USB 2.0 at 480 Mbits/sec. In practice, firewire mass storage devices aren't any faster.
We've done tests on very fast compact flash devices on USB 2.0 and achieved well over 30 MB/sec reading and writing. That being said, I don't know what could be wrong with your USB setup (sorry).
We have a client who needs to preload a large (like 100,000 per month) number of audio players with content. We have done tests with them, mounted as raw devices and no file system. We found that we could write to one of them with good performance, but write speeds dropped dramatically after two or three devices were added and just got worse from there. We tried PCI-based USB 2.0 controllers, no external hubs, and doing the sync's ourselves and nothing helped. It looks like there may be a bottleneck in libusb or somewhere in the kernel. Anybody have any ideas?
I was thinking of looking at the fast USB library in the USRP project, haven't had time yet. It enqueues multiple URBs and does I/O about as fast as it can get done.
Well, one other clue to my specific problems might be that they're not limited solely to USB devices - moving files between partitions on my internal HDD is just as time-consuming.
No too long ago, I was heading out the door to go somewhere with the wife and my new habit is to set my files to copy while I'm away or asleep. I selected all the files in my Videos folder I wanted to save to my USB disk, but I accidentally hit the Delete key, sending them to the Trash Bin. "No big deal," I thought, "I'll just move them back to Videos and then move them to the disk."
I have my Home directory on a its' own partition, and moving the files from Trash back to ~/Videos took as long as it would have to move them to the USB device.
Since then, I've come to learn that moving files between my Home dir (or anywhere else in Ubuntu) and my Windows partition also has the bad write lag.
Reading files from anywhere isn't a problem - I can run an .avi file right off my USB HDD through VLC and have no problems. If I want to read that same file and write it to a different partition, that's where the problem comes in.
Right. Electro doesn't know what he's talking about. IEEE 1394 tops out at 786 Mbit/sec and USB 2.0 at 480 Mbits/sec. In practice, firewire mass storage devices aren't any faster.
We've done tests on very fast compact flash devices on USB 2.0 and achieved well over 30 MB/sec reading and writing. That being said, I don't know what could be wrong with your USB setup (sorry).
We have a client who needs to preload a large (like 100,000 per month) number of audio players with content. We have done tests with them, mounted as raw devices and no file system. We found that we could write to one of them with good performance, but write speeds dropped dramatically after two or three devices were added and just got worse from there. We tried PCI-based USB 2.0 controllers, no external hubs, and doing the sync's ourselves and nothing helped. It looks like there may be a bottleneck in libusb or somewhere in the kernel. Anybody have any ideas?
I was thinking of looking at the fast USB library in the USRP project, haven't had time yet. It enqueues multiple URBs and does I/O about as fast as it can get done.
J
I know what I am talking about. IEEE-1394 is faster than USB because of its hardware. What you do not know, USB has too much over head to handle high data transfers for long periods. USB does not use DMA to handle large amounts of data quickly and by it self. Also USB is not a point to point interface. USB relies on packets for transmission, so these packets will reduces bandwidth significantly if the size of the packets are chosen wisely. When IEEE-1394 is used, its point to point connection works the same as SCSI so it can provide equal performance. It also provides DMA, so the processor can do other things while the IEEE-1394 device is transferring data.
Using PCI cards for USB will not be any different than using on-board USB. The same holds true with IEEE-1394.
Linux has a lot of redundancies in place for writing data. The checks that Linux is doing for every write task is reducing the bandwidth of USB. With USB being dependent on software for its tasks penalizes USB's bandwidth even further.
Stating theoretical speeds does not work in the real world. USB will never even come close to 480 megabits per second. The reason why is because it relies heavily on software for I/O and all the hubs that is between the host and the device deteriorates the signal.
Yes, Linux USB subsystem has poor performance although it is reliable and stable. Windows on the hand is not reliable and stable for USB, but it has high performance.
On my setups I get up to 15 megabytes per second with USB. This is with using a GUI program. If I use cp, I am sure it will get a lot higher. The file systems that I tested with is EXT3 to FAT32. Both file systems are known to not provide high bandwidth.
A compact flash that has 30 megabytes per second is hard for me to believe. A lot of buffering is involve in that throughput. Compact flash can not go any higher than a few megabytes per second.
Quote:
Originally Posted by uncertain
Well, one other clue to my specific problems might be that they're not limited solely to USB devices - moving files between partitions on my internal HDD is just as time-consuming.
No too long ago, I was heading out the door to go somewhere with the wife and my new habit is to set my files to copy while I'm away or asleep. I selected all the files in my Videos folder I wanted to save to my USB disk, but I accidentally hit the Delete key, sending them to the Trash Bin. "No big deal," I thought, "I'll just move them back to Videos and then move them to the disk."
I have my Home directory on a its' own partition, and moving the files from Trash back to ~/Videos took as long as it would have to move them to the USB device.
Since then, I've come to learn that moving files between my Home dir (or anywhere else in Ubuntu) and my Windows partition also has the bad write lag.
Reading files from anywhere isn't a problem - I can run an .avi file right off my USB HDD through VLC and have no problems. If I want to read that same file and write it to a different partition, that's where the problem comes in.
AVI files encoded in Xvid, Divx, or h.264 will have no problems with USB because the bandwidth require for AVI using those codecs is around 300 to 600 kilobytes per second.
One problem that always comes up is processor usage since an AVI file using huffyuv video codec can easily be play back with no notice of dropped frames. The file is directly read from a USB storage drive with ReiserFS.
Again USB is very, very software dependent. If you want high throughput, use a file system that does not take much processor usage, do not use a GUI program to copy files to it, and use a very, very high performance processor. If you want the copying of several big files to be done fast, use either IEEE-1394 or SATA. If you do not want to, you have to bite your lip and use USB.
Please do not compare Windows and Linux. They both are very different on how they handle USB.
A compact flash that has 30 megabytes per second is hard for me to believe. A lot of buffering is involve in that throughput. Compact flash can not go any higher than a few megabytes per second.
[...]
Again USB is very, very software dependent. If you want high throughput, use a file system that does not take much processor usage, do not use a GUI program to copy files to it, and use a very, very high performance processor. If you want the copying of several big files to be done fast, use either IEEE-1394 or SATA. If you do not want to, you have to bite your lip and use USB.
Either buy me a 1394/SATA drive and mail it to me, or shut the hell up about it!
I'm here trying to find out why my USB devices don't go as fast as they do when I'm running a fresh install; I'm not here trying to start a debate about which kind of external storage is better and why.
I'll ask one more time:
Please - If you don't have any practical advice for me on how to track down this problem, unsubscribe this thread and let me try to find someone who does.
As a side note, cp and mv commands have the same slow write times. Only when copying and moving to the USB device; not copying or moving from the device.
Either buy me a 1394/SATA drive and mail it to me, or shut the hell up about it!
I'm here trying to find out why my USB devices don't go as fast as they do when I'm running a fresh install; I'm not here trying to start a debate about which kind of external storage is better and why.
I'll ask one more time:
Please - If you don't have any practical advice for me on how to track down this problem, unsubscribe this thread and let me try to find someone who does.
As a side note, cp and mv commands have the same slow write times. Only when copying and moving to the USB device; not copying or moving from the device.
I already gave you practicable advice and you do not care thinking. I am not starting a debate. I telling the truth about USB. It has always been slow. Do a search in this forum and many other forums. You will get the same thing.
At this time the best advice I can give you right now since you do not care of taking my advice is talk to a kernel developer that is handling USB subsystem for Linux.
Compact flash can not go any higher than a few megabytes per second.
Here's a screenshot of me doing a file transfer to that same USB hard-drive on a Fresh Install of Hardy Heron, screaming along at a thought-to-be-unattainable 19.9MB/s. (The file transfer completed in just barely over two minutes; that's a gigabyte-a-minute, as opposed to a gigabyte every ten minutes, for all you scientific types.) I'd be willing to bet it's only running that slow because I'm compiling compiz-fusion in the background. That shot is sort of an oddball, too - it actually hung closer to 20 or 21 most of the time. The speed did vary pretty widely, though, and dipped as low as 13 or 14.
I figured what the heck and did a fresh install, locking all the version number on installed packages before connecting to the net.
I should note that I'm pretty darn sure that it will eventually degrade, and I'll be stuck back at 3 or 4 or 5 MB/s again, but here's the thing:
That's why I started this thread - so I can find out why and fix it without having to reinstall.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
