USB Host Ethernet Driver

I was getting upwards of 7Mbit/sec on my TCP test, average of 2-4Mbit/sec.

That would justify 'dramatically' - I'm not seeing anything like that.

I did a default "benchtx -a 192.168.0.22" and got :: 244.839 12,720,000 415.620
SerMon:
Code:
Starting benchtx...
Benchmark client started.
Protocol: TCP
Remote IP Addr: 192.168.0.22
Remote Port: 7007
Message Size: 1272
Num. of messages: 10000

Megabytes: 12.720000  Seconds: 244.8360  KBits/Sec: 415.6252


Did Upload and power off, On - rerun - no better.
 
Yeah, I'm getting a pretty consistent 4Mbit/sec
Code:
05:22:13.841 -> Starting benchtx...
05:22:13.841 -> Benchmark client started.
05:22:13.841 -> Protocol: TCP
05:22:13.841 -> Remote IP Addr: 192.168.0.2
05:22:13.841 -> Remote Port: 7007
05:22:13.841 -> Message Size: 8192
05:22:13.841 -> Num. of messages: 10
05:22:13.841 -> 
05:22:14.023 -> Megabytes: 0.081920  Seconds: 0.1620  KBits/Sec: 4045.4319
05:22:15.939 -> Starting benchtx...
05:22:15.939 -> Benchmark client started.
05:22:15.939 -> Protocol: TCP
05:22:15.939 -> Remote IP Addr: 192.168.0.2
05:22:15.939 -> Remote Port: 7007
05:22:15.939 -> Message Size: 8192
05:22:15.939 -> Num. of messages: 10
05:22:15.939 -> 
05:22:16.120 -> Megabytes: 0.081920  Seconds: 0.1620  KBits/Sec: 4045.4319
05:22:17.987 -> Starting benchtx...
05:22:17.987 -> Benchmark client started.
05:22:17.987 -> Protocol: TCP
05:22:17.987 -> Remote IP Addr: 192.168.0.2
05:22:17.987 -> Remote Port: 7007
05:22:17.987 -> Message Size: 8192
05:22:18.079 -> Num. of messages: 10
05:22:18.079 -> 
05:22:18.162 -> Megabytes: 0.081920  Seconds: 0.1400  KBits/Sec: 4681.1431
05:22:20.480 -> Starting benchtx...
05:22:20.480 -> Benchmark client started.
05:22:20.480 -> Protocol: TCP
05:22:20.480 -> Remote IP Addr: 192.168.0.2
05:22:20.480 -> Remote Port: 7007
05:22:20.480 -> Message Size: 8192
05:22:20.480 -> Num. of messages: 10
05:22:20.480 -> 
05:22:20.655 -> Megabytes: 0.081920  Seconds: 0.1510  KBits/Sec: 4340.1323
05:22:22.455 -> Starting benchtx...
05:22:22.455 -> Benchmark client started.
05:22:22.455 -> Protocol: TCP
05:22:22.455 -> Remote IP Addr: 192.168.0.2
05:22:22.455 -> Remote Port: 7007
05:22:22.455 -> Message Size: 8192
05:22:22.455 -> Num. of messages: 10
05:22:22.455 -> 
05:22:22.639 -> Megabytes: 0.081920  Seconds: 0.1620  KBits/Sec: 4045.4319
 
odd - 10X faster and not even that consistently good here.
Anything you have local not shared?
Zzzz's here now … I'm UTC-8 for timezone - same as PJRC - you?
 
I shouldn’t have any differences locally, I’m still running the latest versions that are on GitHub. My time zone is UTC-4, I just happen to be up at all hours of the night.
 
I'll get out a T_3.6 and try it to compare tomorrow … later today. It is 3 am here … -4 isn't 'all hours of the night' anymore. I see more sunrises at my house on the way to bed than because I got up early.
 
I mean it is about to hit sunrise in the next hour for me so I would say it’s been all night :)
 
