Teensyduino 1.56 Beta #1

Status
Not open for further replies.
PaulStoffregen said:
Sadly, it seems we will need to throttle speed when transmitting to Windows.

I still want to see a test which positively confirms the barriers are actually preventing a bug rather than merely changing timing.
Click to expand...

Sorry, I've put enough time into this. I don't feel like it.
I've already shown that it helps. And as USB seems to be maxed-out speed-wise - on windows - it is really out of pure academical interest. Couln't see any speed difference on my system. Perhaps try to use only asm ("":::"memory"). Don't know if it works, too.
 
Triple T_4.1's doing serialtestT.exe in dos boxes. Two wakes to unblank screen and Neither caused any USB disruption - The EXE buf is now 2MB, only change.

Runtime since last EXE edit/build date is 9.5 hours.

Code: 
The three show stats of ZERO LOSS at this point with completions of this number of 100K groups of 33 bytes ( 3.3MB each ):
[B]269201 + 237001 + 254601[/B]

average throughput on EACH is 200 Mbps with occasional hits of 104, 154, 174 Mbps numbers { this version only shows 1 in 50 of each completed 100K } : something can safely slow the Teensy without loss.

So at any given time the transfer sum is ~600 Mbps :: Without error

The code on each is likely running some many megabytes behind with Windows providing buffers.

Buffers handled in steady state are showing no errors or problems - but the DOS BOX exe ability to empty the buffers is not matching the Teensy ability to fill them.

This code happy, but behind, in this one steady state scenario. What it takes to interrupt and break the buffer handling appears to be Windows multitasking distraction.


If the CORES USB code could safely/efficiently throttle the output rate that would allow the sketch to know all data will arrive safely - but the sketch will be slowed when too much output is sent. That is what the USER has to GUESS at now ...
 
I know this is going to sound crazy, even impossible, but I want to try to get Microsoft to fix this driver problem. I'm hoping we can find a way to make the test program more reproducibly give a result like msg #167, which sure looks like a possibly security vulnerability. Maybe if we add delays like busy loops, or other threads which do various things to cause the problems to manifest?
 
PaulStoffregen said:
I know this is going to sound crazy, even impossible, but I want to try to get Microsoft to fix this driver problem. I'm hoping we can find a way to make the test program more reproducibly give a result like msg #167, which sure looks like a possibly security vulnerability. Maybe if we add delays like busy loops, or other threads which do various things to cause the problems to manifest?
Click to expand...

Haven't really been following in great detail but which test program and which usb_serial.c?
 
A post later it shows a CSS style sheet.
I have some hints

- Don't start Arduino or any other "technical" program. It would show sourcecode or other not interesting things.
- Start a RAM intensive program like Firexfox. Open a lot of tabs with big pages , lots of css and javascript. If you have more then 8GB - perhaps reduce the RAM?
- Use my serialtest. Short the printf, so does it not print own texts - only USB or RAM contents and let it print everything but space.. Let my test program print spaces.
- Make the Window fullscreen
- Point with the mouse to the scrollbar, Klick and hold the mouse a few seconds. i.e. the program must stop. This, with a high chance, produces garbage.
- OR: Insert a long delay. 500ms or such. But not too often - the Teensy must overflow the PC buffers. Or use a keypress.
- Don't use Sleep().
- I can write such a program.
- Use a screen recorder.
- If you get money: Give me 50% :)
 
Last edited:
OR:

Sketch:
Code: 
void setup() {
  Serial.begin(9600);
  delay(1000);
  while(1) Serial.write('\0');
}

void loop() {}

Then just run coolterm and log to file.
Try to resize and make the screen blink. Klick "clear data".
 
Just pushed an update to : Defragster/cdcbench/tree/main/AltVersion
> included compiled EXE

Using command line like this will print ONLY full text of everything sent from Teensy: SerialTestT COM11 SZ33 Q
>> (EDIT) : Will PRINT ALL teensy strings that are NOT the specified length! - i.e. GARBAGE and the summary update string from Teensy : It does NOT attempt to print each test transfer string where length match SZ. (Doing that is where I saw the 423 Mbps go by)
> that matches current string in the posted sketch: char szTest[] = "13579abcdefghijklmnopqrstuvwxyz0\n"; //SZ33
> when using "Q" as 3rd param the length can be ANYTHING - except the length matching the expected output length from Teensy - about 56 bytes.
--> without the "Q" the default is to HIDE most Garbage to minimize print SPEW

Got this idea of Windows USB MAX buffering rate when starting clean with emptied buffers:
Code: 
13579abcdefghijklmnopqrstuvwxyz
3300000 Bytes in 62351 us = [B]423.41 Megabits per second[/B]
13579abcdefghijklmnopqrstuvwxyz

Running that "Q" in DOS box and doing 'Ctrl+A' ... Spacebar gave this:
Code: 
3300000 Bytes in 119528 us = 220.87 Megabits per second
13579abcdefghijkXXXXXXXXXX
X
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX♂X♂♫X♫☼X☼►X►◄X◄↕X↕‼X‼▬X▬↨X↨↑X↑↓X↓≥≥Y≤≤Y▐▐Y▀▀YααYßßYΓΓYππYΣΣYσσYµµYττY╚╕²
        X       XXXXXXXXXX
X
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX♂X♂♀X♀loÑ☻Ω▓²
        S♫─**☺  S♫─**δY♫─**╕cJ╧☺╒**(s   S♫─**   δY♫─**
X_Lines-Delta: 9830218. Received: δY♫─**ΦcJ╧☺╒**ΦcJ╧☺╒** bytes: 32δY☺
X_Lines-Delta: 0. Received: '♠ bytes: 32'♠=v5♂╪◄r5♂╨☻)∙║∟=v5♂╪◄r5♂╨☻)∙║∟=v5♂╪◄r5♂╨☻)∙║∟(┼{♣i±
=v5♂╪└]J╧☺╒**ì<c▬♣°**   S♫─**☺
        S♫─**0↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,∙
↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,↨,∟=v5♂╪◄r5♂╨☻)∙║∟=v5♂╪◄r5♂╨☻)∙║∟=v5♂╪◄r5♂╨☻)∙║∟=v5♂╪◄r5♂╨☻)∙║∟Ö╤╜α┐     ±α┐     Θ<-"┘α┐ Ö◄⌐
ßL∟┘α┐  ▒◄⌐
ßL∟┘α┐  ╜◄⌐
ßL∟╤"-"-"╤"-"=2┼"-",'α  -"d.♥╖⌐8ó│3SΣi≈∞┬`┼ ╚╫^╨¼§mâH|Üoè∟_OB╦Zⁿ│┌7⌂√ª¡►q║≥_3qÄ?►S╣@δ⌡¶PÜOµ☼⌐>╬∞ó▌w¼I(cⁿ╙gà≤zYÜΘ√z¥q→◄τ╓P≡½?↑≥i↨♣┤ÿßkzºJßLΘH☻(à┤.nÅΣ▀}?½è6N☻πPß@qF
{∙ÿ░»5¡ÿß½╜ëj♠╖N*÷╝~\└u(N₧►◄ï¡╩;        ôCQ☼$
╟@≡♂NiΩ↑V↕^e9┼3→╓╦]☺jk╨[tTù↔«↕π⌡óZ►|·Çà☻↔♀☼0{└╨╙sèV┘ë
╙█ö♠¿▀s♀u▼^JiΦΓòîN#w▬÷┘æ▌└-F∟≈╝▀σª┴Γ‼»o╛╦6⌠╫┴7æÖ∙Q}=n╜τ╪Ö¢i
a|╡ûaî♦ÆsK╡@bs╝┌Washington1►0♫♠♥U♦‼Redmond1▲0∟♠♥U♦pä∙»d╨♂↑Ç╙,\╒↓tûu$¬¢¶ φjª♥'DU╩X╩á=▐
220910190730Z0x1♂0      ♠♥U♦♠‼☻US1♂0    ♠♥‼☻WA1►0♫♠♥U♦‼Redmond1↕0►♠♥U♦
‼       Microsoft1♀0
[g D¶╕¶½ÜƒûÿL"½π.┐∩Ωδc'M╛}_╩P∟BÑ╪♠&Ä♥ÉÄ£ùoí⌐├µ≥/²╡òOyKMß{zöLtSê αóó$∟_Wc¶a╡òk^b~è↑╠B┐P╗@☺ú[╔»╟■┌E→╝╪ⁿ±9ó«╗J▬F▓↔z9⌠£◄◄ª╞öbu├⌐±2úòíΩΩ·¥kA▌Kkfi§╚IÅ┐GLσö┬↔µt▲~ⁿδ±▀Ω±←╪ëaxYv♣
1╔mk|├ò6B⌂ää«⌂ ╒äTqír▼@=-╒☻♥☺sÅP*ä≤K¬°T♣å-6╖j╚e9Ia?╖↑Washington1►0♫♠♥U♦‼Redmond1▲0∟♠♥U♦
261018230519Z0~1♂0      ♠♥U♦♠‼☻US1‼0◄♠♥‼♦ft Root Certificate Authority 20110▲↨
Washington1►0♫♠♥U♦‼Redmond1▲0∟♠♥U♦
☺☺☺♣☻é☻☺╫▀ôφ⌂▌¼±,s→┘↓7U║▌"xÄí╘¢ °"1q░ö«α░τ&DWÉüù§╬a∞eΓK±àR▬2°╡x¬~═M∞â!ñ¿¢╛Üj♦αú∟═V↑l²k/B>Γ7≥r½╨xsr{▐∞    "version": 0,
    "test":     },
    "log": [],
    ÷│²
∞R♫─**♦Ç**↕îï╙ⁿ⌂∞R♫─**α∙☼╪☺╒**└P÷_♫─**♦☻D>D>D>D>D>D>D>D>D>D>D>D>D>D>#X#☺X☺☺X☺☻X☻♥X♥♦X♦♣X♣♠X♠     X       XXXXXXXXXX
X
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX☺∞R♫─**►Σ⌐┘☺╒**Ç▒)^♫─**7☺á∟ú▬♣°**∞R♫─**pσ⌐┘☺╒**Ç▒)^♫─**hêr▬♣°** ┘⌐┘☺╒**╪Æ7b♫─**@PÆ+♫─**********       S♫─**☺  S♫─**▬m$r♣°**   S♫─**☺
        S♫─**   S♫─**åΦ"r♣°*♂   S♫─**ªóh▬♣°**ObFl∞R♫─**`⌠⌐┘☺╒**Ç▒)^♫─**☼X☼►X►↔╢²
