Teensyduino 1.56 Beta #1

Status
Not open for further replies.
It's not about maximum speed.
It's about maximum reliability.

As long it fixes problems.

Look, the question at hand is whether the memory barriers are actually fixing any problem at all, or whether they just alter subtle timing in a way that makes certain tests run well with certain Windows systems.

The fact that the memory barriers do change performance in some tests is a pretty clear indication this problem is not as simple as you are saying.
 
Oh it's very simple.
It started with the "save to file" test. With H-term. My 10mio lines test.
The logged file shows missing lines. No Garbage.
Added the barriers.
H-Term logging is OK with barriers.*
No missing lines.

So, very simple.
Nice that Linux does not show problems.
But it does not help anything.

Oh, it would be OK if added a delay to that usb_serial. I wouldn't care. As long it does not drop data.

Absolutly simple.
*Edit: And, remember, H-Term is 10 times slower. Edit the Edit: The barrier does not slow down anything here. Magically it works. If you think it's because of the changed speed (What is an unproven assertion), OK
 
Last edited:
Hey, an delay() would have the advantage that it reduces the windows garbage ;-)


I don't care HOW the fix looks like. As long there is one.

Edit:
I had done everything I could - I even wrote a test-tool, I tested several hours. So, remember I'm just a user.
So, "simple" - please make a simple "log to file" work without missing data. I don't care, how.

Thank you.
 
Last edited:
I agree we need a solution for problems with Windows.


I don't care HOW the fix looks like.

I do care what the fix looks like!

I will admit, back in July I sprinkled several (probably) unnecessary memory barriers over the code. That is a trend I do not wish to continue. At the time PJRC has just rehired and we were terribly far behind from over a year of running short-staffed. In July there was no chance for carefully evaluating whether the memory barriers were really doing anything useful.

If the problem truly is a synchronization issue causing Teensy to transmit wrong data, then I want to find and fix the real problem. I do not want to continue adding more unnecessary memory barriers on a purely speculative basis. In fact, I want to investigate if the barriers we currently have really are needed. They probably are not necessary.

Clearly this Windows problem is bigger than just receiving and discarding data in a simple test program. I will (later) experiment with rewriting teensy_serialmon.exe. Currently it is structured at 3 threads, where tasks are performed on the main thread using Overlapped IO. I want to try a 5 thread model, so we can use ReadFile() without Overlapped IO, as this test program does.

I know you just want a quick fix and you don't care whether it is technically correct. I need you to understand that I do care about correctness and actually understanding the problem.

But if we get close to 1.56 release and the Windows is still a problem, I will consider an ugly temporary workaround for Windows, even if it hurts performance on MacOS and Linux.

At this moment, 1.56 release is a long way off. I'm not ready to settle for an ugly workaround at this time. I do care very much how the fix looks.
 
Try setting Tools > Optimize to Debug (and use the toolchain shipped with Teensyduino). Does it still magically work?

I guess it works. Of course it will work.

It stops moving the no_autoflush writes around (optimization). You know the ...:::"memory" stops that, too. It means the write has to happen before :::"memory". The "volatile" is not sufficiant, as (i hope) you know.
In addition it makes the whole program slower. Or is it that what you wanted? Would be better to slow down USB only. Sure it works to slow that down. I said that maybe 5 times?

My goal was to find a way that *not* slows down too much.

But if that's your poposal for a fix... I'd add a no-optimize attribute to the usb code only.

@others: Volatile just means "do access that memory location before the next sequence point". But it does NOT say, when this has to happen. GCC can move that around - not everywhere but It can happen that it is i.e. 50 cycles earlier. Or later. To write a value that it needed to in an interrupt, asap, it's way not enough. This is no exact definition, but good enough here.
So, what happens in usb_serial.c is, that the autoflush runs when it should not.

Want a wikipedia link?
A quote:
"in C and C++ it does not work in most threading scenarios, and that use is discouraged." [...] "Operations on volatile variables are not atomic, nor do they establish a proper happens-before relationship for threading."