I am getting this now with Bet2 of 1.48 on a T_3.6, it may have been there on T4 as well - but it may have fooled me already running the code? Saw it go by but assumed it was a warning::
Code:
"T:\\arduino_1.8.10\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-g++" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -fno-exceptions -fpermissive -felide-constructors -std=gnu++14 -Wno-error=narrowing -fno-rtti -mthumb -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fsingle-precision-constant -D__MK66FX1M0__ -DTEENSYDUINO=148 -DARDUINO=10810 -DF_CPU=180000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-IT:\\TEMP\\arduino_build_256171/pch" "-IT:\\arduino_1.8.10\\hardware\\teensy\\avr\\cores\\teensy3" "-IT:\\arduino_1.8.10\\hardware\\teensy\\avr\\libraries\\USBHost_t36" "-IT:\\tCode\\libraries\\TeensyASIXEthernet" "-IT:\\tCode\\libraries\\TeensyThreads" "-IT:\\tCode\\libraries\\FNET\\src" "T:\\tCode\\libraries\\TeensyThreads\\TeensyThreads.cpp" -o "T:\\TEMP\\arduino_build_256171\\libraries\\TeensyThreads\\TeensyThreads.cpp.o"
T:\tCode\libraries\TeensyThreads\TeensyThreads.cpp: In member function 'int Threads::setMicroTimer(int)':

[B]T:\tCode\libraries\TeensyThreads\TeensyThreads.cpp:385:3: error: 'context_timer' was not declared in this scope

   context_timer.priority(255);
[/B]
   ^

Multiple libraries were found for "USBHost_t36.h"
 Used: T:\arduino_1.8.10\hardware\teensy\avr\libraries\USBHost_t36
Multiple libraries were found for "ASIXEthernet.h"
 Used: T:\tCode\libraries\TeensyASIXEthernet
Multiple libraries were found for "TeensyThreads.h"
 Used: T:\tCode\libraries\TeensyThreads
 Not used: T:\arduino_1.8.10\hardware\teensy\avr\libraries\TeensyThreads
Multiple libraries were found for "fnet.h"
 Used: T:\tCode\libraries\FNET
Using library USBHost_t36 at version 0.1 in folder: T:\arduino_1.8.10\hardware\teensy\avr\libraries\USBHost_t36 
Using library TeensyASIXEthernet in folder: T:\tCode\libraries\TeensyASIXEthernet (legacy)
Using library TeensyThreads at version 1.0 in folder: T:\tCode\libraries\TeensyThreads 
Using library FNET at version 0.1.2 in folder: T:\tCode\libraries\FNET 
Error compiling for board Teensy 3.6.
 
Are you using the newest version of TeensyThreads or the first one that supported T4.0? The first one had a typo that didn’t let it compile for T3.6 that he fixed in the newest update.
 
Are you using the newest version of TeensyThreads or the first one that supported T4.0? The first one had a typo that didn’t let it compile for T3.6 that he fixed in the newest update.

Was using older version - working now - Thanks - had not caught that update.

Ping, Send and receive seems to be working on T_3.6 here with TD 1.48b2
 
So there is some kind of bug regarding TCP transmit window size which is causing the speed to be diminished. The window size is supposed to be the same size as your buffer, but it’s defaulting to 2048 instead of the buffer size so it’s causing TCP messages to be sent and received out of order thus throwing an error code and causing a lot of messages to be resent over and over. I’m currently trying to locate the source of the bug, but if I set the buffer to the same 2048 then there isn’t all the out of order errors and speed is better. I also rigged up my T4.0 so I can test with the USB on that now as well as the T3.6. So my T3.6 experiences the same errors, they were far less frequent than the T4.0 so the speed was reported higher, but they are both stemmed from the TCP window size.
 
So there is some kind of bug regarding TCP transmit window size which is causing the speed to be diminished. ...

Interesting! Darn magic code hiding errors/flaws in the system! That explains there seeming to be some magic spots where speed seemed higher - when it didn't break that buffer barrier for a message.
 
Alright so I found out what was causing the transmit window size to be wrong, however that turned out to not fix the issue, but I did find what is causing the issue. The issue is something I thought to have fixed except because of the slower speed of the T3.6 it was technically fixed for that and was the reason it worked correctly on there and not the T4.0. So basically the issue is its queueing data faster than it's transmitting over USB so it's actually losing data because of that, thus why TCP gets error because it can detect lost data. Now the way I fixed it on the T3.6 was to increase the amount of transfer queues I had in my ASIX driver and that seemed to work fine, but increasing it more than I did for the T3.6 doesn't seem to be doing any favors for the T4.0 so I'm a little lost as to where this could be solved. I see how @wwatson handles his data queues for the MSC driver and I feel like there's probably a better solution than locking the program until each transfer completes. Just the little bit of overhead from having each output message printed over the serial monitor fixes the issue, but that isn't viable as the serial monitor won't always be present.
 
Interesting - don't see an update?

When adding que spots runs out it would be better to pause/spin than end up with lost data or time wasted re-transmitting? At least for a first pass …. that is how other Serial devices work.

Compared to 1 ms or much longer delays with SD card writes - even like this from post #131 to HDD with the @wwatson MSC code:
8.139112 MB/s
(open: 17995 us; close: 26000 us; write: min,max: 3964 3972 us)
 
I'm working on modifying some of the code from the usb serial driver so it actually uses the full queue buffer when it tries to send a lot of data instead writing a bunch of small buffers.
 
Alright I found and fixed the actual issue, so the problem was that using one transmit buffer wasn't enough since before the USB message would be sent the buffer would start to be overwritten by the next message and end up being corrupted. So now I have 8 buffers just to be safe because I know I hit at least 5 transfers at one time already so for now this should be plenty.
 
So doing 100 messages of 8192 bytes with TCP I get about 9.1Mbit/sec pretty consistent and doing the same over UDP I get about 300Mbit/sec, so at least we aren't being crippled by USB speeds.
 
Doesn't like 960 or 912 MHz? Never connects?

Looped: 12639339 LoopedUSB: 3507 LinkSpeed: 10BASE
Looped: 12639334 LoopedUSB: 3507 LinkSpeed: 10BASE

Dropped to 600 and it is up …

PSping not one tenth of what it was? Now 640 was 8900 in 10 secs?
T:\T_Downloads\PSTools>psping64.exe -i 0 -q -n 10s 192.168.0.23

PsPing v2.10 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2016 Mark Russinovich
Sysinternals - www.sysinternals.com

Pinging 192.168.0.23 with 32 bytes of data:
10 seconds (1 warmup pings) connecting test: 100%

Ping statistics for 192.168.0.23:
Sent = 640, Received = 640, Lost = 0 (0% loss),
Minimum = 0.56ms, Maximum = 1.90ms, Average = 1.22ms


TCP fBench 10 sets of 10240 ::

Big mismatch on timing from fBench:
0.035 102,400 23,506.119
0.034 102,400 24,274.031
0.016 102,400 52,427.793
0.016 102,400 52,428.800
0.031 102,400 26,217.252

versus SerMon:
Megabytes: 0.102400 Seconds: 0.0840 KBits/Sec: 9752.3810
Megabytes: 0.102400 Seconds: 0.0840 KBits/Sec: 9752.3810
Megabytes: 0.102400 Seconds: 0.0900 KBits/Sec: 9102.2222
Megabytes: 0.102400 Seconds: 0.0900 KBits/Sec: 9102.2222
Megabytes: 0.102400 Seconds: 0.0840 KBits/Sec: 9752.3810
 
I’m not sure about the latency increase, there shouldn’t be that much of a difference between previous versions and this new fix. I don’t think the way I’m cycling buffers has any kind of impact, at least not that much where it would drop from 8900 to 640.
 
It does run at 720 and 812 MHz … but not faster throughput

At 812 MHz these are the Task Counts :: Looped: 10,277,280 LoopedUSB: 3,507

With :: benchtx -a 192.168.0.22 -m 4096 -mn 10

I get:
Code:
Starting benchtx...
Benchmark client started.
Protocol: TCP
Remote IP Addr: 192.168.0.22
Remote Port: 7007
Message Size: 8192
Num. of messages: 10

Megabytes: 0.081920  Seconds: 0.0960  KBits/Sec: 6826.6667
Starting benchtx...
Benchmark client started.
Protocol: TCP
Remote IP Addr: 192.168.0.22
Remote Port: 7007
Message Size: 8192
Num. of messages: 10