☻13579abcdefghijk13579abcdefghijklmnopqrstuvwxyz
3300000 Bytes in 84483 us = 312.49 Megabits per second
3300000 Bytes in 208135 us = 126.84 Megabits per second
 
Last edited:
Frank B said:
- If you get money: Give me 50% :)
Click to expand...

If there is a prize to be claimed, you could go get it and keep 100%. So could anyone with the fortitude to read this lengthy thread and do whatever additional work is needed (probably a lot) to turn this into proof of concept code worthy of a bug bounty.

I personally just want to see Microsoft fix their CDC driver!

Even if it's not a security issue, there is still some hope.

Years ago the driver had that terrible bug where the COM port would appear but not work if the prior disconnect happened while any program had the port open. Phil Torrone (of Adafruit) somehow found the name and contact info of someone at Microsoft and started an email chain about the issue. At first the Microsoft engineers denied it was a bug in Windows. So I made this video demo to prove it to them. They (perhaps reluctantly) agreed it was indeed a bug. A couple weeks later I got a followup email that they had a meeting and decided not to fix it. That was several months before Windows 8 came out.

Years later after Windows 8 had pretty much bombed, they published the first technical preview for Windows 10. It still had the bug. But after quite some time passed, they started doing updates. I'm not sure which update fixed it, but it was pretty early in the tech preview time.

I still to this day have no idea whether those emails and that video actually put the USBSER.SYS "surprise removal bug" on some list. It could have been forgotten and then by dumb luck fixed later. Who knows?

But I do know for sure that Phil somehow got this guy's contact info and started an email chain and I made that video when they denied the bug, which cause them to admit it was indeed a bug in Windows.

So I'm hopeful with enough work and a little luck we might somehow repeat that process and maybe by Windows 12 or 14 or 15 we might see this problem finally fixed.

