USB Host Ethernet Driver

Alright new fixes have been pushed and there is in increase in performance, now the numbers roughly match up with what fbench says. So the increase in performance is linked to the size of the incoming buffer of the USB driver, so the larger the buffer the more performance you can expect, however there seems to be hard limit in that the buffer can't be anymore than 8192 bytes long or else it just doesn't work. I don't know if this is a limit to the USBHost driver or a limit to the T3.6 chip. At any rate I'm getting roughly 5Mbit/sec speeds with these fixes so it's an improvement.
 
Good work! Here is fBench running 1000 transmits of 1024 bytes using a T4 - about 10 MB/sec.

What CPU MHz is the T_3.6 using? 180 or 256?

Code: 
Benchmark results:
Megabytes: 1.24000
Seconds: 0.8880
Bytes/Sec: 1153153.1532
KBytes/Sec: 1153.1532
KBits/Sec: 9225.2252

Looped: 186989863
LoopedUSB: 6847
Benchmark results:
Megabytes: 1.24000
Seconds: 0.8760
Bytes/Sec: 1168949.7717
KBytes/Sec: 1168.9498
KBits/Sec: 9351.5982

Benchmark results:
Megabytes: 1.24000
Seconds: 0.8820
Bytes/Sec: 1160997.7324
KBytes/Sec: 1160.9977
KBits/Sec: 9287.9819

fBench numbers off a bit - maybe from the difference in Time logged:
Code: 
0.701	1,024,000	11,682.346
0.697	1,024,000	11,755.572
0.698	1,024,000	11,737.710
 
256, yeah I believe it's the difference in time logged because of overhead going through the network. The throughput number also increase some with the amount time the usbthread is run so that could be another reason the T4.0 would be faster in that regard.
 
Indeed fBench times recorded a lower - so the B/sec would be that much higher.

This buffer is 16KB? :: volatile uint8_t rbuf[512*32]; // recieve buffer
 
Not that buffer, it's the buffer in the ASIXEthernet.h file, if you increase past 16 it doesn't run for me.
Code: 
static const uint8_t bufSize = 16;
The buffer in the project does have to be equal or higher than this one though.
 
There is some anomaly even in the USBHost MSC code where something odd - seems it was 32KB failed.

HDD I/O maxed out around 12-14 MB/sec with something under 32KB - 24KB? would have to check that thread to see.

I set this in '\libraries\TeensyASIXEthernet\ASIXEthernet.h' and it worked - but no faster: static const uint8_t bufSize = 31;

Does it handle multiple messages in the buffer?
 
I set the 31 to 32 or 64 and it fails to start. Going back to 31 and it works - but again - no faster … in this case than #16 for an 8KB buffer.

Wondering if the BYTE pointer is not allocated Aligned on a 4 byte boundary and causing an issue?
 
I believe I've fixed the buffer size, some length variables weren't the right type, so I'm testing what I can hit max now.
 
Looks like with the fixes the most I can hit is 32 now, but it didn't help with the tcp throughput, but it probably increased the overall bandwidth.
 
So something isn't stable somewhere, it seems to freeze up after running several benchmark tests.
 
vjmuzik said:
So something isn't stable somewhere, it seems to freeze up after running several benchmark tests.
Click to expand...

Bummer? Is that from changes? The last I pulled down running and stable after a 'decent' number of benchmark iterations - including TWIN PING hits of 1,000 count at the same time.

I am now seeing a couple of these though never seen before - 8 of these always at offset #22 - in the first 139 iterations:
Code: 
Reply from 192.168.0.23: bytes=465 - MISCOMPARE at offset 22 - time<1ms TTL=64
That is on the shorter 465 - the 1,465 longer at same time is running okay
 
I haven't really made any breaking changes that I know of from the most recent version on GitHub, my test consists of 100 messages at 32767 bytes, TCP no delay, and iterations 10, it gets through 1-2 iterations then on the next one the Teensy locks up.
 
I had not tried ones that large. I just did 30K*1024==30720

