Forum Rule: Always post complete source code & details to reproduce any issue!
Page 8 of 12 FirstFirst ... 6 7 8 9 10 ... LastLast
Results 176 to 200 of 291

Thread: USB Host Ethernet Driver

  1. #176
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    401
    I was getting upwards of 7Mbit/sec on my TCP test, average of 2-4Mbit/sec.

  2. #177
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,956
    Quote Originally Posted by vjmuzik View Post
    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.

  3. #178
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    401
    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

  4. #179
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,956
    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?

  5. #180
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    401
    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.

  6. #181
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,956
    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.

  7. #182
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    401
    I mean it is about to hit sunrise in the next hour for me so I would say it’s been all night

  8. #183
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,956
    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)':
    
    T:\tCode\libraries\TeensyThreads\TeensyThreads.cpp:385:3: error: 'context_timer' was not declared in this scope
    
       context_timer.priority(255);
    
       ^
    
    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.

  9. #184
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    401
    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.

  10. #185
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,956
    Quote Originally Posted by vjmuzik View Post
    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

  11. #186
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    401
    Good, at least nothings broken so far.

  12. #187
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    401
    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.

  13. #188
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,956
    Quote Originally Posted by vjmuzik View Post
    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.

  14. #189
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    401
    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.

  15. #190
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,956
    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)

  16. #191
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    401
    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.

  17. #192
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,956
    Quote Originally Posted by vjmuzik View Post
    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.
    Cool - looking forward to it.

  18. #193
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    401
    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.

  19. #194
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    401
    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.

  20. #195
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,956
    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

  21. #196
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    401
    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.

  22. #197
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,956
    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

  23. #198
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    401
    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?

  24. #199
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,956
    Quote Originally Posted by vjmuzik View Post
    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

  25. #200
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,956
    Quote Originally Posted by vjmuzik View Post
    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
    
     F_CPU=960000000	deg  C=65
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •