From: Tristan H. <Tri...@ge...> - 2009-07-08 06:26:22
|
Hi, I tried sending this to the list earlier but it appears to have bounced. Perhaps the original email including kernel config was too big. I'm working on a project incorporating the Overo module and several USB peripherals (Network adapter, Sierra Wireless 3G modem, TI USB audio device and a USB serial adapter) connected to the EHCI host port via a hub. We are having an issue with the host port on both the air and earth modules (we have tested around 10 different boards) when mounted on the Summit board. In our case, the USB devices are plugged into an external powered USB 2.0 hub (several hub models/chipsets have been tried, at least one had a separate transaction translator for each port) and we are experiencing periodic disconnections of the USB hub from the EHCI host. This occurs at different frequencies with different combinations of peripherals but it always occurs sooner or later. The same issue has been reported on the beagle in this thread http://groups.google.com/group/beagleboard/browse_thread/thread/5b8385f0bb1f63da and they seem to suspect that it may be a hardware issue. We are running Kernel 2.6.29-rc3. A sample of the error messages reported are included below. We are having enough trouble establishing if the issue is hardware or software let alone being able to close in on our own solution (We have tried so many combinations of peripherals, power source, etc. Sometimes the issue appears to be gone but it always re-appears). Does anyone else have any insight into causes/possible solutions? Is anyone else successfully (and reliably) using the EHCI host port with several USB peripherals on a hub? If so what kernel version/config etc. are you using? For the project we will be using the OTG port for accessing the Overo as a file backed storage gadget so we can't fall back to it as an alternative USB host. Unfortunately this single issue is holding us back from proceeding with a design for our own base board and we may have to scrap the project or select another embedded module if we cannot resolve it soon. Otherwise, the Overo has proven to be a good platform to develop on so I hope we can make some progress into finding a cause. - Thanks, Tristan hub 1-0:1.0: port 2 disabled by hub (EMI?), re-enabling... usb 1-2: USB disconnect, address 2 usb 1-2.1: USB disconnect, address 3 ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 ftdi_sio 1-2.1:1.0: device disconnected usb 1-2.3: USB disconnect, address 8 usb 1-2.4: USB disconnect, address 9 eth0: unregister 'smsc95xx' usb-ehci-omap.0-2.4, smsc95xx USB 2.0 Ethernet usb 1-2: new high speed USB device using ehci-omap and address 10 usb 1-2: New USB device found, idVendor=0409, idProduct=005a usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 1-2: configuration #1 chosen from 1 choice hub 1-2:1.0: USB hub found hub 1-2:1.0: 4 ports detected usb 1-2.1: new full speed USB device using ehci-omap and address 11 usb 1-2.1: New USB device found, idVendor=0403, idProduct=6001 usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-2.1: Product: USB <-> Serial usb 1-2.1: Manufacturer: FTDI usb 1-2.1: configuration #1 chosen from 1 choice ftdi_sio 1-2.1:1.0: FTDI USB Serial Device converter detected usb 1-2.1: Detected FT232BM usb 1-2.1: FTDI USB Serial Device converter now attached to ttyUSB0 usb 1-2.2: new full speed USB device using ehci-omap and address 12 usb 1-2.2: device descriptor read/64, error -32 usb 1-2.2: device descriptor read/64, error -32 usb 1-2.2: new full speed USB device using ehci-omap and address 13 usb 1-2.2: device descriptor read/64, error -32 usb 1-2.2: device descriptor read/64, error -32 usb 1-2.2: new full speed USB device using ehci-omap and address 14 usb 1-2.2: device not accepting address 14, error -32 usb 1-2.2: new full speed USB device using ehci-omap and address 15 usb 1-2.2: device not accepting address 15, error -32 hub 1-2:1.0: unable to enumerate USB device on port 2 usb 1-2.3: new full speed USB device using ehci-omap and address 16 usb 1-2.3: New USB device found, idVendor=08bb, idProduct=29b2 usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-2.3: Product: USB Audio CODEC usb 1-2.3: Manufacturer: Burr-Brown from TI usb 1-2.3: configuration #1 chosen from 1 choice input: Burr-Brown from TI USB Audio CODEC as /class/input/input3 generic-usb 0003:08BB:29B2.0002: input: USB HID v1.00 Device [Burr-Brown from TI USB Audio CODEC ] on usb-ehci-omap.0-2.3/input3 usb 1-2.4: new high speed USB device using ehci-omap and address 17 usb 1-2.4: New USB device found, idVendor=0424, idProduct=9500 usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-2.4: Product: LAN9500 usb 1-2.4: Manufacturer: SMSC usb 1-2.4: SerialNumber: 000950B41 usb 1-2.4: configuration #1 chosen from 1 choice smsc95xx v1.0.4 eth0 (smsc95xx): not using net_device_ops yet eth0: register 'smsc95xx' at usb-ehci-omap.0-2.4, smsc95xx USB 2.0 Ethernet, 00:80:0f:95:0b:41 hub 1-0:1.0: port 2 disabled by hub (EMI?), re-enabling... usb 1-2: USB disconnect, address 10 usb 1-2.1: USB disconnect, address 11 ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 ftdi_sio 1-2.1:1.0: device disconnected usb 1-2.3: USB disconnect, address 16 usb 1-2.4: USB disconnect, address 17 eth0: unregister 'smsc95xx' usb-ehci-omap.0-2.4, smsc95xx USB 2.0 Ethernet usb 1-2: new high speed USB device using ehci-omap and address 18 usb 1-2: New USB device found, idVendor=0409, idProduct=005a usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 1-2: configuration #1 chosen from 1 choice hub 1-2:1.0: USB hub found hub 1-2:1.0: 4 ports detected usb 1-2.1: new full speed USB device using ehci-omap and address 19 usb 1-2.1: New USB device found, idVendor=0403, idProduct=6001 usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-2.1: Product: USB <-> Serial usb 1-2.1: Manufacturer: FTDI usb 1-2.1: configuration #1 chosen from 1 choice ftdi_sio 1-2.1:1.0: FTDI USB Serial Device converter detected usb 1-2.1: Detected FT232BM usb 1-2.1: FTDI USB Serial Device converter now attached to ttyUSB0 usb 1-2.2: new full speed USB device using ehci-omap and address 20 usb 1-2.2: device descriptor read/64, error -32 usb 1-2.2: device descriptor read/64, error -32 usb 1-2.2: new full speed USB device using ehci-omap and address 21 usb 1-2.2: device descriptor read/64, error -32 usb 1-2.2: device descriptor read/64, error -32 Start recording Child process getpid: 1934 getppid: 1712 Parent running pid: 1934 getpid: 1712 Recording WAVE 'schAudio.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono usb 1-2.2: new full speed USB device using ehci-omap and address 22 usb 1-2.2: device not accepting address 22, error -32 usb 1-2.2: new full speed USB device using ehci-omap and address 23 usb 1-2.2: device not accepting address 23, error -32 hub 1-2:1.0: unable to enumerate USB device on port 2 usb 1-2.3: new full speed USB device using ehci-omap and address 24 usb 1-2.3: New USB device found, idVendor=08bb, idProduct=29b2 usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-2.3: Product: USB Audio CODEC usb 1-2.3: Manufacturer: Burr-Brown from TI usb 1-2.3: configuration #1 chosen from 1 choice input: Burr-Brown from TI USB Audio CODEC as /class/input/input4 generic-usb 0003:08BB:29B2.0003: input: USB HID v1.00 Device [Burr-Brown from TI USB Audio CODEC ] on usb-ehci-omap.0-2.3/input3 usb 1-2.4: new high speed USB device using ehci-omap and address 25 usb 1-2.4: New USB device found, idVendor=0424, idProduct=9500 usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-2.4: Product: LAN9500 usb 1-2.4: Manufacturer: SMSC usb 1-2.4: SerialNumber: 000950B41 usb 1-2.4: configuration #1 chosen from 1 choice smsc95xx v1.0.4 eth0 (smsc95xx): not using net_device_ops yet eth0: register 'smsc95xx' at usb-ehci-omap.0-2.4, smsc95xx USB 2.0 Ethernet, 00:80:0f:95:0b:41 eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 *********************************************************************** Tristan Henderson Software Engineer Geonautics International Pty Ltd 60 Morley Street, Coorparoo Queensland 4151 AUSTRALIA Web: http://www.geonautics.com Tel: + 61 7 33242555 Fax: + 61 7 33242566 Email link: Tristan Henderson's Email *********************************************************************** This message and any associated attachments may contain Privileged / Confidential Information and are intended solely for the named addressees. Distribution or copying of any part of this transmission by anyone other than the addressees is prohibited. If you have received this message in error please delete the message and destroy any printed copies. Views in this message are those of the individual sender. |
From: Jason C. M. <jas...@am...> - 2009-07-08 17:35:06
|
I've had the same issue with a Rev C2 beagleboard. Sometimes I can go an entire day without a disconnection, and other times I get a few within an hour. As of today this is my biggest concern regarding the Overo/OMAP3x, and it might prevent us from going into development with it. I think most people just shrug it off because they haven't experienced it on their one or two boards. Or they try to put the blame on their hub which is easy because most of them are cheap crap. Yet that cheap crap still works on their PC without disconnections. It doesn't help matters that the EHCI port wasn't even on any of the initial OMAP35x boards. It wasn't on the OMAP3 EVM, and it wasn't "really" on any of the beagleboard rev's up till rev C. The gumstix overo earth / summit board was the first one I saw it on. It wasn't even working in the beginning on their board. Now its on all these boards with kernels that support it. Gumstix Overo Line OMAP3 EVM -> With the Multi-media daughter card Beagleboard Rev C2 and higher I'm going to test the OMAP3 EVM / Daughter Card, but I have rev ES2.1 of the OMAP3530 on the EVM board I have. TI made changes to the USB Host subsystem from ES 2.1 to the ES 3.1 so I don't think its really going to be an effective test. However if I can repeat the problem with that board its the one I'll get the most tech support with. Gumstix doesn't truly have tech support, and it doesn't seem like they have the resources for it. It works well for providing good hardware for a reasonable price so I'm not really complaining. FYI, here is the TI Errata for the OMAP35x silicon. From looking at it I don't think you can expect ES 2.1 to work well. What version do you have on your 10 different Overo Boards? http://focus.ti.com/lit/er/sprz278d/sprz278d.pdf ________________________________________ From: Tristan Henderson [Tri...@ge...] Sent: Tuesday, July 07, 2009 11:23 PM To: gum...@li... Subject: [Gumstix-users] Overo EHCI USB host port problems - resend Hi, I tried sending this to the list earlier but it appears to have bounced. Perhaps the original email including kernel config was too big. I'm working on a project incorporating the Overo module and several USB peripherals (Network adapter, Sierra Wireless 3G modem, TI USB audio device and a USB serial adapter) connected to the EHCI host port via a hub. We are having an issue with the host port on both the air and earth modules (we have tested around 10 different boards) when mounted on the Summit board. In our case, the USB devices are plugged into an external powered USB 2.0 hub (several hub models/chipsets have been tried, at least one had a separate transaction translator for each port) and we are experiencing periodic disconnections of the USB hub from the EHCI host. This occurs at different frequencies with different combinations of peripherals but it always occurs sooner or later. The same issue has been reported on the beagle in this thread http://groups.google.com/group/beagleboard/browse_thread/thread/5b8385f0bb1f63da and they seem to suspect that it may be a hardware issue. We are running Kernel 2.6.29-rc3. A sample of the error messages reported are included below. We are having enough trouble establishing if the issue is hardware or software let alone being able to close in on our own solution (We have tried so many combinations of peripherals, power source, etc. Sometimes the issue appears to be gone but it always re-appears). Does anyone else have any insight into causes/possible solutions? Is anyone else successfully (and reliably) using the EHCI host port with several USB peripherals on a hub? If so what kernel version/config etc. are you using? For the project we will be using the OTG port for accessing the Overo as a file backed storage gadget so we can't fall back to it as an alternative USB host. Unfortunately this single issue is holding us back from proceeding with a design for our own base board and we may have to scrap the project or select another embedded module if we cannot resolve it soon. Otherwise, the Overo has proven to be a good platform to develop on so I hope we can make some progress into finding a cause. - Thanks, Tristan hub 1-0:1.0: port 2 disabled by hub (EMI?), re-enabling... usb 1-2: USB disconnect, address 2 usb 1-2.1: USB disconnect, address 3 ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 ftdi_sio 1-2.1:1.0: device disconnected usb 1-2.3: USB disconnect, address 8 usb 1-2.4: USB disconnect, address 9 eth0: unregister 'smsc95xx' usb-ehci-omap.0-2.4, smsc95xx USB 2.0 Ethernet usb 1-2: new high speed USB device using ehci-omap and address 10 usb 1-2: New USB device found, idVendor=0409, idProduct=005a usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 1-2: configuration #1 chosen from 1 choice hub 1-2:1.0: USB hub found hub 1-2:1.0: 4 ports detected usb 1-2.1: new full speed USB device using ehci-omap and address 11 usb 1-2.1: New USB device found, idVendor=0403, idProduct=6001 usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-2.1: Product: USB <-> Serial usb 1-2.1: Manufacturer: FTDI usb 1-2.1: configuration #1 chosen from 1 choice ftdi_sio 1-2.1:1.0: FTDI USB Serial Device converter detected usb 1-2.1: Detected FT232BM usb 1-2.1: FTDI USB Serial Device converter now attached to ttyUSB0 usb 1-2.2: new full speed USB device using ehci-omap and address 12 usb 1-2.2: device descriptor read/64, error -32 usb 1-2.2: device descriptor read/64, error -32 usb 1-2.2: new full speed USB device using ehci-omap and address 13 usb 1-2.2: device descriptor read/64, error -32 usb 1-2.2: device descriptor read/64, error -32 usb 1-2.2: new full speed USB device using ehci-omap and address 14 usb 1-2.2: device not accepting address 14, error -32 usb 1-2.2: new full speed USB device using ehci-omap and address 15 usb 1-2.2: device not accepting address 15, error -32 hub 1-2:1.0: unable to enumerate USB device on port 2 usb 1-2.3: new full speed USB device using ehci-omap and address 16 usb 1-2.3: New USB device found, idVendor=08bb, idProduct=29b2 usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-2.3: Product: USB Audio CODEC usb 1-2.3: Manufacturer: Burr-Brown from TI usb 1-2.3: configuration #1 chosen from 1 choice input: Burr-Brown from TI USB Audio CODEC as /class/input/input3 generic-usb 0003:08BB:29B2.0002: input: USB HID v1.00 Device [Burr-Brown from TI USB Audio CODEC ] on usb-ehci-omap.0-2.3/input3 usb 1-2.4: new high speed USB device using ehci-omap and address 17 usb 1-2.4: New USB device found, idVendor=0424, idProduct=9500 usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-2.4: Product: LAN9500 usb 1-2.4: Manufacturer: SMSC usb 1-2.4: SerialNumber: 000950B41 usb 1-2.4: configuration #1 chosen from 1 choice smsc95xx v1.0.4 eth0 (smsc95xx): not using net_device_ops yet eth0: register 'smsc95xx' at usb-ehci-omap.0-2.4, smsc95xx USB 2.0 Ethernet, 00:80:0f:95:0b:41 hub 1-0:1.0: port 2 disabled by hub (EMI?), re-enabling... usb 1-2: USB disconnect, address 10 usb 1-2.1: USB disconnect, address 11 ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 ftdi_sio 1-2.1:1.0: device disconnected usb 1-2.3: USB disconnect, address 16 usb 1-2.4: USB disconnect, address 17 eth0: unregister 'smsc95xx' usb-ehci-omap.0-2.4, smsc95xx USB 2.0 Ethernet usb 1-2: new high speed USB device using ehci-omap and address 18 usb 1-2: New USB device found, idVendor=0409, idProduct=005a usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 1-2: configuration #1 chosen from 1 choice hub 1-2:1.0: USB hub found hub 1-2:1.0: 4 ports detected usb 1-2.1: new full speed USB device using ehci-omap and address 19 usb 1-2.1: New USB device found, idVendor=0403, idProduct=6001 usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-2.1: Product: USB <-> Serial usb 1-2.1: Manufacturer: FTDI usb 1-2.1: configuration #1 chosen from 1 choice ftdi_sio 1-2.1:1.0: FTDI USB Serial Device converter detected usb 1-2.1: Detected FT232BM usb 1-2.1: FTDI USB Serial Device converter now attached to ttyUSB0 usb 1-2.2: new full speed USB device using ehci-omap and address 20 usb 1-2.2: device descriptor read/64, error -32 usb 1-2.2: device descriptor read/64, error -32 usb 1-2.2: new full speed USB device using ehci-omap and address 21 usb 1-2.2: device descriptor read/64, error -32 usb 1-2.2: device descriptor read/64, error -32 Start recording Child process getpid: 1934 getppid: 1712 Parent running pid: 1934 getpid: 1712 Recording WAVE 'schAudio.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono usb 1-2.2: new full speed USB device using ehci-omap and address 22 usb 1-2.2: device not accepting address 22, error -32 usb 1-2.2: new full speed USB device using ehci-omap and address 23 usb 1-2.2: device not accepting address 23, error -32 hub 1-2:1.0: unable to enumerate USB device on port 2 usb 1-2.3: new full speed USB device using ehci-omap and address 24 usb 1-2.3: New USB device found, idVendor=08bb, idProduct=29b2 usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-2.3: Product: USB Audio CODEC usb 1-2.3: Manufacturer: Burr-Brown from TI usb 1-2.3: configuration #1 chosen from 1 choice input: Burr-Brown from TI USB Audio CODEC as /class/input/input4 generic-usb 0003:08BB:29B2.0003: input: USB HID v1.00 Device [Burr-Brown from TI USB Audio CODEC ] on usb-ehci-omap.0-2.3/input3 usb 1-2.4: new high speed USB device using ehci-omap and address 25 usb 1-2.4: New USB device found, idVendor=0424, idProduct=9500 usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-2.4: Product: LAN9500 usb 1-2.4: Manufacturer: SMSC usb 1-2.4: SerialNumber: 000950B41 usb 1-2.4: configuration #1 chosen from 1 choice smsc95xx v1.0.4 eth0 (smsc95xx): not using net_device_ops yet eth0: register 'smsc95xx' at usb-ehci-omap.0-2.4, smsc95xx USB 2.0 Ethernet, 00:80:0f:95:0b:41 eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 *********************************************************************** Tristan Henderson Software Engineer Geonautics International Pty Ltd 60 Morley Street, Coorparoo Queensland 4151 AUSTRALIA Web: http://www.geonautics.com Tel: + 61 7 33242555 Fax: + 61 7 33242566 Email link: Tristan Henderson's Email *********************************************************************** This message and any associated attachments may contain Privileged / Confidential Information and are intended solely for the named addressees. Distribution or copying of any part of this transmission by anyone other than the addressees is prohibited. If you have received this message in error please delete the message and destroy any printed copies. Views in this message are those of the individual sender. ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Tristan H. <Tri...@ge...> - 2009-07-09 00:29:07
|
Hi Jason, Thanks for the reply. I've checked and it appears all the boards we have (and I just found out we have purchased quite a few more than 10 of these) are fitted with ES2.1 OMAP chips. I guess I'll be chasing this up with Gumstix sales as it sounds like we aren't going to get anywhere unless we can get a hold of ES3.1. Does anyone know if any ES3.1 Overo boards have even been produced? - Cheers, Tristan *********************************************************************** Tristan Henderson Software Engineer Geonautics International Pty Ltd 60 Morley Street, Coorparoo Queensland 4151 AUSTRALIA Web: http://www.geonautics.com Tel: + 61 7 33242555 Fax: + 61 7 33242566 Email link: Tristan Henderson's Email *********************************************************************** This message and any associated attachments may contain Privileged / Confidential Information and are intended solely for the named addressees. Distribution or copying of any part of this transmission by anyone other than the addressees is prohibited. If you have received this message in error please delete the message and destroy any printed copies. Views in this message are those of the individual sender. |
From: Jason C. M. <jas...@am...> - 2009-07-09 07:24:23
|
One oddity that I discovered today that might, or might not have anything to do with it. That oddity is the Write speed of the USB Host to a USB flash drive. It took 17 seconds for a 4 megabyte file to transfer from an SD card to the USB flash drive. In this test I had a keyboard, and a usb flash drive connected to a powered hub, and the hub was connected to the host port. I confirmed the 17 seconds with both an Overo board, and a Beagleboard Rev C2. It also took around 17 seconds on the OTG port (on both boards). That's a ridiculously long time, and so something was obviously wrong. The read speed from USB to SD didn't take anywhere close to as long ( < 1 second or so). With a write speed of that who cares about USB disconnections? Its like worrying about a flat tire on a car without an engine. So then I decided to ONLY connect the USB flash drive to the Host port on the beagleboard, and I connected the HUB to the OTG port (with the keyboard into the hub). In that configuration it took < 1 second to transfer the 4 megabyte file to the USB flash drive. That doesn't rule out potential issues of the VBUS since it obviously changed (from the HUB to the external power supply powering the beagle). How long does transferring a 4MB file take on your overo with your hub? Is it really fast (down around a second or two), or some ridiculously long time? ________________________________________ From: Tristan Henderson [Tri...@ge...] Sent: Wednesday, July 08, 2009 5:16 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] Overo EHCI USB host port problems - resend Hi Jason, Thanks for the reply. I've checked and it appears all the boards we have (and I just found out we have purchased quite a few more than 10 of these) are fitted with ES2.1 OMAP chips. I guess I'll be chasing this up with Gumstix sales as it sounds like we aren't going to get anywhere unless we can get a hold of ES3.1. Does anyone know if any ES3.1 Overo boards have even been produced? - Cheers, Tristan *********************************************************************** Tristan Henderson Software Engineer Geonautics International Pty Ltd 60 Morley Street, Coorparoo Queensland 4151 AUSTRALIA Web: http://www.geonautics.com Tel: + 61 7 33242555 Fax: + 61 7 33242566 Email link: Tristan Henderson's Email *********************************************************************** This message and any associated attachments may contain Privileged / Confidential Information and are intended solely for the named addressees. Distribution or copying of any part of this transmission by anyone other than the addressees is prohibited. If you have received this message in error please delete the message and destroy any printed copies. Views in this message are those of the individual sender. ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Dave H. <dhy...@gm...> - 2009-07-09 14:50:31
|
Hi Jason, On Thu, Jul 9, 2009 at 12:24 AM, Jason C. Mecham<jas...@am...> wrote: > One oddity that I discovered today that might, or might not have anything to do with it. > > That oddity is the Write speed of the USB Host to a USB flash drive. > > It took 17 seconds for a 4 megabyte file to transfer from an SD card to the USB flash drive. In this test I had a keyboard, and a usb flash drive connected to a powered hub, and the hub was connected to the host port. I confirmed the 17 seconds with both an Overo board, and a Beagleboard Rev C2. It also took around 17 seconds on the OTG port (on both boards). > > That's a ridiculously long time, and so something was obviously wrong. The read speed from USB to SD didn't take anywhere close to as long ( < 1 second or so). Be careful with your measurements here. If you did the write followed by the read, then the read would have come from RAM and wouldn't have touched the USB device. If you did the read as the first operation after a reboot, then you'd really be measuring the read time. Linux will cache files using un-used RAM. You can observe this by looking at /proc/meminfo before copying the file and looking at it after copying the file. IIRC you'll see that the Cached amount increases by the 4Mb of your file. Since the entire file fits in the cache, subsequent reads will come directly from cache. If your USB flash card is mounted using the sync option, then each and every write will be flushed to the device (which makes writes take MUCH longer). Without the sync option, then writes will occur to the cache, and the cache will be lazily flushed out the device later. My point is, that obtaining performance numbers can be tricky. You generally need to copy files which are much larger than your system RAM size, or measure performance at the driver level, in order to get anything that might be considered accurate. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: Rod B. <rb...@st...> - 2009-07-09 15:33:43
|
I have just finished this sort of testing and evaluation I used the following test lines: The USB write command is: time dd if=/dev/zero of=/dev/sda1 count=4096 bs=64k The USB read command is: time dd if=/dev/sda1 of=/dev/null count=4096 bs=64k Note I was writing to the partitions which are not cached I also used a hard disk and not flash based disks (flash is soooooo slow dude). I got the following numbers: USB Read 182.4Mbps USB Write 197.6Mbps This enabled us to select gumstix for our needs. Regards, Rod Boyce -----Original Message----- From: Dave Hylands [mailto:dhy...@gm...] Sent: 09 July 2009 15:50 To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] Overo EHCI USB host port problems - resend Hi Jason, On Thu, Jul 9, 2009 at 12:24 AM, Jason C. Mecham<jas...@am...> wrote: > One oddity that I discovered today that might, or might not have anything to do with it. > > That oddity is the Write speed of the USB Host to a USB flash drive. > > It took 17 seconds for a 4 megabyte file to transfer from an SD card to the USB flash drive. In this test I had a keyboard, and a usb flash drive connected to a powered hub, and the hub was connected to the host port. I confirmed the 17 seconds with both an Overo board, and a Beagleboard Rev C2. It also took around 17 seconds on the OTG port (on both boards). > > That's a ridiculously long time, and so something was obviously wrong. The read speed from USB to SD didn't take anywhere close to as long ( < 1 second or so). Be careful with your measurements here. If you did the write followed by the read, then the read would have come from RAM and wouldn't have touched the USB device. If you did the read as the first operation after a reboot, then you'd really be measuring the read time. Linux will cache files using un-used RAM. You can observe this by looking at /proc/meminfo before copying the file and looking at it after copying the file. IIRC you'll see that the Cached amount increases by the 4Mb of your file. Since the entire file fits in the cache, subsequent reads will come directly from cache. If your USB flash card is mounted using the sync option, then each and every write will be flushed to the device (which makes writes take MUCH longer). Without the sync option, then writes will occur to the cache, and the cache will be lazily flushed out the device later. My point is, that obtaining performance numbers can be tricky. You generally need to copy files which are much larger than your system RAM size, or measure performance at the driver level, in order to get anything that might be considered accurate. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ ------------------------------------------------------------------------ ------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Jason C. M. <jas...@am...> - 2009-07-09 18:02:05
|
Flash is slow, but its what the end user will use. When I did that test it gave me USB Read 133.6Mbps USB Write 46.4Mbps Yet, at the same time it still takes 17 seconds to write a 4MB file to it (with the SYNC option). ________________________________________ From: Rod Boyce [rb...@st...] Sent: Thursday, July 09, 2009 8:11 AM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] Overo EHCI USB host port problems - resend I have just finished this sort of testing and evaluation I used the following test lines: The USB write command is: time dd if=/dev/zero of=/dev/sda1 count=4096 bs=64k The USB read command is: time dd if=/dev/sda1 of=/dev/null count=4096 bs=64k Note I was writing to the partitions which are not cached I also used a hard disk and not flash based disks (flash is soooooo slow dude). I got the following numbers: USB Read 182.4Mbps USB Write 197.6Mbps This enabled us to select gumstix for our needs. Regards, Rod Boyce -----Original Message----- From: Dave Hylands [mailto:dhy...@gm...] Sent: 09 July 2009 15:50 To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] Overo EHCI USB host port problems - resend Hi Jason, On Thu, Jul 9, 2009 at 12:24 AM, Jason C. Mecham<jas...@am...> wrote: > One oddity that I discovered today that might, or might not have anything to do with it. > > That oddity is the Write speed of the USB Host to a USB flash drive. > > It took 17 seconds for a 4 megabyte file to transfer from an SD card to the USB flash drive. In this test I had a keyboard, and a usb flash drive connected to a powered hub, and the hub was connected to the host port. I confirmed the 17 seconds with both an Overo board, and a Beagleboard Rev C2. It also took around 17 seconds on the OTG port (on both boards). > > That's a ridiculously long time, and so something was obviously wrong. The read speed from USB to SD didn't take anywhere close to as long ( < 1 second or so). Be careful with your measurements here. If you did the write followed by the read, then the read would have come from RAM and wouldn't have touched the USB device. If you did the read as the first operation after a reboot, then you'd really be measuring the read time. Linux will cache files using un-used RAM. You can observe this by looking at /proc/meminfo before copying the file and looking at it after copying the file. IIRC you'll see that the Cached amount increases by the 4Mb of your file. Since the entire file fits in the cache, subsequent reads will come directly from cache. If your USB flash card is mounted using the sync option, then each and every write will be flushed to the device (which makes writes take MUCH longer). Without the sync option, then writes will occur to the cache, and the cache will be lazily flushed out the device later. My point is, that obtaining performance numbers can be tricky. You generally need to copy files which are much larger than your system RAM size, or measure performance at the driver level, in order to get anything that might be considered accurate. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ ------------------------------------------------------------------------ ------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Rod B. <rb...@st...> - 2009-07-10 07:30:19
|
All, Also note that we were only interested in USB performance not how long it takes to write to a flash based device. Don't forget that when writing to flash based devices the that the write time will vary depending on the wear levelling algorithm used, what triggers garbage collection and how old the device is. Most companies regard these algorithms as secrets and will not disclose them. Regards, Rod Boyce -----Original Message----- From: Dave Hylands [mailto:dhy...@gm...] Sent: 10 July 2009 00:46 To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] Overo EHCI USB host port problems - resend Hi Jason, On Thu, Jul 9, 2009 at 11:01 AM, Jason C. Mecham<jas...@am...> wrote: > Flash is slow, but its what the end user will use. > > When I did that test it gave me > > USB Read 133.6Mbps > USB Write 46.4Mbps > > Yet, at the same time it still takes 17 seconds to write a 4MB file to it (with the SYNC option). And here we discover the fundamental difference between raw I/O and block size. The dd variant has no filesystem to worry about and it's using 64K blocks. When writing to a filesystem, you're probably using 512 byte blocks. The sync option is forcing every write to complete, not just at the end of the file. It is my experience, that there is a HUGE performance difference between block sizes. Even going through the filesystem, you'll probably get a huge performance improvement by writing your own program to copy the file 64K at a time and do a single sync at the end of the file rather than using the sync option on the mount. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ ------------------------------------------------------------------------ ------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: David V. <dvd...@gm...> - 2009-07-09 04:18:58
|
A lot of the disconnect problems, at least on Beagle and I assume on Overo have to do with the VBUS supply. USB 2.0 has very tight requirements on VBUS supply and D+/D- impedance for high speed operation. It is not a trivial hardware implention to get everything right. Probably some are software related but most of the silicon issues are obscure and have easy workarounds. I have tested the USB host operation on the Overo under Windows CE and have not seen any issues. There is feedback that will notify the OMAP when the USB sees an overcurrent or other conditions. I do not believe it is implemented in the Linux kernel yet. I could be wrong. |
From: Jason C. M. <jas...@am...> - 2009-07-09 16:53:35
|
I completely agree with you in terms of obtaining performance numbers, and watching out for cache issues. When I do obtain TRUE performance numbers I'll probably use the "time dd" command with a flash drive that is mounted with the sync command (the user needs to be able to unplug the drive without file corruption). The goal of my test wasn't that though. It was just seeing approximately how long it would take to write to a 4MB flash drive. I only cared about whether it was even close to something reasonable, and 17 seconds is NOT reasonable. ________________________________________ From: Dave Hylands [dhy...@gm...] Sent: Thursday, July 09, 2009 7:50 AM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] Overo EHCI USB host port problems - resend Hi Jason, On Thu, Jul 9, 2009 at 12:24 AM, Jason C. Mecham<jas...@am...> wrote: > One oddity that I discovered today that might, or might not have anything to do with it. > > That oddity is the Write speed of the USB Host to a USB flash drive. > > It took 17 seconds for a 4 megabyte file to transfer from an SD card to the USB flash drive. In this test I had a keyboard, and a usb flash drive connected to a powered hub, and the hub was connected to the host port. I confirmed the 17 seconds with both an Overo board, and a Beagleboard Rev C2. It also took around 17 seconds on the OTG port (on both boards). > > That's a ridiculously long time, and so something was obviously wrong. The read speed from USB to SD didn't take anywhere close to as long ( < 1 second or so). Be careful with your measurements here. If you did the write followed by the read, then the read would have come from RAM and wouldn't have touched the USB device. If you did the read as the first operation after a reboot, then you'd really be measuring the read time. Linux will cache files using un-used RAM. You can observe this by looking at /proc/meminfo before copying the file and looking at it after copying the file. IIRC you'll see that the Cached amount increases by the 4Mb of your file. Since the entire file fits in the cache, subsequent reads will come directly from cache. If your USB flash card is mounted using the sync option, then each and every write will be flushed to the device (which makes writes take MUCH longer). Without the sync option, then writes will occur to the cache, and the cache will be lazily flushed out the device later. My point is, that obtaining performance numbers can be tricky. You generally need to copy files which are much larger than your system RAM size, or measure performance at the driver level, in order to get anything that might be considered accurate. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Jason C. M. <jas...@am...> - 2009-07-09 17:07:48
|
"how long it would take to write to a 4MB flash drive." Err, I meant How long it would take to write a 4MB file to a fairly recent USB flash drive. ________________________________________ From: Jason C. Mecham [jas...@am...] Sent: Thursday, July 09, 2009 9:53 AM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] Overo EHCI USB host port problems - resend I completely agree with you in terms of obtaining performance numbers, and watching out for cache issues. When I do obtain TRUE performance numbers I'll probably use the "time dd" command with a flash drive that is mounted with the sync command (the user needs to be able to unplug the drive without file corruption). The goal of my test wasn't that though. It was just seeing approximately how long it would take to write to a 4MB flash drive. I only cared about whether it was even close to something reasonable, and 17 seconds is NOT reasonable. ________________________________________ From: Dave Hylands [dhy...@gm...] Sent: Thursday, July 09, 2009 7:50 AM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] Overo EHCI USB host port problems - resend Hi Jason, On Thu, Jul 9, 2009 at 12:24 AM, Jason C. Mecham<jas...@am...> wrote: > One oddity that I discovered today that might, or might not have anything to do with it. > > That oddity is the Write speed of the USB Host to a USB flash drive. > > It took 17 seconds for a 4 megabyte file to transfer from an SD card to the USB flash drive. In this test I had a keyboard, and a usb flash drive connected to a powered hub, and the hub was connected to the host port. I confirmed the 17 seconds with both an Overo board, and a Beagleboard Rev C2. It also took around 17 seconds on the OTG port (on both boards). > > That's a ridiculously long time, and so something was obviously wrong. The read speed from USB to SD didn't take anywhere close to as long ( < 1 second or so). Be careful with your measurements here. If you did the write followed by the read, then the read would have come from RAM and wouldn't have touched the USB device. If you did the read as the first operation after a reboot, then you'd really be measuring the read time. Linux will cache files using un-used RAM. You can observe this by looking at /proc/meminfo before copying the file and looking at it after copying the file. IIRC you'll see that the Cached amount increases by the 4Mb of your file. Since the entire file fits in the cache, subsequent reads will come directly from cache. If your USB flash card is mounted using the sync option, then each and every write will be flushed to the device (which makes writes take MUCH longer). Without the sync option, then writes will occur to the cache, and the cache will be lazily flushed out the device later. My point is, that obtaining performance numbers can be tricky. You generally need to copy files which are much larger than your system RAM size, or measure performance at the driver level, in order to get anything that might be considered accurate. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Jason C. M. <jas...@am...> - 2009-07-09 18:16:33
|
Update - My finding were wrong. There is no difference in write speed using the HUB or not using the HUB. I always get around 17 seconds when I make sure the USB flash drive is mounted with the sync option. Somehow it must have mounted without the sync option when I got the <1 second result. ________________________________________ From: Jason C. Mecham [jas...@am...] Sent: Thursday, July 09, 2009 12:24 AM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] Overo EHCI USB host port problems - resend One oddity that I discovered today that might, or might not have anything to do with it. That oddity is the Write speed of the USB Host to a USB flash drive. It took 17 seconds for a 4 megabyte file to transfer from an SD card to the USB flash drive. In this test I had a keyboard, and a usb flash drive connected to a powered hub, and the hub was connected to the host port. I confirmed the 17 seconds with both an Overo board, and a Beagleboard Rev C2. It also took around 17 seconds on the OTG port (on both boards). That's a ridiculously long time, and so something was obviously wrong. The read speed from USB to SD didn't take anywhere close to as long ( < 1 second or so). With a write speed of that who cares about USB disconnections? Its like worrying about a flat tire on a car without an engine. So then I decided to ONLY connect the USB flash drive to the Host port on the beagleboard, and I connected the HUB to the OTG port (with the keyboard into the hub). In that configuration it took < 1 second to transfer the 4 megabyte file to the USB flash drive. That doesn't rule out potential issues of the VBUS since it obviously changed (from the HUB to the external power supply powering the beagle). How long does transferring a 4MB file take on your overo with your hub? Is it really fast (down around a second or two), or some ridiculously long time? ________________________________________ From: Tristan Henderson [Tri...@ge...] Sent: Wednesday, July 08, 2009 5:16 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] Overo EHCI USB host port problems - resend Hi Jason, Thanks for the reply. I've checked and it appears all the boards we have (and I just found out we have purchased quite a few more than 10 of these) are fitted with ES2.1 OMAP chips. I guess I'll be chasing this up with Gumstix sales as it sounds like we aren't going to get anywhere unless we can get a hold of ES3.1. Does anyone know if any ES3.1 Overo boards have even been produced? - Cheers, Tristan *********************************************************************** Tristan Henderson Software Engineer Geonautics International Pty Ltd 60 Morley Street, Coorparoo Queensland 4151 AUSTRALIA Web: http://www.geonautics.com Tel: + 61 7 33242555 Fax: + 61 7 33242566 Email link: Tristan Henderson's Email *********************************************************************** This message and any associated attachments may contain Privileged / Confidential Information and are intended solely for the named addressees. Distribution or copying of any part of this transmission by anyone other than the addressees is prohibited. If you have received this message in error please delete the message and destroy any printed copies. Views in this message are those of the individual sender. ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Tristan H. <Tri...@ge...> - 2009-07-12 23:51:27
|
We haven't had any serious reliability issues when using bulk transfers off storage devices. The host port crashes very rarely under these circumstances (I've only seen it once or twice). The port seems to crash very frequently when carrying out isochronous transfers (i.e. recording from a USB sound card). I've tried more than one sound card and many hub and power supply configurations (built up a linear supply to eliminate switching noise just to see). The behaviour is consistent across different connected hardware. Over the weekend I've also tried some new USB cables but the issue still persists. Even if the frequency of the crash was reduced to once of twice a day we could work around the problem but at the moment it is occurring far to often (several times per hour) for us to design a reliable system. - Cheers, Tristan *********************************************************************** Tristan Henderson Software Engineer Geonautics International Pty Ltd 60 Morley Street, Coorparoo Queensland 4151 AUSTRALIA Web: http://www.geonautics.com Tel: + 61 7 33242555 Fax: + 61 7 33242566 Email link: Tristan Henderson's Email *********************************************************************** This message and any associated attachments may contain Privileged / Confidential Information and are intended solely for the named addressees. Distribution or copying of any part of this transmission by anyone other than the addressees is prohibited. If you have received this message in error please delete the message and destroy any printed copies. Views in this message are those of the individual sender. -----Original Message----- From: Jason C. Mecham [mailto:jas...@am...] Sent: Friday, 10 July 2009 4:12 AM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] Overo EHCI USB host port problems - resend Update - My finding were wrong. There is no difference in write speed using the HUB or not using the HUB. I always get around 17 seconds when I make sure the USB flash drive is mounted with the sync option. Somehow it must have mounted without the sync option when I got the <1 second result. ________________________________________ From: Jason C. Mecham [jas...@am...] Sent: Thursday, July 09, 2009 12:24 AM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] Overo EHCI USB host port problems - resend One oddity that I discovered today that might, or might not have anything to do with it. That oddity is the Write speed of the USB Host to a USB flash drive. It took 17 seconds for a 4 megabyte file to transfer from an SD card to the USB flash drive. In this test I had a keyboard, and a usb flash drive connected to a powered hub, and the hub was connected to the host port. I confirmed the 17 seconds with both an Overo board, and a Beagleboard Rev C2. It also took around 17 seconds on the OTG port (on both boards). That's a ridiculously long time, and so something was obviously wrong. The read speed from USB to SD didn't take anywhere close to as long ( < 1 second or so). With a write speed of that who cares about USB disconnections? Its like worrying about a flat tire on a car without an engine. So then I decided to ONLY connect the USB flash drive to the Host port on the beagleboard, and I connected the HUB to the OTG port (with the keyboard into the hub). In that configuration it took < 1 second to transfer the 4 megabyte file to the USB flash drive. That doesn't rule out potential issues of the VBUS since it obviously changed (from the HUB to the external power supply powering the beagle). How long does transferring a 4MB file take on your overo with your hub? Is it really fast (down around a second or two), or some ridiculously long time? ________________________________________ From: Tristan Henderson [Tri...@ge...] Sent: Wednesday, July 08, 2009 5:16 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] Overo EHCI USB host port problems - resend Hi Jason, Thanks for the reply. I've checked and it appears all the boards we have (and I just found out we have purchased quite a few more than 10 of these) are fitted with ES2.1 OMAP chips. I guess I'll be chasing this up with Gumstix sales as it sounds like we aren't going to get anywhere unless we can get a hold of ES3.1. Does anyone know if any ES3.1 Overo boards have even been produced? - Cheers, Tristan *********************************************************************** Tristan Henderson Software Engineer Geonautics International Pty Ltd 60 Morley Street, Coorparoo Queensland 4151 AUSTRALIA Web: http://www.geonautics.com Tel: + 61 7 33242555 Fax: + 61 7 33242566 Email link: Tristan Henderson's Email *********************************************************************** This message and any associated attachments may contain Privileged / Confidential Information and are intended solely for the named addressees. Distribution or copying of any part of this transmission by anyone other than the addressees is prohibited. If you have received this message in error please delete the message and destroy any printed copies. Views in this message are those of the individual sender. ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Dave H. <dhy...@gm...> - 2009-07-09 23:46:23
|
Hi Jason, On Thu, Jul 9, 2009 at 11:01 AM, Jason C. Mecham<jas...@am...> wrote: > Flash is slow, but its what the end user will use. > > When I did that test it gave me > > USB Read 133.6Mbps > USB Write 46.4Mbps > > Yet, at the same time it still takes 17 seconds to write a 4MB file to it (with the SYNC option). And here we discover the fundamental difference between raw I/O and block size. The dd variant has no filesystem to worry about and it's using 64K blocks. When writing to a filesystem, you're probably using 512 byte blocks. The sync option is forcing every write to complete, not just at the end of the file. It is my experience, that there is a HUGE performance difference between block sizes. Even going through the filesystem, you'll probably get a huge performance improvement by writing your own program to copy the file 64K at a time and do a single sync at the end of the file rather than using the sync option on the mount. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: Jason C. M. <jas...@am...> - 2009-07-10 00:14:31
|
Thanks. That's exactly what I'll wind up doing. Still I didn't expect there to be that much of a difference between raw I/O, and the filesystem. I know FAT has a lot of overhead, but I assumed the VFAT was cache'ing the FAT sectors, and waiting till the end to write it. I did do time dd if=/dev/zero of=test123 count=64 bs=64k That took 14 seconds when being run on the USB flash drive (with sync enabled on the mount) Increasing the block size does help (bs=512 with count=8000 in the above example took 54 seconds), but sync'ing just KILLS it. As you said its much faster to just sync at the end, and not mount the volume with the sync option. ________________________________________ From: Dave Hylands [dhy...@gm...] Sent: Thursday, July 09, 2009 4:46 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] Overo EHCI USB host port problems - resend Hi Jason, On Thu, Jul 9, 2009 at 11:01 AM, Jason C. Mecham<jas...@am...> wrote: > Flash is slow, but its what the end user will use. > > When I did that test it gave me > > USB Read 133.6Mbps > USB Write 46.4Mbps > > Yet, at the same time it still takes 17 seconds to write a 4MB file to it (with the SYNC option). And here we discover the fundamental difference between raw I/O and block size. The dd variant has no filesystem to worry about and it's using 64K blocks. When writing to a filesystem, you're probably using 512 byte blocks. The sync option is forcing every write to complete, not just at the end of the file. It is my experience, that there is a HUGE performance difference between block sizes. Even going through the filesystem, you'll probably get a huge performance improvement by writing your own program to copy the file 64K at a time and do a single sync at the end of the file rather than using the sync option on the mount. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: David V. <dvd...@gm...> - 2009-07-10 11:21:16
|
Rod and Dave Bring up some excellent points. Be carefull how you are measuring transfering fome SD card to flash is not so good as SD read performance can very based on mode (1bit vs 4bit0 and several other factors). Also stated, caching and write algorithm makes a difference. Caching probably has the biggest influence as write performance on newer big drives is pretty good. Like on a PC where you have write-through vs write-back caching. Most removable drives are configured as write-through for safety. Write-through is much slower (flush operation has to complete) but because most people do not unmount (eject) the drive before yanking it out it is better. You can configure for write-back an get much faster (precieved) operation but stand to get a corrupted file system if removed before flash write operation completes. DV |