10 iterations of 10 messages WITH TWO pings noted both running:
Code: 
2:31:38.485	Tx	Tcp	192.168.0.23	0.174	307,200	14,100.580
2:31:38.938	Tx	Tcp	192.168.0.23	0.180	307,200	13,677.497
2:31:39.362	Tx	Tcp	192.168.0.23	0.174	307,200	14,126.338
2:31:39.781	Tx	Tcp	192.168.0.23	0.176	307,200	13,961.304
2:31:40.207	Tx	Tcp	192.168.0.23	0.176	307,200	13,927.678
2:31:40.646	Tx	Tcp	192.168.0.23	0.173	307,200	14,231.488
2:31:41.78	Tx	Tcp	192.168.0.23	0.177	307,200	13,860.502
[B]2:31:41.491	Tx	Tcp	192.168.0.23	0.172	307,200	14,287.375
2:31:41.923	Tx	Tcp	192.168.0.23	0.176	307,200	13,930.922
2:31:42.350	Tx	Tcp	192.168.0.23	0.178	307,200	13,824.877[/B]

Last three - Benchmark calcs are way off:
Code: 
Benchmark results:
Megabytes: 0.307200
Seconds: 0.3780
Bytes/Sec: 812698.4127
KBytes/Sec: 812.6984
KBits/Sec: 6501.5873

Looped: 188899911
LoopedUSB: 6847
Benchmark results:
Megabytes: 0.307200
Seconds: 0.3960
Bytes/Sec: 775757.5758
KBytes/Sec: 775.7576
KBits/Sec: 6206.0606

Benchmark results:
Megabytes: 0.307200
Seconds: 0.3900
Bytes/Sec: 787692.3077
KBytes/Sec: 787.6923
KBits/Sec: 6301.5385
 
Not sure what was up with offset #22 miscompare in post #87 above - just did 100 sets of 10 at 30K with no new repeats.
 
So best I can figure out is FNET is overflowing it's heap memory I believe, by increasing this value on line 101 it lets TCP last longer, but this is not a permanent solution because the memory should not be overflowing.
Code: 
static fnet_uint8_t         stack_heap[([COLOR="#FF0000"]128[/COLOR]U * 1024U)];
 
vjmuzik said:
I haven't really made any breaking changes that I know of from the most recent version on GitHub, my test consists of 100 messages at 32767 bytes, TCP no delay, and iterations 10, it gets through 1-2 iterations then on the next one the Teensy locks up.
Click to expand...

vjmuzik said:
@defragster Does the T4.0 lock up after sending with the same settings I used in #88?
Click to expand...

---------------------------
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.0.23:7007
---------------------------
Click to expand...

Ran for some iterations I was groups of 10 trying 100 at 32767 - then stalled and gave Error above.

Code: 
 // ...
4:6:2.752	Tx	Tcp	192.168.0.23	0.193	327,670	13,572.415
4:6:3.189	Tx	Tcp	192.168.0.23	0.193	327,670	13,597.020
4:6:3.611	Tx	Tcp	192.168.0.23	0.189	327,670	13,893.049
4:6:4.30	Tx	Tcp	192.168.0.23	0.186	327,670	14,078.596
4:6:23.208	Tx	Tcp	192.168.0.23	0.047	163,835	27,816.498

Now it won't ping or restart and SerMon output stopped …

I suppose I might open debug_tt … Are there any useful status bytes/info or anything in the code that would tell you what died where?
 
I've found the error, now it'll display an error instead of getting caught in a loop. So for some reason in some case the usb buffer will still show it has data left so it would get caught in a never ending loop trying to find an index that's not there. So now it'll just discard the rest of the buffer and print an error if it get's lost instead of freezing forever.
 
Cool! I ran two sets of {100 msgs ten times } with no error and ping still works- so it was a boundary case.

I wonder if that is what was catching the PING OFFSET #22 above?
 
I can tell you that it also catches whatever causes it not to work if the usb buffer is set above 32, so apparently there is maybe message corruption if you try to queue too much at one time?
 
Just triggered this again:
Reply from 192.168.0.23: bytes=465 - MISCOMPARE at offset 22 - time=1ms TTL=64
Click to expand...

Twin Pings 465 and 1465 with fBench { 10*100 of 32767 }
No fBench error and no error in SerMon.
 
You must log in or register to reply here.
Back
Top