Megabytes: 0.081920  Seconds: 0.1020  KBits/Sec: 6425.0980
Starting benchtx...
Benchmark client started.
Protocol: TCP
Remote IP Addr: 192.168.0.22
Remote Port: 7007
Message Size: 8192
Num. of messages: 10

Megabytes: 0.081920  Seconds: 0.0960  KBits/Sec: 6826.6667
Starting benchtx...
Benchmark client started.
Protocol: TCP
Remote IP Addr: 192.168.0.22
Remote Port: 7007
Message Size: 8192
Num. of messages: 10

Megabytes: 0.081920  Seconds: 0.1020  KBits/Sec: 6425.0980
Starting benchtx...
Benchmark client started.
Protocol: TCP
Remote IP Addr: 192.168.0.22
Remote Port: 7007
Message Size: 8192
Num. of messages: 10

Megabytes: 0.081920  Seconds: 0.1140  KBits/Sec: 5748.7719
Starting benchtx...
Benchmark client started.
Protocol: TCP
Remote IP Addr: 192.168.0.22
Remote Port: 7007
Message Size: 8192
Num. of messages: 10

Megabytes: 0.081920  Seconds: 0.0960  KBits/Sec: 6826.6667
 
I’ll have to rig up a fan to test at the higher clock speeds and see if it’s anything in my driver. Do you know if other usb devices work at the higher speeds?
 
I’m not sure about the latency increase, there shouldn’t be that much of a difference between previous versions and this new fix. I don’t think the way I’m cycling buffers has any kind of impact, at least not that much where it would drop from 8900 to 640.

Same CMD window open - running the same line …

Now:
Pinging 192.168.0.23 with 32 bytes of data:
10 seconds (1 warmup pings) connecting test: 100%

Ping statistics for 192.168.0.23:
Sent = 640, Received = 640, Lost = 0 (0% loss),
Minimum = 0.52ms, Maximum = 1.89ms, Average = 1.26ms

older:
Pinging 192.168.0.23 with 32 bytes of data:
10 seconds (1 warmup pings) connecting test: 100%

Ping statistics for 192.168.0.23:
Sent = 8990, Received = 8990, Lost = 0 (0% loss),
Minimum = 0.27ms, Maximum = 2.01ms, Average = 0.90ms
 
I’ll have to rig up a fan to test at the higher clock speeds and see if it’s anything in my driver. Do you know if other usb devices work at the higher speeds?

Using simple copper heat sink on this T_4: Looks the same as 1 in use - just ordered this 8 pack :: Copper VGA RAM Cooling Heatsinks

Yes no problem running the MSC > "T:\tCode\libraries\uSDFS\examples\logger_RawWrite\logger_RawWrite.ino" at 960 MHz.

Code:
Test logger_RawWrite

[B] F_CPU=960000000	deg  C=65[/B]
uSDFS_VER:30_Jun_19_07_17
BUFFSIZE :8192
Dev Type :2:/
File System FS_EXFAT
Free Disk Size -1 clusters
Cluster Size 256 sectors
Sector Size 512 bytes

Change drive
A_00001.dat
stat FR_OK 0
 opened FR_OK 0

................................................................
................................... (3021996 - 10.843164 MB/s)
 (open: 15999 us; close: 20000 us; write: min,max: 2981 3986 us)

Data thoughput not improved … unless I make the buffer bigger - here 24K DWords - now 16 MB - old high was IIRC 14 MB/s:
Code:
 F_CPU=960000000	deg  C=71
uSDFS_VER:30_Jun_19_07_17
BUFFSIZE :24576
Dev Type :2:/
File System FS_EXFAT
Free Disk Size -1 clusters
Cluster Size 256 sectors
Sector Size 512 bytes

Change drive
A_00001.dat
stat FR_OK 0
 opened FR_OK 0

................................................................
.................................... (6122995 - 16.054888 MB/s)
 (open: 42999 us; close: 83000 us; write: min,max: 4960 13961 us)

Funny it drops back to 14 MB/s when I set the buffer to 31K DWORDS.
 
Back
Top