(Here, read threading = interrups)

Well.. ":::"memory" does that. And the dsb/dmb makes sure the pipline does it too.
 
Last edited:
Did you try it?

When I run it here compiled for debug, the problem is much worse, even though the data is slower. After about an hour, my Windows 10 test machine crashed with a blue screen of death.
 
You might be interested to know that I fixed maybe half dozen bugs in the core by adding barriers. Last was in the eeprom code.


No but I can try this evening.

So, why is it worse? Must have a reason.
 
Ok, tried it.
H-Term logged a wonderful perfect file.
Wanted to attach it here, but it's even zipped too large.

Have not tried the serial monitor.
What _exactly_ do you want me to test?
 
Paul, even if you don't believe me, please trust the Wiki-Text (in this case)
And even in the case that it does nothing to fix the problem the text says you need barriers ;) And even if there is no problem -the way it is implemened now would work by pure accident. The volatile does not help.

btw, yield needs a barrier, too.

"Thus, the usage of volatile keyword as a portable synchronization mechanism is discouraged by many C/C++ groups"

Of course, you can bring out even heavier guns than ::memory. But I don't think that's necessary.
However, as Tim said, there are still a few missing packets.... so... I'm not really 100% sure. Can be an additional race we don't see at the moment. Or indeed you need the heavy thread-sync guns. std::atomic<T>
 
Last edited:
Ran overnight with last PJRC edit of usb_serial.c here is the screen shot showing skips on screen turn on:
serialTestPJRCusb_wake.jpg

then after print of stats on the three since last post:
serialTestPJRCusb_wake.jpg

That shows a long triple teensy run on Windows can work uninterrupted at those speeds.

How The Teensy USB link can detect 'PC' distraction and pause - not sure.

Can't say for sure anything has changed - as noted some runs give alternate results of the same test it seems - and sometime windows has to sync with desired behavior to route the data on startup?