Or maybe someone reading this will turn it into a spectacular security vulnerability and manage to cash in. I really hope someone does. If it's actually a vulnerability, maybe we'd see a fix within a year?!
 
Tim within 3 minutes got this only - not as interesting as yours :)
(window.webpackJsonp=window.webpackJsonp||[]).push([[3],{345:function(module,exports,__webpack_require__){(function(module){var __WEBPACK_AMD_DEFINE_FACTORY__,__WEBPACK_AMD_DEFINE_ARRAY__,__WEBPACK_AMD_DEFINE_RESULT__;__webpack_require__(770),__webpack_req♦♦*♥j↨∟↨K↨I↨↓¶↔!3↨┤↔<↨←¶×▬Æ‼»%┤
Click to expand...
 
Last edited:
Good night.
Oh I'm pretty sure it is a vulnerability. It shows RAM-Contents that are not part of the running program.
The the CSS only I post earlier can give hints which webpage it was... now, let it be a internal intranet page of a large company. With "secret" info.
Luck that there is no password (or maybe username)
 
Last edited:
Good night Frank.

Frank B said:
Tim iwithin 3 minutes got this only - not as interesting as yours :)
Click to expand...

"Root Certificate Authority" Definitely not from 'DOS BOX' memory space :(

Only tried ONCE and that is what I got. Had Visual Studio 2019 open - updating it and now updating again to add more Installed parts. Want to see if I can get a simple CDC app created. Not sure if that or other exposed the text 'Root Certificate Authority'

Minor EDIT to p#236 text made on the "Q" output.

I have THREE T_4.1's running it with NO TROUBLE signs in normal steady state. It seems I saw ONE 'line' glitch show on windows 'resize'.

STOPPING the EXE and using TYCOMM on that Teensy QUICKLY shows GARBAGE trying to print everything.
 
mjs513 said:
@defragster - sorry Tim - can not run your exe - in compatible with Win64 :)
Click to expand...

Odd?

Save the EXE to a folder.
Open a DOS box to that folder and run? :: SerialTestT.exe COM37 SZ33 Q

If you have GCC : gcc -m64 serialtestT.c -O3 -Wall -oserialtestT.exe
 
Ok finally got it to compile after having to install gcc 64 bit. the 32 bit version I had had a problem. Got this almost right away:
Code: 
3400000 Bytes in 92997 us = 292.48 Megabits per second
3400000 Bytes in 89844 us = 302.75 Megabits per second
3400000 Bytes in 90105 us = 301.87 Megabits per second
3400000 Bytes in 88692 us = 306.68 Megabits per second
3400000 Bytes in 93334 us = 291.43 Megabits per second
13579adefghijklmnopqrstuvwxyz0
3400000 Bytes in 97163 us = 279.94 Megabits per second
13579abcdefghijklmnopqrsvwxyz0
3400000 Bytes in 99803 us = 272.54 Megabits per second
3400000 Bytes in 95374 us = 285.19 Megabits per second
179abcdefghijklmnopqrstuvwxyz0
3400000 Bytes in 95750 us = 284.07 Megabits per second
13579abcdefghijklmnopqrstuvwxot so bralnik dokumentov PDF, mo┼╛nosti glasnega branja, orodja za slovnico, pisanje s peresom in veliko drugega. Nastavite ga za privzeti bralnik dokumentov PDF.Nastavi za privzeti bralnik dokumentov PDFMicrosoft Edge je nasta      jo poskusite odstraniti s seznama in jo nanj znova dodati.─îe uporabljate stre┼╛nik proxy:Preverite nastavitve proxyja. Morda boste morali v svoji organizaciji preveriti, ali stre┼╛nik proxy deluje. ─îe menite, da uporaba stre┼╛nika proxy ni potrebna    <br /><br />
    Obrnite se na svojo organizacijo.Spletnega mesta <strong jscontent="failedUrl"></strong> ni mogoče doseči.Datoteka na naslovu <strong jscontent="failedUrl"></strong> ni berljiva. Morda je bila premaknjena oz. odstranjena ali pa dostop preprečujejo d    $1Rezultat št. $1 od $2Ni rezultatovNazaj (Ctrl + Shift + G)Naprej (Ctrl + G)Iskalne zastaviceReset allWarning: Experimental features ahead!By enabling these features, you could lose browser data or
    compromise your security or privacy. Enabled features apply to all
    users of this browser. If you are an enterprise admin you should
    not be using these flags in production.Ni eksperimentov, ki bi se ujemaliNi na voljo na va┼íi platformi.Ponastavitev je bila priznana.Preskus je omogo─ìen1 result for '$1'$1 results for '$2'Ponastavi vseFunkcije iskanjaZastarele funkcijeNepodprte funkc13RCRD(☺e☻E☺e☻E♥c♥c☺☺n☻N☺n☻N☺☻D☻D☺a☻A☺a☻A☻D☻D☻I☻I♥c♥c☻B☻B☻D☻D♥c♥cx■■☺e☻E☺e☻Eùc∩/ùc∩/♥c♥c☺a☻I☻K☻K☻M☻M☺m☺m☻M☻M☺n☺n☻N☻N☻E☻I☻K☻K☻M☻M☺m☺m☻M☻M☺n☺n☻N☻N☻A☻E☺a☻A¥c∩/¥c∩/¥c∩/☻D☻D☻I☻I☻B☻B♥c☻D☻D♥c♥c«c∩/☺♥c☻C☻C♥c3400000 Bytes in 117038 us = 232.40 Megabits per second
3400000 Bytes in 95322 us = 285.35 Megabits per second
3400000 Bytes in 95455 us = 284.95 Megabits per second

Some of that looks like microsoft edge but not sure of all the other stuff. Why do I say it looks like EDGE because I have edge open and Task manager shows I have 6 instances but I only have 2 tabs.

Capture.PNG

Sorry couldn't get coolterm to save file
 
mjs513 said:
Ok finally got it to compile after having to install gcc 64 bit. the 32 bit version I had had a problem. Got this almost right away:
...

Some of that looks like microsoft edge but not sure of all the other stuff. Why do I say it looks like EDGE because I have edge open and Task manager shows I have 6 instances but I only have 2 tabs.

View attachment 26101

Sorry couldn't get coolterm to save file
Click to expand...

Edge and 'browser' indeed.

Have 7 instances of EDGE open here with some large number of tabs - TaskMan shows (50) subtasks.

Funny of PowerShell and both command Processors are their own entry - but definitely running on ONE CORE. Pausing the first two dropped ~10% each then ~30% for the final - leaving some 10% on that core as before.

Two glitched and restarted the third dumped this - passed the "Q" uick print and then hung in the "-X_" recovery over a minute ago with this - showing computer make/model:
Code: 
3300000 Bytes in 123659 us = 213.49 Megabits per second
13579abcdefghijkl***********************************************************************************************************************************************************************************************************************************************`e☻`e☻`e☻`e☻
X_Lines-Delta: -635894308. Received: `e☻ bytes: 32`e☻ö─+V☻║K¶↨♦α‼≡#└3Ç6á[á&☺p=☺░?☺ ^☺@p☺ v☺ ü☺Çü☺@é☺░é☺►â☺Éå☺Éï☺╨æ☺Éò☺╡#Ñ
═
╡#scenarionsqö╥Ñ╨╦╞─┘◄⌐"o:bc3902d8132f43e3ae086a009979fa88╤♠é♦╦§
☺i      Dell Inc.ë♂Vostro 5880☺☺I&c:2d48bf63-777c-4926-bd9f-28e5787f842e⌐☼Windows.Desktomsteamsupdate╔♠↕21253.5☺)↔EVT-♦-C++-ECS-☺-      1628☺⌐
◄↕AppInfo.CliInstanS                    ☼¶≤►B♀≡
╨♠└♦P♥0☻p☺`44|0|0|16385|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|33554432|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|524288|0|0|0|0|0|0|0|268435456|0|0|1073741824|0|0|0|67108864|0|0|0|0|0|0|0|0|0|0|1048576|0|0|0|0|0|0|2097152|0|0|0|0|0|0|0|0|268435456|0|0|0|0|0|0|0|÷q**áσw└#²**↑♀*************************************≤║#*≡«*≡«☺☺Å☺☺☺☺3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v   3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v3v☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺
X_Lines-Delta: 0. Received: ☺ bytes: 32☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺☺çA½ê☺►ê♣►ê☺ ê ►ê♣ ê☺0.X_32

> That 'dos box' won't return to show prints - and 'Ctrl+A' selects but doesn't drop core use %, had to Ctrl+C to break it ... It restarted so it wasn't the Teensy.
 
mjs513 said:
Ok made a couple more sequential runs of about 10-15 minutes each and both show weird stuff - mostly looks like 0xff, soh, sof etc. Attached for review since not sure its meaningfulView attachment 26103
Click to expand...

Surprising it works at all - TyComm fails fast.

I feel like NTSB showing up to a drone range and finding craters with pieces in ... and no black boxes ... can we just blame gravity and go home?

The Teensy sends the 100K strings too fast - so slow it down ...

Running a SINGLE ( against serialtestT.exe ) I could not get the Mbps under 200 even with a 20 to 500 ns delay!

BUT - I did see more failed strings with those delays ???? At least early in the start. At FULL speed ZERO failed strings would be observed.

Finally jumped to 1500 ns delay after each print as below and now it is showing about 140 Mbps and some 50 or 98 Mbps - and this showed up:
Code: 
...
3300000 Bytes in 273815 us = 96.42 Megabits per second
3300000 Bytes in 185669 us = 142.19 Megabits per second
13579abcd*******************************************************************************************************************************************************************************************************************************************************3300000 Bytes in 184209 us = 143.32 Megabits per second
3300000 Bytes in 183489 us = 143.88 Megabits per second
...
3300000 Bytes in 183419 us = 143.93 Megabits per second
1♦Ç***♦Ç******♦Ç******♦Ç******▓@y♂½Fy♂♦Ç******:♦Ç******♦Ç******:♦Ç******:♦Ç******:♦Ç******dy♂Pdy♂ky♂3300000 Bytes in 266152 us = 99.19 Megabits per second
3300000 Bytes in 182631 us = 144.55 Megabits per second
...

Started up so all three T_4.1's are running and holding just over 140 Mbps ( with some sub 100 Mbps blips on each ):
Code: 
void loop() {
  t = micros();
  for (int i = 1; i < n + 1; i++) {
    Serial.print(szTest);
    [B]delayNanoseconds( 1500 );[/B]
  }
  t = micros() - t;

Just stopped all three and restarted them, only first string seemed broken - no surprise and all three stable now, except one just sent this 'early', but not quickly - all now looking good:
Code: 
3300000 Bytes in 182840 us = 144.39 Megabits per second
3300000 Bytes in 181547 us = 145.42 Megabits per second
13579abcD>D>D>D>D>D>D>D>D>D>D>D>▄       D>D>☻
Å☼Å☼3300000 Bytes in 200889 us = 131.42 Megabits per second
3300000 Bytes in 181158 us = 145.73 Megabits per second

And that one CPU core is generally under 55% - closer to 50% rather than 10% higher so reduced traffic is easier on the core.

NOTEWORTHY and ODD that 1.5us spacing between each of 100,000 prints causes MORE string issues? Is that Teensy or Windows?

That also shows that throttling the Serial USB really does take time: Spent in CORE_USB waiting. 100K*1500ns is 150 ms and the total transfer time measures shown above are 181-185 ms !!! Some "free" transfer time in the loop and other code - but it only takes 35 ms (~190ms/sec) for T_4.1 to queue 140 Mbps during sending.
 
Just noticed defragster post # over 15K ...

Started the three without "Q" to see stats. They got started with zero errors in the first 100 sets of 100K. One however did pop one bad string on about #115 - all good since then on the three with 1400 sets of no other bad strings. One other string miss on another Teensy before they all got to 3000.

Using the EXE for monitor any garbage is rare - so the "Q" doesn't so much without forcing an error.

With a T_4.1 limited to 140 Mbps - TyComm started okay - but is now in garbage land. Moving to T_sermon ...
> Didn't last long - pauses - pages of garbage and then return to function.

Interesting NOTE: return to TaskMan - CPU Perf. That ONE CORE now running at 60% KERNEL TIME ( IT WAS ALL KERNEL time before ) - but now has APP time over Kernel time at 90% with regular peaks toward 100% on that core.
> maybe the INTEL CPU only has USB connectivity on that first CORE?

<edit> - an hour away from last post ... Tsermon streaming along
On Screen wake the other two did trigger bad strings - still with 2MB RAM buffer in the EXE.
> those two showing 23601 sets of 100K each and one Less=14 w2 repeats and the other less=19 and also 2 repeats. So dropping the send rate with 1.5us delay is not helping and for the 'short' run it is perhaps worse than the unbounded write from sketch as it seems they've gone more hours before with less missed strings. Computer restarted today - but maybe some new thing outside the USB is different.
Tsermon not shown anything odd in peripheral these past minutes.
 
Last edited:
defragster said:
NOTEWORTHY and ODD that 1.5us spacing between each of 100,000 prints causes MORE string issues? Is that Teensy or Windows?
Click to expand...

Answering this question will require an immense amount of work to capture and parse / read / search through the USB communication happening between Teensy and Windows.

My Beagle 480 protocol analyzer probably isn't up to the task, as it only has a small 64MB buffer and 480 Mbit downlink for the capture. It works great for normal USB stuff where you have only short bursts of maximum bandwidth communication. A few times in the early days of USBHost_t36 where I made mistakes that flooded the USB bandwidth, it completely locked up. They do sell a much more expensive model with 5 Gbit/sec USB3 downlink. Whether my PC is even up to this task is a good question. I have only 64GB RAM. Capturing max bandwidth 480 Mbit communication with the timing info and whatever other per-packet metadata Total Phase uses burns up the memory buffer quickly!

I do intend to try at some point. MTP is a much higher priority right now, so I probably won't really put serious time into this anytime soon.

There is one thing you could do in the test code which would really help, when I eventually get time to look at capturing the USB traffic. Adding a 32 bit counter into the transmitted data, rather than sending the same string would really help for looking through of hundreds of megabytes of captured USB packets. Probably best to just put the 4 bytes right into the string, in big endian format so they're easy to read when looking at hex data.

Edit: On the PC side, of course it would be really helpful if you could capture and print the 32 bit counter from the next correct-length string that arrives after garbage. Then it's be relatively simple to find the exact place within an enormous packet capture to see what USB communication actually happened.
 
Last edited:
Indeed - looking at the same string over and over is numbing and void of usable info, will fix.
> and the "delayNanoseconds( 1500 )" suggests there is time to format as desired a serialized fixed length string.

With the 140Mbps delay limited output Tsermon is still doing well! It is second screen peripheral vision - but not caught any garbage splashes - and it is running. Though hard catch to any of the 1/100000 Mbps print lines ... got:: 3300000 Bytes in 190033 us = 138.92 Megabits per second
>> so they should flash by 5+ times/sec and I'm not seeing them that often - maybe full page draws hide them?

As far as answering THAT 'rhetorical' question - not sure it is the biggie - the errors are still relatively few and it may be computer generated noise from multitasking or ??? But it did jump out as new behavior. The 'stats' below show higher loss than last reported 2X longer run 11am post.
The three show stats of ZERO LOSS at this point with completions of this number of 100K groups of 33 bytes ( 3.3MB each ):
269201 + 237001 + 254601
Click to expand...

ALERT: I just saw an rmax=1992704 and 1988608 on the two running T_4.1's - the c code EXE ( non "Q" ) somehow exhausted a 2MB buffer before another 2MB could gather! Seems 145 MBps may be near steady state for the serialtestT.exe code?
> grabbing the screen data it has happened 12 times out of 643 stat prints
>> stats: 100K=127801 less=27 repeated 2 rmax=1992704
> the other T-4.1 with smaller PowerShell screen buffer shows 331 prints of rmax and 56 are under 2MB
>> stats: 100K=131201 less=30 repeated 2 rmax=1988608

<edit>: Fresh start on two T_4.1 copies of serialtestT.exe not showing ANY errors yet at 3801 sets of 100K
 
Last edited:
Status
Not open for further replies.
Back
Top