USB Storage Slow?

[DonC52]

I have been wondering why the following occurs on my Windows 10 laptop and the Pi USB. I am using a 128G SanDisk Extreme Plus UHS so I would think it rather fast.

I put in an old "slow" USB stick into my Laptop port and copy a Sentry Mode directory, I get about 20MB/Sec transfer rate.

I put the Pi USB in with power applied from external source and copy the same directory, I get like 1.5MB/s to 2.5MB/s transfer rate.

Looking at top, there is a LOT of wait time going on. Is there anything that can be done to speed things up?

[marcone]

The time you circled in that screenshot is I/O wait time, i.e. time spent waiting for data to be read from the sd card, and time spent transferring data over USB, both of which probably happen via DMA, thus the CPU will be mostly idle during those times.

As to why you get such low transfer rates, no idea. How are you measuring that? I'm getting around 20 MB/sec on both read and write with 'dd' when attached to a Mac or linux machine.

[marcone]

Does dmesg on the Pi show "dwc2 20980000.usb: new device is high-speed" or something else?

[DonC52]

I got the following from dmesg | grep "dwc2 20980000.usb" while connected to the car. It looks like the last timestamps show it as high-speed.
''' root@teslausb: dmesg | grep "dwc2 20980000.usb" [ 3.136821] dwc2 20980000.usb: 20980000.usb supply vusb_d not found, using dummy regulator [ 3.137004] dwc2 20980000.usb: Linked as a consumer to regulator.0 [ 3.137033] dwc2 20980000.usb: 20980000.usb supply vusb_a not found, using dummy regulator [ 3.353750] dwc2 20980000.usb: dwc2_check_params: Invalid parameter lpm=1 [ 3.353775] dwc2 20980000.usb: dwc2_check_params: Invalid parameter lpm_clock_gating=1 [ 3.353789] dwc2 20980000.usb: dwc2_check_params: Invalid parameter besl=1 [ 3.353800] dwc2 20980000.usb: dwc2_check_params: Invalid parameter hird_threshold_en=1 [ 3.353866] dwc2 20980000.usb: EPs: 8, dedicated fifos, 4080 entries in SPRAM [ 3.355146] dwc2 20980000.usb: DWC OTG Controller [ 3.355220] dwc2 20980000.usb: new USB bus registered, assigned bus number 1 [ 3.355301] dwc2 20980000.usb: irq 33, io mem 0x20980000 [ 93.619677] dwc2 20980000.usb: bound driver g_mass_storage [ 93.641717] dwc2 20980000.usb: new device is high-speed [ 94.006578] dwc2 20980000.usb: new device is high-speed [ 94.248037] dwc2 20980000.usb: new address 13 [ 756.636039] dwc2 20980000.usb: bound driver g_mass_storage [ 756.762610] dwc2 20980000.usb: new device is high-speed [ 756.836337] dwc2 20980000.usb: new device is high-speed [ 756.897926] dwc2 20980000.usb: new address 14 root@teslausb:~# '''

