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.
Let's dig a little deeper and think outside the box. :)
Uncertain,
A couple of questions to look at some other areas:
1. Do you have any encryption on any of your drives, especially the USB drive?
2. What types of partitions are on your drives? (EXT2, EXT3, FAT32, NTFS)
3. You refer to an a135 Toshiba. I have had my experiences with Toshiba and Linux (And found Kubuntu to not function at all, while Ubuntu will on one of then, weird but true). The question is: Have you gone into your BIOS Settings and changed the USB Legacy option (if its there)? If not, give that a try and see if that changes anything. The updates may have something to do with that. Sort of like the ACPI bug in Ubuntu 7.10 (and most other Distros at the time).
4. What is the exact model of your laptop???
Let's go with this and see what you have to answer with and see if we can't get anywhere.
A couple of questions to look at some other areas:
1. Do you have any encryption on any of your drives, especially the USB drive?
2. What types of partitions are on your drives? (EXT2, EXT3, FAT32, NTFS)
3. You refer to an a135 Toshiba. I have had my experiences with Toshiba and Linux (And found Kubuntu to not function at all, while Ubuntu will on one of then, weird but true). The question is: Have you gone into your BIOS Settings and changed the USB Legacy option (if its there)? If not, give that a try and see if that changes anything. The updates may have something to do with that. Sort of like the ACPI bug in Ubuntu 7.10 (and most other Distros at the time).
4. What is the exact model of your laptop???
Let's go with this and see what you have to answer with and see if we can't get anywhere.
-Cybie
1. Nope - no encryption.
2. The 320GB external HDD is formatted FAT32, which makes it a pain to share with samba, but that's the only real issue. I have a number of thumb drives of varying sizes, all but one of which are also formatted FAT32 - the exception is formatted EXT3, and it shows the same slow transfer rate.
3. Yes, I've tried changing the BIOS settings. There's no real options to choose from - either I select support for legacy USB devices or I don't. Things work the same with either option selected.
4. Exact model is Satellite a135-s4527. I'll attach the output of dmidecode so you can see detailed information for everything
Code:
zero@zero-laptop:~$ dmidecode
# dmidecode 2.9
SMBIOS 2.4 present.
22 structures occupying 1005 bytes.
Table at 0x000DC010.
Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: TOSHIBA
Version: V1.30
Release Date: 03/30/2007
Address: 0xE59B0
Runtime Size: 108112 bytes
ROM Size: 512 kB
Characteristics:
PCI is supported
PC Card (PCMCIA) is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
Japanese floppy for Toshiba 1.2 MB is supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
AGP is supported
Smart battery is supported
BIOS boot specification is supported
Targeted content distribution is supported
BIOS Revision: 1.48
Firmware Revision: 1.48
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: TOSHIBA
Product Name: Satellite A135
Version: PSAD0U-05400P
Serial Number: 47444713K
UUID: CFBC01EA-E93E-11DB-A8DD-0016D4F7F84D
Wake-up Type: Power Switch
SKU Number: 012345678912345678912345678
Family: ABCDEFGHIJKLMNOPQRSTUVWXYZ
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: TOSHIBA
Product Name: IAKAA
Version: 1.00
Serial Number: 0123456789AB
Handle 0x0003, DMI type 3, 17 bytes
Chassis Information
Manufacturer: TOSHIBA
Type: Notebook
Lock: Not Present
Version: N/A
Serial Number: None
Asset Tag: *
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x00001234
Handle 0x0004, DMI type 4, 35 bytes
Processor Information
Socket Designation: U2E1
Type: Central Processor
Family: Other
Manufacturer: Intel
ID: EC 06 00 00 FF FB E9 BF
Version: Genuine Intel(R) CPU T2
Voltage: 3.3 V
External Clock: Unknown
Max Speed: 2048 MHz
Current Speed: 1730 MHz
Status: Populated, Enabled
Upgrade: ZIF Socket
L1 Cache Handle: 0x0005
L2 Cache Handle: 0x0006
L3 Cache Handle: Not Provided
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0005, DMI type 7, 19 bytes
Cache Information
Socket Designation: L1 Cache
Configuration: Enabled, Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 32 KB
Maximum Size: 32 KB
Supported SRAM Types:
Burst
Pipeline Burst
Asynchronous
Installed SRAM Type: Asynchronous
Speed: Unknown
Error Correction Type: Unknown
System Type: Unknown
Associativity: Unknown
Handle 0x0006, DMI type 7, 19 bytes
Cache Information
Socket Designation: L2 Cache
Configuration: Enabled, Socketed, Level 2
Operational Mode: Write Back
Location: External
Installed Size: 1024 KB
Maximum Size: 512 KB
Supported SRAM Types:
Burst
Pipeline Burst
Asynchronous
Installed SRAM Type: Burst
Speed: Unknown
Error Correction Type: Unknown
System Type: Unknown
Associativity: Unknown
Handle 0x0007, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J6
Internal Connector Type: None
External Reference Designator: Keyboard
External Connector Type: Circular DIN-8 male
Port Type: Keyboard Port
Handle 0x0008, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J5
Internal Connector Type: None
External Reference Designator: PS/2 Mouse
External Connector Type: Circular DIN-8 male
Port Type: Keyboard Port
Handle 0x0009, DMI type 9, 13 bytes
System Slot Information
Designation: TI7412
Type: 32-bit PCI
Current Usage: Unknown
Length: Long
ID: 0
Characteristics:
5.0 V is provided
3.3 V is provided
Handle 0x000A, DMI type 10, 6 bytes
On Board Device Information
Type: Sound
Status: Disabled
Description: HD-Audio
Handle 0x000B, DMI type 11, 5 bytes
OEM Strings
String 1: PSAD0U-05400P,SQ004286V02,11B
Handle 0x000C, DMI type 12, 5 bytes
System Configuration Options
Option 1: Jumper settings can be described here.
Handle 0x000D, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 3 GB
Error Information Handle: Not Provided
Number Of Devices: 2
Handle 0x000E, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000D
Error Information Handle: No Error
Total Width: 32 bits
Data Width: 32 bits
Size: 512 MB
Form Factor: SODIMM
Set: 1
Locator: M1
Bank Locator: Bank 0
Type: DDR
Type Detail: Synchronous
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x000F, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000D
Error Information Handle: No Error
Total Width: 32 bits
Data Width: 32 bits
Size: 512 MB
Form Factor: SODIMM
Set: 1
Locator: M2
Bank Locator: Bank 1
Type: DDR
Type Detail: Synchronous
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0010, DMI type 19, 15 bytes
Memory Array Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x0003FFFFFFF
Range Size: 1 GB
Physical Array Handle: 0x000D
Partition Width: 0
Handle 0x0011, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x0001FFFFFFF
Range Size: 512 MB
Physical Device Handle: 0x000E
Memory Array Mapped Address Handle: 0x0010
Partition Row Position: Unknown
Interleave Position: Unknown
Interleaved Data Depth: Unknown
Handle 0x0012, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00020000000
Ending Address: 0x0003FFFFFFF
Range Size: 512 MB
Physical Device Handle: 0x000F
Memory Array Mapped Address Handle: 0x0010
Partition Row Position: Unknown
Interleave Position: Unknown
Interleaved Data Depth: Unknown
Handle 0x0013, DMI type 22, 26 bytes
Portable Battery
Location: 1st Battery
Manufacturer: TOSHIBA
Manufacture Date: 12/01/2005
Serial Number: 3658Q
Name: PA3395U
Chemistry: Lithium Ion
Design Capacity: 31500 mWh
Design Voltage: 14800 mV
SBDS Version: Not Specified
Maximum Error: Unknown
OEM-specific Information: 0x00000000
Handle 0x0014, DMI type 32, 20 bytes
System Boot Information
Status: <OUT OF SPEC>
Handle 0x0015, DMI type 127, 4 bytes
End Of Table
I live in Poland now, but I bought the laptop when I still lived in the States - Point being that it's a US model. As a side note, my wife's laptop is a European model Acer Travelmate 2480 running Hardy that also has the same slow USB speeds both reading from and writing to a USB device.
Odd. Very odd. I might be wrong, but this would indicate that perhaps something else is at fault? What else gets updated in a "fatal" update?
Could you upload the "broken" kernel config (and a known good one to compare it against) somewhere and post the link here so that I can take a quick look when I get home from work?
Sorry... must have missed that post somewhere in the mix. I'm not sure what all else gets updated.. just about every package you can name from a fresh install of 8.04, really. Jaunty is set to come out in less than two months or so.. Hardy is close to a year old. The last re-install I did was around September or October (if I remember right) and there were something like 280-some-odd megabytes of updates to download and apply. It's probably more by now.
I'll gladly post any details you'd like to see.. just tell me what commands to run and I'll C&P/attach the outputs here.
The only way for me to get a good, working configuration to compare to is to do my re-install, though. Like I said, I'm leaning in that direction anyways, so by this weekend I could have the good configuration for comparison.
Let me know how you want to do this. Maybe shoot me a PM and we can exchange emails or something.
Quote:
Originally Posted by rkelsen
uncertain: I feel your pain, but at this point I'd be ignoring this guy. He has contributed nothing useful to the thread so far and probably won't. Don't waste your time or energy.
True, true. I guess I should be the one to take the high road here.. Better late than never.
If you think being immature and finding the best setup for the best USB performance will fix the problem, you think wrong. You have to download the latest vanilla kernel and start editing it to fix the problem. Doing it your way will never get things fix. Doing something like my way is the step in the right direction to get things fixed.
Quote:
Originally Posted by cybie257
Umm, I think I did by stating that I was getting 26.3MB/Sec while writing that last reply. And yes, that was the nautilis GUI progress bar/status time shown, but the MATH showed it to be accurate within +-5%.
As for hardware:
GigaByte Motherboard GA-P35C-DS3R
4 GIGS Kingston 800 DDR2 RAM
Core 2 Duo Intel CPU 1.6GHz (Speed may be slightly higher)
On Board USB to Externeral USB Hub (Hub = Cheap Generic 7-Port, powered)
EverTech (generic brand) Ext USB 3.5" SATA HD Enclosure
Cheap generic USB 3-foot cable
(Other hardware irrelevant to USB topic)
Ubuntu 8.10 All the latest updates (No new updates available at this time)
Portability, compatibility, USB is the way to go. Even if it's not the fastest. Yes, I like E-sata, but what happens when I take my external HD to a friends house who doesn't have E-Sata? It like saying Blu-Ray is the way to go. Yeah, 50GB is awesome, but what good does it do if the majority of people don't have the ability to read the medium???
I never said it was just for Mac. I said it is more popular for Mac. It was developed by Apple to replace the parallel SCSI bus. Firewire also is being held back due to royalty requirements by Apple. That's why it's mosty found in MACs.
The problem with your replies aren't that you don't have any less right to speak your mind, it's that you avoided the original question of this thread over and over. The question was, USB was going "THIS FAST" and now it's going "THIS SLOW" after updates. Hardware is NOT the issue. I achieve 25MB/Sec on Average copy to and from my USB drive. If you don't believe it because yours doesn't work, then great. Mine does and I have had cheap motherboards in the past that have produced poor USB performance. But then again, the entire system was poor. Your computer will only perform as good as the hardware is. In my opinion, based on experience with numerous manufactures, GigaByte provides one of the best, affordable motherboards out there. In fact, the board I have will even run OSX. Yes, I have done so already with no special hardware. Search the net for the board model and OSX and you will find it on the list to run OSX natively.
Oh, and just an FYI. Copying from a native EXT2 Internal SATA to the same external drive (formatted as a Native EXT2), provided read/write speeds at and above 35MB/Sec. That's with nothing else being done on the computer and is a fact.
-Cybie
I have provided information that is more relevant to the issue than posting silly throughput readings that might be skewed, but nobody took the offer. Again what needs to be done is a complete re-write of USB for the kernel. If that is too much, editing the kernel source to provide patches to people for testing. I will be willing to test the patches, but it seems uncertain and others just wants to complain about the throughput issues and not get dirty to edit the source code. I am not willing to fix the issue.
The performance of USB is not annoying me like hell like many others. What annoys me is the reliability of USB and how gullible people are while looking at throughput statistics.
I am using the following setup for USB.
6 foot USB 2.0 with Ferrite bobbins
USB 2.0 to IDE: M-System ISD300A1
Power supply: Meanwell D-60A
Seagate Barracuda 7200.7 120 GB (ST3120022A)
I tested with Intel ICH9 and NEC USB 2.0 controller in different setups. All about the same throughput using iozone in different systems.
I tried sending a PM, but it said that you can't receive them.
So, I sent you an email. Post here if you don't receive it.
Cheers!
I got your email and sent the attachments directly to you. I'll post them here, too, just in case something got lost along the way or if someone else wants to have a look. Just for giggles, I ran a diff command on them, and the changes shown are minimal. I'll attach that output, too.
Hmmm... Not much has changed... but it looks like there were some changes to the IO scheduler.
Please post the output of this command: (substituting "sda" for the USB device)
Code:
cat /sys/block/sda/queue/scheduler
It'd be best you could post the output of this command under both kernels.
I'll do it as soon as I get home from work and have access to the drive.
I'll check back in a few hours with the outputs from both kernels. I'll even try it from a livecd session, so there's a baseline to compare to.
Changes to the I/O scheduler is in line with what I see happening when I move files to USB or between my partitions. If I put a gnome system monitor in my panel, the User, System, and Nice parts of the graph are about you'd expect to see, but the graph goes almost solid for the I/O Wait Time category. (Check the screenshot here for an example: http://img518.imageshack.us/img518/4952/screenshotq.png) Notice in the graph, and in my Conky, the actual CPU usage is low. Everything is going to whatever the Gnome people are calling I/O wait time.
Changes to the I/O scheduler is in line with what I see happening when I move files to USB or between my partitions.
This also happens between hard disk partitions?
Quote:
Originally Posted by uncertain
Maybe we're on to something.
Let's hope so.
Seeing this behaviour between hard disk partitions would indicate that the default scheduler may not be best for your needs. Your config files indicate that the CFQ scheduler is the default on both kernels.
I'll explain how to change it now, because I'm going to bed shortly...
The output of the command in the previous post should look something like this:
In this case, the noop, anticipatory, deadline and cfq schedulers are available for sda, and the brackets indicate that the cfq scheduler is currently selected.
The way to change it would be: (again substituting sda for the USB device)
Yes it is. The screenshot I linked to up there is me moving a video I had deleted (for demonstration purposes) from my Trash folder back to ~/Videos. (My home directories reside on their own partition, separate from root.)
Changing the setting on sda didn't have any noticeable effect. If anything, I'd say it might have slowed me down a little bit more - my GUI becomes almost totally unresponsive while a file transfer is in progress. Things like Compiz still work - switching desktops or switching between windows with alt+tab are fine, but trying to open a FF window while the transfer was working took almost a full four minutes.
You think I should try the other options, just for giggles?
You think I should try the other options, just for giggles?
No, it probably won't make any difference. Don't worry about changing the setting back, it'll reset itself when you reboot.
From your diff, these are the non-driver related items which have changed.
Code:
> CONFIG_CGROUPS=y
> CONFIG_CGROUP_CPUACCT=y
> CONFIG_CGROUP_NS=y
> CONFIG_FAIR_CGROUP_SCHED=y
> # CONFIG_FAIR_USER_SCHED is not set
< # CONFIG_CGROUPS is not set
> CONFIG_CPUSETS=y
< # CONFIG_FAIR_CGROUP_SCHED is not set
< CONFIG_FAIR_USER_SCHED=y
< CONFIG_VERSION_SIGNATURE="Ubuntu 2.6.24-16.30-generic"
---
> CONFIG_VERSION_SIGNATURE="Ubuntu 2.6.24-23.49-generic"
Note the addition of Control Groups and the Fair Control Group Scheduler and the removal of the Fair User Scheduler.
Could this be the cause? Do you have the libcgroup package installed?
No, it probably won't make any difference. Don't worry about changing the setting back, it'll reset itself when you reboot.
From your diff, these are the non-driver related items which have changed.
Code:
> CONFIG_CGROUPS=y
> CONFIG_CGROUP_CPUACCT=y
> CONFIG_CGROUP_NS=y
> CONFIG_FAIR_CGROUP_SCHED=y
> # CONFIG_FAIR_USER_SCHED is not set
< # CONFIG_CGROUPS is not set
> CONFIG_CPUSETS=y
< # CONFIG_FAIR_CGROUP_SCHED is not set
< CONFIG_FAIR_USER_SCHED=y
< CONFIG_VERSION_SIGNATURE="Ubuntu 2.6.24-16.30-generic"
---
> CONFIG_VERSION_SIGNATURE="Ubuntu 2.6.24-23.49-generic"
Note the addition of Control Groups and the Fair Control Group Scheduler and the removal of the Fair User Scheduler.
Could this be the cause? Do you have the libcgroup package installed?
I ran dpkg -l | grep libcgroup at a terminal, and didn't get any output - I think that's terminal's way of saying 'no'. There is, of course, libc6, libc6-dev, libc6-i686, and linux-libc-dev. Are those connected somehow, or no?
I also did an apt-cache search for libcgroup, and didn't get any response. I don't think that package is even in any of the ubuntu repos I have enabled.
I ran that command on sdb when I got home last night - I didn't notice any effect at all, positive or negative.
I still think we're on the right track with this line of thinking.
I don't believe it, but it seems to be true: The most recent kernel updates fixed my problems.
Well, not exactly "fixed" in the purest sense of the word, but things are a lot better than they were.
I have read speeds averaging around 20MB/s and write speeds that hang between 24 and 25 Mb/s, but still slowly degrade to around 19 or so.
There does seem to still be a file size associated with how this works. Historically, since I first fell victim to this bug, files that came in under 7000MB (think: AVI files) in size seemed to go pretty much as fast as anything, but once that 700MB line was crossed it was slowville all the way. Read speeds always appeared to be completely unaffected, up until the previous kernel update, which sent my read speeds down the same toilet.
I've tested the transfer speeds with AVI files of various sizes, and then I grabbed a big batch of around 14GB worth (like 10 or 12 files) and moved them off & back onto my drive. Single files work normally. The big batch took a little longer than Nautilus said it was taking, but it still went faster than it used to.
I don't know... I just wish it was something I did so I would know it's a lasting, permanent change and not just dumb luck.
I'll attach the kernel config just so there's something to compare to previously given info.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