Last posted numbers:
Code:
** at 8001 (and 10001) that one is less=10 and repeated 162 (the .X_'s)
Another perfect 0 loss at 10001, and loss=3 on the third.

and Now:
Code:
** at 212001 (and 10001) that one is less=16 and repeated 162 (the .X_'s)
Another  6 loss at 210001, and loss=12 on the third at 222001.

Did a recursive root DIR in another DOS box - it jumped an alternate CPU core form 20 to 80% - and did not affect the SerialTest ... expected it to use the same core like the three serialtest boxes are.
 
Last edited:
Thank you Tim.

Teensy detects i.e. a timeout. The code is written in a way that the it does not stall - after some millicseconds (don't remember - 120?) it stops trying sending data.
120ms is, however, a long time. For USB. The PC shouldn't stop that long if there is a program that trys to get data.

You can test this with a digitalWrite that toggles the LED. I bet you can switch it on and off if you use your "scrollback" trick!
Edit: I think the serial Teensy can do the same (timeout on Teensy) if it pauses for some 10 seconds.
However _that_ is not the issue I'm trying to fix or to find a workaround for.

Last edit of usb_serial -
last PJRC edit of usb_serial.c
- was three months ago. It was the issue with missing data. Yes, that fix helped. As I know now, unfortunately it did not fix it completely.

Ok, late (again) I would have tested the "Optimize for debug" more, but I still don't know what Pauls _exactly_ wants to test. My "save to file" test worked good.

And Paul, yes, the issue gets worse when Teensy has to send slower, because the RX on PC is slow - as with most programs (at least on Windows? ).

So, just,
Good night.
 
Last edited:
Opps that was last FORUM EDIT - on prior page of this thread. p#183 :: pjrc.com/threads/68291-Teensyduino-1-56-Beta-1

Last edit of usb_serial -
last PJRC edit of usb_serial.c
- was three months ago. It was the issue with missing data. Yes, that fix helped. As I know now, unfortunately it did not fix it completely.


Made the p#213 and left machine a few hours.

AGAIN on return to machine and 'unsave' the black screens Windows Jitters the USB - and added three missed (sub)groups:
View attachment 26091

and after that in tabbing around one of the three did a super SPAZ: >> stats: 100K=374001 less=32 repeated 8613
Code:
Lines-Delta: 100000. Received: 3300000 Bytes in 123319 us = 214.08 Megabits per second
..................................................
Lines-Delta: 100000. Received: 3300000 Bytes in 127738 us = 206.67 Megabits per second
..................................................
Lines-Delta: 100000. Received: 3300000 Bytes in 139034 us = 189.88 Megabits per second
........................
X_Lines-Delta: 47633. Received: 13579abcdefghijklmnopqrprovidesupport
X_Lines-Delta: 0. Received: .X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_
X_Lines-Delta: 13167. Received: 13579abcdefghijklmnopqrstuvwxyzα╞^
X_Lines-Delta: 0. Received: .X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_.X_..........................
Lines-Delta: 100000. Received: 3300000 Bytes in 123476 us = 213.81 Megabits per second
..................................................
Lines-Delta: 100000. Received: 3300000 Bytes in 124549 us = 211.96 Megabits per second
 
The .c code is doing good keeping up with the incoming USB data. Not sure how close the code is to not keeping up - even without prepping and stuffing the system with GUI overhead. Breaks seem to relate to PC losing USB continuity in the stream? Not sure how to see or prove otherwise or to prevent or recover from that?

Big cascades of errors ".X_.X_. ..." like p#215 show a rare disturbed data stream - hidden but perhaps it was that rare garbage?

@Paul - if USB1 and USB2 are same hardware/code as USB - then it seems the same code as tested for USB should be propagated? Until the Code4Code used USB1 to send out 3MB of code the compiler verified as 'broken' without hand coded delayMicroseconds() - it was generally the 'slow debug stream' for major events as I've used it. It could be quickly changed to run serialtestT.exe against a sketch with USB1.

Going to the .c code to add a counter to track incoming pased bytes ...
> added a byte count as parsed - only make sense to print on error - errors are few and far between and doesn't add much. - just shows like '56' which is the portion of the buffer printed.
--> somehow the \n newlines are missing across the end of one string to the start of the next - this shows in the printed 'partial' lines.
-->> not sure if that is up to the PC to process or anything to do with Teensy when pushing the packet?

Increased 1MB buffer as it was always getting 1MB between stats prints. Made it 2MB and it is always read()'ing 2MB between stat prints - so Windows is buffering it upstream and always happy to offload 2MB
> even with changed stat prints to 200 100K groups from 2000
> did not increase Mbps throughput - single or triple USB runs.
> even a quick DOS box select 'pause' causes packet miss
 
Last edited:
Can you buffer 225,337,344 bytes

Doing : 'Ctrl + A' ... pause ... 'Spacebar' to resume EXE'cution:
Code:
X_Lines-Delta: 77002. Received: 3300000 Bytes in 89851 us = 293.82 Megabits per second
 bytes: 55.....
X_Lines-Delta: 44938. Received: 13579abcdefghijklAAAADwv79djwAAAAAAw12PAAAAAAAAAAAAAADwvz9fjwAAAAAAQ1+PAAAAAAAAAAAAAADwvzdgjwAAAAAAO2CPAAAAAAAAAAAAAADwv3NhjwAAAAAAd2GPAAAAAAAAAAAAAADwv2VijwAAAAAAaWKPAAAAAAAAAAAAAADwv1NjjwAAAAAAV2OPAAAAAAAAAAAAAADwv9JkjwAAAAAA1mSPAAAAAAAAAAAAAADwv2lmjwAAA bytes: 256
X_Lines-Delta: 319. Received: 13579abcdefghijkl13579abcdefghijklmnopqrstuvwxyz
 bytes: 49

Doing that (takes a few times) trying to trigger the ".X_" case to see how much data Windows is buffering. Once it started it cascaded a bit.
Of course it cascades because this gets the buffer WAY out of sync discarding 52MB to 225MB of data until it happens upon a valid series to restart. That could be hidden - but this shows the nature of the problem at hand pretty well?
Code:
X_Lines-Delta: 56432. Received: á'v▼°^ bytes: 256
X_Lines-Delta: 0. Received: ë!°^ bytes: 256[B][U][COLOR="#FF0000"].X_[/COLOR][/U][/B]256       [B][COLOR="#FF0000"]Bufdump of 111,694,464[/COLOR][/B]
.X_4    Bufdump of 113760256
.X_40   Bufdump of 53325824

X_Lines-Delta: 0. Received: defghijklmnopqrstuvwxyz
 bytes: 24.X_24 Bufdump of 52,921,216

X_Lines-Delta: 0. Received: defghijklmnopqrstuvwxyz
 bytes: 24.X_8  Bufdump of 55,234,560

X_Lines-Delta: 0. Received: lmnopqrstuvwxyz
 bytes: 16.X_56 Bufdump of 109,222,784

[B][COLOR="#FF0000"]X_Lines-Delta: 0. Received: lmnopqrstuvwxyz
 bytes: 16.X_8  Bufdump of 225,337,344[/COLOR][/B]

X_Lines-Delta: 0. Received: tuvwxyz
 bytes: 8.X_56  Bufdump of 223,400,832

X_Lines-Delta: 0. Received: defghijklmnopqrstuvwxyz
 bytes: 24.X_56 Bufdump of 168,613,888

X_Lines-Delta: 24448. Received: efghijklmnopqrstuvwxyz
 bytes: 23
X_Lines-Delta: 2444. Received: 3300000 Bytes in 238248 us = 110.81 Megabits per second
 bytes: 56..
Lines-Delta: 100000. Received: 3300000 Bytes in 110009 us = 239.98 Megabits per second

As "FAST" as this .c code with no GUI SPEW may be - Windows is buffering a large amount of data!

On the FIRST trigger there was "Bufdump of 111,694,464" data ready for the EXE - even throwing it away as fast as possible wouldn't catch up fast enough with the next set of processing.

225,337,344 is 68 sets of 3.3M ... over 7.5 seconds of runtime at 114ms per 3.3M at 230 Mbps

This code needed the 'Bufdump' print moved outside the do{}while - when inside the time of print never let it get to zero - so rewrote to SUM in rr and print on exit:
Code:
            else {
              if ( 0!= stats[0] )
                stats[2]++;
              printf( ".X_%lu", bcnt );
              SSIZE_T rr=0;
[B]              do {
                r = read_port(port, buf, sizeof buf);
                rr+=r;
              } while ( r >1800000 );[/B]
              printf( "\tBufdump of %I64u\n", rr );
            }
 
Maybe I have good news.
Tim, can you test this?

Code:
        uint8_t *txdata = txbuffer + (tx_head * TX_SIZE) + (TX_SIZE - tx_available);
        if (size >= tx_available) {
[COLOR=#ff0000]            timer_stop(); //<-- insert here[/COLOR]
            memcpy(txdata, data, tx_available);
            //*(txbuffer + (tx_head * TX_SIZE)) = 'A' + tx_head; // to see which buffer
            //*(txbuffer + (tx_head * TX_SIZE) + 1) = ' '; // really see it
            uint8_t *txbuf = txbuffer + (tx_head * TX_SIZE);
            usb_prepare_transfer(xfer, txbuf, TX_SIZE, 0);
            arm_dcache_flush_delete(txbuf, TX_SIZE);
            usb_transmit(CDC_TX_ENDPOINT, xfer);
            if (++tx_head >= TX_NUM) tx_head = 0;
            size -= tx_available;
            sent += tx_available;
            data += tx_available;
            tx_available = 0;
[COLOR=#ff0000]//            timer_stop(); //<-- comment out[/COLOR]
        } else {

Yout "Scrollback" trick works much better now on my system. I see missing lines - of course, the program stops - but no garbage after scroll back.
Also, I have the impression that it faster reaches reliabale working after start.

Would you try that?
And after that, maybe with the additional barriers? (you can add them without the "DSB" so that paul has fewer problems with it...)

Thanks!
 
Maybe I have good news.
Tim, can you test this?
...

Yout "Scrollback" trick works much better now on my system. I see missing lines - of course, the program stops - but no garbage after scroll back.
Also, I have the impression that it faster reaches reliabale working after start.

Would you try that?
And after that, maybe with the additional barriers? (you can add them without the "DSB" so that paul has fewer problems with it...)

Thanks!

The usb_serial.c code running here is Paul's latest (linked above prior page) code that has timer removed. So that edit won't work here.

Did you see the crossposted note on the amount of buffered data?
 
Yes I saw that.
And it buffers the missing lines the Teensy sends, too.


I don't see garabage on putty, coolterm, tera term anymore. Have to correct me: the "dsb" is needed on some places (but not everywhere).
Let it run in coolterm now for a longer time.
Edit: To be clear: This seems to be a way to reduce the garbage - not missing lines.)

Edit: So far no garbage in coolterm.
2021-10-06 09_21_32-Window.png

Had not exepcted reduced garbage... goal were still the missing data.
Seems way less than before.

Edit: Ok, saw garbage now.
 
Last edited:
Yes I saw that.


I don't see garabage on putty, coolterm, tera term anymore. Have to correct me: the "dsb" is needed on some places (but not everywhere).
Letting it run in coolterm now for a longer time. (Putty is "medium" fast.. ;-)

If you post a COMPLETE copy of the usb_serial.c { here or github as alternate ) I'll let that run here overnight ...
 
Thx, not needed.. I think what I saw was random. However it lastet pretty long.

I think I'll don't invest more time in this.
Its just not possible to get it *really* reliable running without delays in the user code.
The barriers reduce the problem but it's still existent.

Edit: And as long the Windows "garbage" bug exists, it's all pretty pointless.

Ok, have fun.. and bye here.
 
Last edited:
Okay Frank. Will wait for next change/Beta from Paul.

All three running again - now all T_4.1's to simplify sketch changes. Last change was to usb_serial.c posted with no timeout/callback.

They all three run FINE in general - with no signs of trouble or errors in steady state.

With all three running one was interrupted - only took twice - with "Ctrl+A ... SPACEBAR" {or the Pause key} - the other two continued to run without error:
Code:
Lines-Delta: 100000. Received: 3300000 Bytes in 129596 us = 203.71 Megabits per second
................................................
X_Lines[B]-Delta: 128983[/B]. Received: 3300000 Bytes in 121050 us = 218.09 Megabits per second [B]// First caused this miss[/B] - somehow the -Delta count over 100K! so (200000-128983) groups of 33 bytes were lost?
 bytes: 56..
Lines-Delta: 100000. Received: 3300000 Bytes in 130696 us = 202.00 Megabits per second
.......
X_Lines-Delta: 84999. Received: 13579abcdefghijk◄ bytes: 256    [B]// Second caused this cascade[/B]
X_Lines-Delta: 0. Received:  bytes: 76[B][COLOR="#FF0000"].X_256    Bufdump of 168520448[/COLOR][/B]     // 168,520,448 Bytes read --- then it cascades : limited below
.X_7    Bufdump of 145582080
.X_16   Bufdump of 195336192
.X_24   Bufdump of 47552512
.X_8    Bufdump of 96835584
.X_16   Bufdump of 47116288
.X_8    Bufdump of 47769600
.X_16   Bufdump of 1318912
.X_24   Bufdump of 45627392
.X_16   Bufdump of 48441344
.X_8    Bufdump of 46905344
.X_8    Bufdump of 47454208
.X_8    Bufdump of 47448064
.X_8    Bufdump of 48769024
.X_16   Bufdump of 47757312
.X_40   Bufdump of 293232640

X_Lines-Delta: 7583. Received: defghijklmnopqrstuvwxyz
 bytes: 24
X_Lines-Delta: 88234. Received: 3300000 Bytes in 129159 us = 204.40 Megabits per second
 bytes: 56...........................................
Lines-Delta: 100000. Received: 3300000 Bytes in 127343 us = 207.31 Megabits per second
..................................................
Lines-Delta: 100000. Received: 3300000 Bytes in 131496 us = 200.77 Megabits per second
        stats: 100K=2001 less=5 repeated 16 rmax=2000000

This 100+MB explains the runon of SerMon long after a Teensy stops transmitting. Windows buffers a HUGE amount of data well in excess of what can be processed. Then one slight 'processing Pause' by the app ( from Windows or whatever ) limiting throughput - must exceed Windows capacity/tolerance for cohesive buffering.

Here is with the cascade limiter in place to stop repeat triggering - it retriggers once showing a large buffer accumulating again.
> of course the 'Ctrl+A' builds an abnormally large buffer of 34,576,512 Bytes ( failed to trigger with 60+ tries with single T_4.1, it triggered quickly with the other two running )
- the single cascade though returning to running triggered then with a buffer of 191,428,608 Bytes, then it found a start and completed a set of 100K blocks.
Code:
Lines-Delta: 100000. Received: 3300000 Bytes in 130105 us = 202.91 Megabits per second
...........
X_Lines-Delta: 19136. Received: 13579abcd******************************************************************************************************************************************************************************************************************************************************* bytes: 256
X_Lines-Delta: 0. Received:  bytes: 256.X_256   [B]Bufdump of 34576512[/B]

X_Lines-Delta: 0. Received: fghijklmnopqrstuvwxyz
 bytes: 22.X_8  [B]Bufdump of 191428608[/B]

X_Lines-Delta: 16908. Received: 3300000 Bytes in 128947 us = 204.74 Megabits per second
 bytes: 56
X_Lines-Delta: 13270. Received: tuvwxyz
 bytes: 8
X_Lines-Delta: 14303. Received: 13579abcdefghijklmnopqrs13579abcdefghijklmnopqrstuvwxyz
 bytes: 56
X_Lines-Delta: 86729. Received: 3300000 Bytes in 251589 us = 104.93 Megabits per second
 bytes: 56.......................................
Lines-Delta: 100000. Received: 3300000 Bytes in 134461 us = 196.34 Megabits per second

Sketch unchanged - but this 'Dump Happy' version on extreme error posted : AltVersion/serialtestT.c
 
A little summary to bring Paul up to speed:

- Windows USB CDC is not slower than other OS.
- With the current code sometimes complete USB packages are missing. For whatever reason.
- the barriers are 1. necessary, and 2. they slow down the code only marginally. Mainly because of this:
- The benchmark measures the speed of the PC software.
- With the current code, no speed increase is visible by overclocking.
- Its needed to run the serialtest several hours.
- Teensy monitor is still not fast enough, and I strongly doubt that it is feasible to speed it up massively. Unless it intentionally skips a few million lines every now and then, and then aborts the output. That would be a workaround.
- Windows USB-Serial has a memory problem. Also with other MCUs.
- As long as the Windows bug exists no reliable high speed transfer is possible. Delays are necessary. Just because of the memory problem.
- Therefore it is of little use to rewrite the code completely. At least not for Windows.
- yield() and possibly more code needs a fix.
- For the sake of reliability it might even be necessary to slow down TX on purpose.

More work should be put into other protocols instead. HID seems to be slow to me. Maybe PJRC can provide a tool that makes it easier to use (for the purpose of data transfer) on the PC. No, not for me, don't worry. I speak for the other users.
 
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.
 
Status
Not open for further replies.
Back
Top