I test out new things by copying a test event to the Pi USB TeslaCam/SavedClips so it can transfer something without driving the car. I only has like 15 files in it and takes like 6 minutes to copy the file. I use the display that Windows shows when copying a file (details) and it is usually close to whats going on as far as speed. (Thus the 20MB/S to a regular "old" stick

Tomorrow evening I can take out the Pi from the car and plug it into my Laptop. Then take a look at what dmesg has to say.

Sound like a plan?

[DonC52]

Well another day - I first plugged the Pi into power from the wall and let it boot all the way up. I then connected it to he USB port on the computer. Doing a copy of the test file again is like 1.5MB/s rather than the 20 expected. Still a lot of wait going on.

Looking at the windows device manager, I noticed that the Pi is seen as a Linux File-Stor Gadget USB Device. I am wondering if there is an issue with that driver in Windows? When I READ from the Pi TeslaCam/SavedClips I get a flat 20MB/s. When WRITING to the Pi folder, I get between 1.5 - .5MB/s.

Anyone else plug the Pi into a Windows 10 machine and try to write to the TeslaCam folder? Here is the dmesg output: ''' pi@teslausb:~ $ dmesg | grep "dwc2 20980000.usb" [ 3.281850] dwc2 20980000.usb: 20980000.usb supply vusb_d not found, using dummy regulator [ 3.282043] dwc2 20980000.usb: Linked as a consumer to regulator.0 [ 3.282074] dwc2 20980000.usb: 20980000.usb supply vusb_a not found, using dummy regulator [ 3.503745] dwc2 20980000.usb: dwc2_check_params: Invalid parameter lpm=1 [ 3.503770] dwc2 20980000.usb: dwc2_check_params: Invalid parameter lpm_clock_gating=1 [ 3.503783] dwc2 20980000.usb: dwc2_check_params: Invalid parameter besl=1 [ 3.503795] dwc2 20980000.usb: dwc2_check_params: Invalid parameter hird_threshold_en=1 [ 3.503863] dwc2 20980000.usb: EPs: 8, dedicated fifos, 4080 entries in SPRAM [ 3.505247] dwc2 20980000.usb: DWC OTG Controller [ 3.505316] dwc2 20980000.usb: new USB bus registered, assigned bus number 1 [ 3.505401] dwc2 20980000.usb: irq 33, io mem 0x20980000 [ 92.034137] dwc2 20980000.usb: bound driver g_mass_storage [ 344.999742] dwc2 20980000.usb: new device is high-speed [ 345.052498] dwc2 20980000.usb: new address 2 pi@teslausb:~ $ '''

[DonC52]

Okay - after I sent the last Commment, things changed. Now when WRITING to the Pi I get 120MB/s for a few seconds and then 19.5-20.8MB/s. I have no idea what changed to get the write times better. READING back gives me 20.0-27.7MB/s.

I don't know if I taught the Windows driver something or just what is going on. Much better though.

Still - has any Windows 10 people out there playing around and noticed the same thing?

[DonC52]

Think I have a handle on the speed issue but I need sleep. Will follow-up tomorrow after work.

[curiousgrge]

Okay - after I sent the last Commment, things changed. Now when WRITING to the Pi I get 120MB/s for a few seconds and then 19.5-20.8MB/s. I have no idea what changed to get the write times better. READING back gives me 20.0-27.7MB/s.

I don't know if I taught the Windows driver something or just what is going on. Much better though.

Still - has any Windows 10 people out there playing around and noticed the same thing?

I'm having the exact same problems as you. 1.5-2.5MB/sec. If you have a handle on what you've changed for direct copying, I'm interested in how this is resolved. Took me 2.5+hrs to copy my MUSIC partition back. Even to get 20MB/sec would be dramatic improvement in copy time. For the data connection, I'm connected via USB 3.0. Possibly my issue is my USB cable now that I think about it since it is a thin flat cable that came with my Smart Watch.

[marcone]

You could try adding nofua=1,1 to /etc/modprobe.d/g_mass_storage.conf and see if that helps. (see https://www.kernel.org/doc/Documentation/usb/mass-storage.txt for details)

[curiousgrge]

Just tried the adding nofua=1,1 to the tail end of the conf file and now it is 4-5MB/sec but well shy of 20MB/sec.

[DonC52]

I "Think" I found the solution. Windows 10 tends to want writes to complete before issuing more writes. (NO write caching!) To speed this up, I went into Device Manager, selected Disk Drives and you will see the Linux File-Stor Gadget USB Device. (two of them) Select the policies tab and select Better performance. The write-caching check box will be selected but DO NOT turn on the flushing check-box. (Very bad idea) Do this for BOTH of the devices.

Doing this simple change enabled me to copy 200 music files (about 797MB) in about 30 seconds or so. From the 4-5MB/s it went to about 150MB/s with a short time delay at the end for the system to flush the cache.

Hopefully it will help you as well.

[curiousgrge]

Redoing my TeslaUSB again due to it now not giving me notifications. Tested @DocC52 suggestion and it is at least 3x faster than what it was doing again. After the initial caching, it does slow down quite a bit. Takes about 30 minutes now to copy everything for me rather than 2.5hrs so I guess it improves it 5x.

I didn't test this with the nofua=1,1 so don't know if that makes a difference too.

Also keep in mind if you do this that user will need to eject the drive rather than just being able to pull out. Not sure why the image was unlucky and says 3MB/sec when it was mostly hovering around 15MB/sec or higher.

[ZeFrenchBibster]

Hi,

Not sure if this is related, but I have the same sort of micro SD (128GB Sandisk 'claims' 100 MB/sec) in my pi (Zero-W) behind a 'Zendure 5' powerbanck/HUB.

Once the car wakes up, it works, but after a while, she claims that the USB storage is too slow. I'll fetch it from the car tonight, and try the 'nofua=1,1' thing, as well as any messages for /var/log/messages.

[githubsean]

Sorry, no solutions, just adding a data point.

I'm also having troubles with this, and I wonder if it is some bottleneck somewhere in the raspberry pi. I tested a card on both windows and linux computers - i.e. I plugged the raspberry pi acting as a USB drive into both computers and ran some write speed tests. They both came out to about 2MB/sec. I then took the card out of the pi and tried writing directly to it - about 18MB/sec. I haven't done any more investigation to see if it is:

• on the pi, the raw write speed on the pi to the USB (i.e. slow USB interface)
• on the pi, the write speed to the file system file used as the USB storage (some issue with the file system driver) I have tried the nofua=1,1 thing and I didn't see any significant difference in write speed.

I may try the new "Buster" version to see if things improve.

[mcowger]

I've enabled nofua on my 0W - will see how it goes today.

[mcowger]

I did some quick tests just now. This is a High Endurance SanDisk U3, Class10, V30 card I'd tested well over 25MB/sec writes (its rated for 40). nofua didn't seem to help much.

• Using the Pi0W attached to my Mac as a USB drive, I started a streaming write with 4KB blocks to the drive.
• Initially it was around 20MB/sec, but very quickly (after about 60s) dropped off to less than 1MB/sec, which makes sense that the car would be unhappy with.
• Then I tried it directly on the Pi, mounting the card through to g_mass_storage driver as /mnt/cam. Speeds were inconsistent, but often dipping below 2MB/sec, and then back up to 6.

My views:

1. Given the initial performance of 20MB/sec, I dont think its the RPi USB interface.
2. Given the initial performance and then drop, this feels like overrunning a cache somewhere, and then dropping straight to disk-performance.
3. Given the poor performance when loopback mounted with g_mass_storage, my gut suggests this is a performance problem in the kernel driver or just the RPi0W in general.

Next steps - I'm considering grabbing one of my faster ODroidC2's to see if its a CPU performance issue.

[mcowger]

Update - couldn't quite get my RPi3b+ to work.

[marcone]

Update - couldn't quite get my RPi3b+ to work.

Only the Pi0 and Pi4 support USB gadget mode.

[mcowger]

Well that would explain it :)

I'll pick up a RPi4 and play.

On Mon, Sep 30, 2019 at 4:47 PM marcone notifications@github.com wrote:

Update - couldn't quite get my RPi3b+ to work.

Only the Pi0 and Pi4 support USB gadget mode.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/marcone/teslausb/issues/239?email_source=notifications&email_token=AAOXCTHJQAOOI7YYKH2AJ3DQMKFYFA5CNFSM4IUEPZCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD77OCBA#issuecomment-536797444, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOXCTCBPCBLWPEGGLPFMMLQMKFYFANCNFSM4IUEPZCA .

-- -- Matt

[gacevedo]

I'll try the nofua=1,1 setting next. Here's the output from dmesg:

_root@teslausb:~# dmesg | grep 'dwc2 20980000.usb' [ 2.974130] dwc2 20980000.usb: 20980000.usb supply vusb_d not found, using dummy regulator [ 2.974288] dwc2 20980000.usb: Linked as a consumer to regulator.0 [ 2.974317] dwc2 20980000.usb: 20980000.usb supply vusb_a not found, using dummy regulator [ 3.194131] dwc2 20980000.usb: dwc2_check_params: Invalid parameter lpm=1 [ 3.194158] dwc2 20980000.usb: dwc2_check_params: Invalid parameter lpm_clock_gating=1 [ 3.194171] dwc2 20980000.usb: dwc2_check_params: Invalid parameter besl=1 [ 3.194183] dwc2 20980000.usb: dwc2_check_params: Invalid parameter hird_threshold_en=1 [ 3.194250] dwc2 20980000.usb: EPs: 8, dedicated fifos, 4080 entries in SPRAM [ 3.195656] dwc2 20980000.usb: DWC OTG Controller [ 3.195726] dwc2 20980000.usb: new USB bus registered, assigned bus number 1 [ 3.195811] dwc2 20980000.usb: irq 33, io mem 0x20980000 [ 1845.177686] dwc2 20980000.usb: bound driver g_massstorage [ 1845.434266] dwc2 20980000.usb: new device is high-speed [ 1845.490515] dwc2 20980000.usb: new device is high-speed [ 1845.545863] dwc2 20980000.usb: new device is high-speed [ 1845.601519] dwc2 20980000.usb: new device is high-speed [ 1845.656760] dwc2 20980000.usb: new device is high-speed [ 1845.712490] dwc2 20980000.usb: new device is high-speed [ 1845.768239] dwc2 20980000.usb: new device is high-speed [ 1845.823636] dwc2 20980000.usb: new device is high-speed [ 1845.878855] dwc2 20980000.usb: new device is high-speed [ 1845.970411] dwc2 20980000.usb: new address 10

[itsrainingben]

Apologies no solutions on my side either, just throwing my hat into this issue. Was not something I ran into prior to V10 & updating the pi following instructions here.

I mounted the rPi (stem enclosure if that matters) to a macOS host and tested read/write with Aja System Test Lite and saw between 17-19MB/s write. The software would error out after writing about 1GB. New to dmesg, so I tailed it and this is what I was able to pull -

disk3s1: I/O error. disk3s1: I/O error. **** [IOBluetoothDevice][decrementNumberOfOutstandingPacketsBy] -- Handle 0x000c -- remove ACL Timer 0xffffff8069112d20 for ACL packet 0xffffff806d2bb40 0 -- numOutstandingHWPackets = 1, mNumNotDequeuedAckedPackets = 0, mDestroyDeviceCalled = FALSE -- hostController = 0x1080 ****

**** [IOBluetoothDevice][decrementNumberOfOutstandingPacketsBy] -- Handle 0x000c -- remove ACL Timer 0xffffff8069113e60 for ACL packet 0xffffff806d1c6c0 0 -- numOutstandingHWPackets = 1, mNumNotDequeuedAckedPackets = 0, mDestroyDeviceCalled = FALSE -- hostController = 0x1080 **** disk3s1: I/O error. disk3s1: I/O error. disk3s1: I/O error. **** [IOBluetoothDevice][decrementNumberOfOutstandingPacketsBy] -- Handle 0x000c -- remove ACL Timer 0xffffff8057255900 for ACL packet 0xffffff806d15520 0 -- numOutstandingHWPackets = 1, mNumNotDequeuedAckedPackets = 0, mDestroyDeviceCalled = FALSE -- hostController = 0x1080 ****

If there are any recommended commands for dmesg feel free to throw them here and I'm happy to run. Otherwise I'll be following closely and thank you @marcone for all your work on this project.

[mcowger]

@marcone @gacevedo - Got my RPi4 today and installed the latest buster based release on it.

Native card write performance: 58MB/sec Thru RPI as USB (like the car would): 20.1MB/sec

This is vastly faster. Also, I watched the power consumption using an inline meter - even with default settings, the RPi4 maxed at a momentary 4.2W draw during install, and after settling down during normal running conditions draws about 2.9W....well within the power delivery available on at least the Model 3.

I've got it running in the car right now and will report back.

[DMBlakeley]

Curious what RAM size of RPi4 people are using?

[mcowger]

Mine is 1GB (which is 2x that of the RPi0W), the smallest. memory usage on the device shows 65MB.

[DMBlakeley]

Thanks! Didn’t want to go overboard.

[itsrainingben]

Hey Mat - 20MB/s is what I was get on the zeroW over USB (like the car does).

On Oct 1, 2019, at 5:24 PM, Matt Cowger notifications@github.com wrote:

 @marcone @gacevedo - Got my RPi4 today and installed the latest buster based release on it.

Native card write performance: 58MB/sec Thru RPI as USB (like the car would): 20.1MB/sec

This is vastly faster. Also, I watched the power consumption using an inline meter - even with default settings, the RPi4 maxed at a momentary 4.2W draw during install, and after settling down during normal running conditions draws about 2.9W....well within the power delivery available on at least the Model 3.

I've got it running in the car right now and will report back.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[mcowger]

I got 20mb/s at first l, then it throttled down to like 2. This is sustained.

On Tue, Oct 1, 2019 at 5:59 PM Ben Tucker notifications@github.com wrote:

Hey Mat - 20MB/s is what I was get on the zeroW over USB (like the car does).

On Oct 1, 2019, at 5:24 PM, Matt Cowger notifications@github.com wrote:

 @marcone @gacevedo - Got my RPi4 today and installed the latest buster based release on it.

Native card write performance: 58MB/sec Thru RPI as USB (like the car would): 20.1MB/sec

This is vastly faster. Also, I watched the power consumption using an inline meter - even with default settings, the RPi4 maxed at a momentary 4.2W draw during install, and after settling down during normal running conditions draws about 2.9W....well within the power delivery available on at least the Model 3.

I've got it running in the car right now and will report back.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/marcone/teslausb/issues/239?email_source=notifications&email_token=AAOXCTDLWYE4KPJKSQ3BGBDQMPW7JA5CNFSM4IUEPZCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEADGSMA#issuecomment-537291056, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOXCTBU77GYF2YOVVA46MTQMPW7JANCNFSM4IUEPZCA .

-- -- Matt

[itsrainingben]

How long does that write speed sustain for? Mine errors out after a minute (roughly 1GB written to disk).

On Tue, Oct 1, 2019 at 6:03 PM Matt Cowger notifications@github.com wrote:

I got 20mb/s at first l, then it throttled down to like 2. This is sustained.

On Tue, Oct 1, 2019 at 5:59 PM Ben Tucker notifications@github.com wrote:

Hey Mat - 20MB/s is what I was get on the zeroW over USB (like the car does).

On Oct 1, 2019, at 5:24 PM, Matt Cowger notifications@github.com wrote:

 @marcone @gacevedo - Got my RPi4 today and installed the latest buster based release on it.

Native card write performance: 58MB/sec Thru RPI as USB (like the car would): 20.1MB/sec

This is vastly faster. Also, I watched the power consumption using an inline meter - even with default settings, the RPi4 maxed at a momentary 4.2W draw during install, and after settling down during normal running conditions draws about 2.9W....well within the power delivery available on at least the Model 3.

I've got it running in the car right now and will report back.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/marcone/teslausb/issues/239?email_source=notifications&email_token=AAOXCTDLWYE4KPJKSQ3BGBDQMPW7JA5CNFSM4IUEPZCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEADGSMA#issuecomment-537291056 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AAOXCTBU77GYF2YOVVA46MTQMPW7JANCNFSM4IUEPZCA

.

-- -- Matt

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/marcone/teslausb/issues/239?email_source=notifications&email_token=AGE3NGRHSRMFX3T2FUPJYQ3QMPXMTA5CNFSM4IUEPZCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEADGYAI#issuecomment-537291777, or mute the thread https://github.com/notifications/unsubscribe-auth/AGE3NGVQPYNFJTEBCMYCRTDQMPXMTANCNFSM4IUEPZCA .

[mcowger]

On rpi0w it’s about the same.

On my 4 I sustained it for as long as I tested (5ish mins).

On Tue, Oct 1, 2019 at 6:10 PM Ben Tucker notifications@github.com wrote:

How long does that write speed sustain for? Mine errors out after a minute (roughly 1GB written to disk).

On Tue, Oct 1, 2019 at 6:03 PM Matt Cowger notifications@github.com wrote:

I got 20mb/s at first l, then it throttled down to like 2. This is sustained.

On Tue, Oct 1, 2019 at 5:59 PM Ben Tucker notifications@github.com wrote:

Hey Mat - 20MB/s is what I was get on the zeroW over USB (like the car does).

On Oct 1, 2019, at 5:24 PM, Matt Cowger notifications@github.com wrote:

 @marcone @gacevedo - Got my RPi4 today and installed the latest buster based release on it.

Native card write performance: 58MB/sec Thru RPI as USB (like the car would): 20.1MB/sec

This is vastly faster. Also, I watched the power consumption using an inline meter - even with default settings, the RPi4 maxed at a momentary 4.2W draw during install, and after settling down during normal running conditions draws about 2.9W....well within the power delivery available on at least the Model 3.

I've got it running in the car right now and will report back.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/marcone/teslausb/issues/239?email_source=notifications&email_token=AAOXCTDLWYE4KPJKSQ3BGBDQMPW7JA5CNFSM4IUEPZCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEADGSMA#issuecomment-537291056

, or mute the thread <

https://github.com/notifications/unsubscribe-auth/AAOXCTBU77GYF2YOVVA46MTQMPW7JANCNFSM4IUEPZCA

.

-- -- Matt

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/marcone/teslausb/issues/239?email_source=notifications&email_token=AGE3NGRHSRMFX3T2FUPJYQ3QMPXMTA5CNFSM4IUEPZCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEADGYAI#issuecomment-537291777 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AGE3NGVQPYNFJTEBCMYCRTDQMPXMTANCNFSM4IUEPZCA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/marcone/teslausb/issues/239?email_source=notifications&email_token=AAOXCTACWGY5435PBVBX44DQMPYIVA5CNFSM4IUEPZCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEADHC6Q#issuecomment-537293178, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOXCTCZPMP36KRHWDJZADDQMPYIVANCNFSM4IUEPZCA .

-- -- Matt

[itsrainingben]

Just got home, able to add my dmesg for @marcone 's request -

_root@teslapi:/home/pi# dmesg | grep "dwc2 20980000.usb" [ 3.426141] dwc2 20980000.usb: 20980000.usb supply vusb_d not found, using dummy regulator [ 3.426308] dwc2 20980000.usb: Linked as a consumer to regulator.0 [ 3.426337] dwc2 20980000.usb: 20980000.usb supply vusb_a not found, using dummy regulator [ 3.643940] dwc2 20980000.usb: dwc2_check_params: Invalid parameter lpm=1 [ 3.643965] dwc2 20980000.usb: dwc2_check_params: Invalid parameter lpm_clock_gating=1 [ 3.643980] dwc2 20980000.usb: dwc2_check_params: Invalid parameter besl=1 [ 3.643993] dwc2 20980000.usb: dwc2_check_params: Invalid parameter hird_threshold_en=1 [ 3.644061] dwc2 20980000.usb: EPs: 8, dedicated fifos, 4080 entries in SPRAM [ 3.645655] dwc2 20980000.usb: DWC OTG Controller [ 3.645765] dwc2 20980000.usb: new USB bus registered, assigned bus number 1 [ 3.645850] dwc2 20980000.usb: irq 33, io mem 0x20980000 [ 74.977688] dwc2 20980000.usb: bound driver g_mass_storage [ 75.001183] dwc2 20980000.usb: new device is high-speed [ 75.365197] dwc2 20980000.usb: new device is high-speed [ 75.617993] dwc2 20980000.usb: new device is high-speed [ 75.682544] dwc2 20980000.usb: new address 10 [ 1057.171063] dwc2 20980000.usb: bound driver g_massstorage [ 1057.314384] dwc2 20980000.usb: new device is high-speed [ 1057.376563] dwc2 20980000.usb: new device is high-speed [ 1057.439266] dwc2 20980000.usb: new address 8

[marcone]

That looks OK to me

[itsrainingben]

That looks OK to me

I may have been too late in grabbing that. I'll try again tomorrow. Again, thank you for this project.

[GCustom]

https://github.com/marcone/teslausb/issues/239#issuecomment-537288463

Mine is 2 GB

[ZeFrenchBibster]

I'll fetch mine Rpi0W from the car, and give it a try with Aja on my mac... Let's seen what happens. Meanwhile, rpi4 is only 38€... and could maybe do a lot more tricks !

[ZeFrenchBibster]

OK, same behaviour: Starts @20MB/s, but then slows down.

Tried with Blackmagic Disk Speed Test, and after a while it said: 'Error writing the test file'... and the OS shouted to me I should've ejected the CAM and MUSIC disks before disconnecting...

The Rpi was happily flashing, so no reboot I guess...

Can't connect to the Rpi (@work)... maybe the Network over USB gadget is not active?

[ZeFrenchBibster]

ok, here's the results:

We can see how the average write speed drops significantly after a while, until it becomes too slow for the car... Exactly like in the car: Mornings it works, and after say 15 minutes, it stops working

[marcone]

@ZeFrenchBibster someone on Discord mentioned that iostat on the Pi appears to be showing the car writes out the files in bulk once a minute (presumably they get recorded to internal storage on the car, then written out once complete. If that's the case (I haven't verified), then a better test would be to write out four 30MB files once a minute, and see if that slows down over time, rather than writing continuously. (also: what do the green and red lines indicate?)

[ice2032]

Mine is 1GB (which is 2x that of the RPi0W), the smallest. memory usage on the device shows 65MB.

Are the front USB ports enough to drive the RPi4? The specs say it needs at least 3A?

[mcowger]

the specs say a peak of 3A, but thats with BT, Wifi and CPU pegged.

When I actually measure it with a power meter, it never exceeded 3W steady states (4.6W peak) (model 3 ports can do 10W).

On Wed, Oct 2, 2019 at 8:07 AM ice2032 notifications@github.com wrote:

Mine is 1GB (which is 2x that of the RPi0W), the smallest. memory usage on the device shows 65MB.

Are the front USB ports enough to drive the RPi4? The specs say it needs at least 3A?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/marcone/teslausb/issues/239?email_source=notifications&email_token=AAOXCTGRNMYRSIYVO2UMYRTQMS2LTA5CNFSM4IUEPZCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAFC2XY#issuecomment-537537887, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOXCTAYNY6NNTOCFI7IIZ3QMS2LTANCNFSM4IUEPZCA .

-- -- Matt

[marcone]

Same here, I see it peak at about 700mA during boot (at 5V that's 3.5W), but once booted it's 500-600mA. That's just with sd card though, no SSD.

[itsrainingben]

@ZeFrenchBibster someone on Discord mentioned that iostat on the Pi appears to be showing the car writes out the files in bulk once a minute (presumably they get recorded to internal storage on the car, then written out once complete. If that's the case (I haven't verified), then a better test would be to write out four 30MB files once a minute, and see if that slows down over time, rather than writing continuously. (also: what do the green and red lines indicate?)

Video is somewhere between 4-5.6 Mbps so at that rate, 1 minute video segments can actually clock in closer to 40MB. I'm already late to work so don't have a programmatic way to test your question but quickly I just drag/dropped some files onto the pi (via USB as the car would as tested previously) and to write out four 33-38MB files ( it takes roughly 5 seconds. No issue on a few drag/drops over the few minutes it's taking me to write this out and don't see anything

Curious where we'll end up as a solve on this.

[vita10gy]

Has anyone ruled out something like it being a temperature spike that's just slogging everything?

Seems a bit too predictable for something like that though, I suppose.

[itsrainingben]

Doesn't feel like temperature, I had this operating fine in the SoCal Summer heat and worked in that environment.

Variables I see as being new/changed stem from the V10 update (33% additional data write bandwidth) and @marcone/teslausb teslausb@noreply.github.com 's update but I don't have visibility into what was changed in either. The data write bandwidth increase is significant but should still be well within the r/w performance of the Zero.

Not suggesting either is the culprit just pointing out what I see.

On Wed, Oct 2, 2019 at 11:24 AM vita10gy notifications@github.com wrote:

Has anyone ruled out something like it being a temperature spike that's just slogging everything?

Seems a bit too predictable for something like that though, I suppose.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/marcone/teslausb/issues/239?email_source=notifications&email_token=AGE3NGQD6WMCNUFTUEB3OQDQMTRNJA5CNFSM4IUEPZCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAFWZVA#issuecomment-537619668, or mute the thread https://github.com/notifications/unsubscribe-auth/AGE3NGS4QQD5WTVAWTL26KLQMTRNJANCNFSM4IUEPZCA .

[vita10gy]

True, it would have to be a confluence of things for sure. Something about the change pushed it over the top. I was more focusing on the explaination of why something starts fast for a while and then craters. Perhaps the PI was always doing that, it just didn't matter with 1 less video, so we never noticed, or the change made what it was always doing just worse enough to matter.

[ZeFrenchBibster]

Hi,

I build a little script to simulate (...) the way (we suppose) the car writes the files, as to keep an eye on time it takes.:

`

!/bin/bash

# while(true); do now=$(date +%Y%m%d-%H:%M:%S)

# Write 5 files like our car would do in one go...
mkdir -p ${now}
time (
(dd if=/dev/zero of=${now}/file1 bs=1m count=35) > /dev/null 2>&1
(dd if=/dev/zero of=${now}/file2 bs=1m count=35) > /dev/null 2>&1
(dd if=/dev/zero of=${now}/file3 bs=1m count=35) > /dev/null 2>&1
(dd if=/dev/zero of=${now}/file4 bs=1m count=35) > /dev/null 2>&1
(dd if=/dev/zero of=${now}/file5 bs=1m count=35) > /dev/null 2>&1
) 2>&1 >/dev/null
sleep 60

done `

I'll have it run for a while, and get back to you.

cheers,

Paul (shorter to type than my username :-)

Sorry, I'm dumb, can't get the code to show properly....

[itsrainingben]

Nice Paul! Doesn't the car write four files, not five? L/R/F/B

All about stress testing but just want to be accurate.

On Wed, Oct 2, 2019 at 11:59 AM ZeFrenchBibster notifications@github.com wrote:

Hi,

I build a little script to simulate (...) the way (we suppose) the car writes the files, as to keep an eye on time it takes.:

[code]

!/bin/bash

while(true); do now=$(date +%Y%m%d-%H:%M:%S)

Write 5 files like our car would do in one go...

mkdir -p ${now} time ( (dd if=/dev/zero of=${now}/file1 bs=1m count=35) > /dev/null 2>&1 (dd if=/dev/zero of=${now}/file2 bs=1m count=35) > /dev/null 2>&1 (dd if=/dev/zero of=${now}/file3 bs=1m count=35) > /dev/null 2>&1 (dd if=/dev/zero of=${now}/file4 bs=1m count=35) > /dev/null 2>&1 (dd if=/dev/zero of=${now}/file5 bs=1m count=35) > /dev/null 2>&1 ) 2>&1 >/dev/null sleep 60

done [/code]

I'll have it run for a while, and get back to you.

cheers,

Paul (shorter to type than my username :-)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/marcone/teslausb/issues/239?email_source=notifications&email_token=AGE3NGTAORT3GLKIPSI5M23QMTVQ3A5CNFSM4IUEPZCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAF2DCI#issuecomment-537633161, or mute the thread https://github.com/notifications/unsubscribe-auth/AGE3NGRDMWWRKICCOCXXKMDQMTVQ3ANCNFSM4IUEPZCA .

[ZeFrenchBibster]

Ben, damn wrong we are, both! 3 files only...

Corrected, and running again. I've put the actual write in the background as well, and display the time now:

`

!/bin/bash

# while(true); do now=$(date +%Y%m%d-%H:%M:%S)

echo ${now}
# Write 3, not 4. 5 is right out ! files like our car would do in one go...
# /r/unexpectedmontypython
# Then, shalt thou count to three. No more. No less. Three shalt be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, nor either count thou two, excepting that thou then proceed to three. Five is right out. 

mkdir -p ${now}
time (
(dd if=/dev/zero of=${now}/file1 bs=1m count=35) > /dev/null 2>&1
(dd if=/dev/zero of=${now}/file2 bs=1m count=35) > /dev/null 2>&1
(dd if=/dev/zero of=${now}/file3 bs=1m count=35) > /dev/null 2>&1
) &
sleep 60

done `

[vita10gy]

@ZeFrenchBibster It does 4 files now with the v10 change, which is what we're interested in testing as it worked ok with 3.

[ice2032]

There should be 4 separate files (Left, Right, Front, Back)

[ZeFrenchBibster]

Wee zoo dont 'ave ze verzion 10 yet 'ere in france, go mind your now business! :-)

Meanwhile: 21:20 $ ~/Desktop/TT/testcase.sh

20191002-21:20:40

real 0m49.383s user 0m0.003s sys 0m0.064s

20191002-21:21:40

real 0m39.823s user 0m0.003s sys 0m0.058s

20191002-21:22:40

real 0m59.830s user 0m0.003s sys 0m0.060s

20191002-21:23:40

real 0m44.914s user 0m0.003s sys 0m0.062s

looks slowing down to me, when I started testing, I had something like this:

real 0m39.059s user 0m0.006s sys 0m0.103s

real 0m34.990s user 0m0.005s sys 0m0.102s

real 0m43.685s user 0m0.006s sys 0m0.093s

real 0m33.886s user 0m0.006s sys 0m0.101s

sorry for the formatting...

[ZeFrenchBibster]

ok, the R-Pi is completely loosing it's head here....

✘-INT /Volumes/CAM/testcase 
21:20 $ ~/Desktop/TT/testcase.sh
-----------------------------------
20191002-21:20:40

real    0m49.383s
user    0m0.003s
sys     0m0.064s
-----------------------------------
20191002-21:21:40

real    0m39.823s
user    0m0.003s
sys     0m0.058s
-----------------------------------
20191002-21:22:40

real    0m59.830s
user    0m0.003s
sys     0m0.060s
-----------------------------------
20191002-21:23:40

real    0m44.914s
user    0m0.003s
sys     0m0.062s
-----------------------------------
20191002-21:24:40

real    0m54.566s
user    0m0.003s
sys     0m0.069s
-----------------------------------
20191002-21:25:40
-----------------------------------
20191002-21:26:40

real    1m26.238s
user    0m0.003s
sys     0m0.060s
-----------------------------------
20191002-21:27:42
-----------------------------------
20191002-21:28:42
^C
✘-INT /Volumes/CAM/testcase 
21:29 $ 
real    1m54.711s
user    0m0.003s
sys     0m0.064s

✘-INT /Volumes/CAM/testcase 
21:29 $ find . -typ
real    3m4.228s
user    0m0.003s
sys     0m0.055s
e f
./20191002-21:20:40/file1
./20191002-21:20:40/file2
./20191002-21:20:40/file3
./20191002-21:21:40/file1
./20191002-21:21:40/file2
./20191002-21:21:40/file3
./20191002-21:22:40/file1
./20191002-21:22:40/file2
./20191002-21:22:40/file3
./20191002-21:23:40/file1
./20191002-21:23:40/file2
./20191002-21:23:40/file3
./20191002-21:24:40/file1
./20191002-21:24:40/file2
./20191002-21:24:40/file3
./20191002-21:25:40/file1
./20191002-21:25:40/file2
./20191002-21:25:40/file3
./20191002-21:26:40/file1
./20191002-21:26:40/file2
./20191002-21:26:40/file3
./20191002-21:27:42/file1
./20191002-21:27:42/file2
./20191002-21:27:42/file3
./20191002-21:28:42/file1
./20191002-21:28:42/file2
./20191002-21:28:42/file3
✔ /Volumes/CAM/testcase 
21:30 $ 
real    2m2.511s
user    0m0.003s
sys     0m0.061s

✔ /Volumes/CAM/testcase 
21:31 $ 
✔ /Volumes/CAM/testcase 
21:31 $ 
✔ /Volumes/CAM/testcase 
21:31 $ 
✔ /Volumes/CAM/testcase 
21:31 $ 

See how there's still output coming from the commands launched in the background (&) AFTER I stopped the script?

And see how looooong they took to complete?

And I went to have a look at the pi, and saw this:

top - 20:30:58 up 52 min,  1 user,  load average: 7.03, 7.42, 4.75
Tasks: 127 total,   1 running,  53 sleeping,   0 stopped,   0 zombie
%Cpu(s):  9.5 us, 28.6 sy,  0.0 ni, 57.1 id,  0.0 wa,  0.0 hi,  4.8 si,  0.0 st
KiB Mem :   443136 total,    36396 free,    35368 used,   371372 buff/cache
KiB Swap:   102396 total,   102396 free,        0 used.   353000 avail Mem

So, I recon, it's the pi :-(