RAHID performance

Status
Not open for further replies.
@frankb I am not sure that the teensy monitor will survive prolonged high speed transfers, or how you would prove it. For one thing it probably couldn't keep up in the display. So it is not really that relevant. But by all means, crank it up to 1MB/s and let it go a for a few hours and lets see what happens. Make sure to browse the web and process a few emails while its working.

Again, hard real time vs soft realtime.
 
Make sure to browse the web and process a few emails while its working.
.

I would suggest, to have the teensy also on a USB hub with a WD 1TB SSD disk that blocks the USB for >15 each time when waking up! (I have such a disk on my desk)
 
So, why this discussion? You say it is not possible -- why this thread, then? I think for my side, i've said all and gave enough hints and ways to make it more reliable.
And no, my (slower than yours) PC had never problems, even with 3 videos running in the background.

Have luck,
Frank

(hope you get it running and tell us about the bugs you found. we had theses discussions several times.. several topics.. (i.e. not serial).. each time it was a bug in the user code)

And give x/y/z modem a chance.
 
The p#21 github linked Teensy code runs against SerMon for just a visual integrity test.

Run that code on T_3.2 against SerMon - then slow it down to the data rates needed in the use case at hand 5-10 times - it will work against SerMon. At that rate even the IDE built in slower Java code versus optimized for T_4.x speed code by Paul.


"C" code came form 'somewhere' - and ran on Windows - and was randomly hacked and tweaked ... it is here somewhere, not seeing it was posted to github
 
@frankb I am not sure that the teensy monitor will survive prolonged high speed transfers, or how you would prove it. For one thing it probably couldn't keep up in the display. So it is not really that relevant. But by all means, crank it up to 1MB/s and let it go a for a few hours and lets see what happens. Make sure to browse the web and process a few emails while its working.

Again, hard real time vs soft realtime.

This was done during Paul's pjrc teensy_sermon testing against the 10+MB T_4.x
 
Walter, sure, if the USB is maxed out, what should happen? :) You need a flow control. But we said this. Blindly sending data and just hoping that they arrive does not help. Don't trust the PC.
That all not new. Pretty old stuff, million times used. Not sure why today's user think they don't need that. For me, it's a bug not use a flow control / protcol, if it should be reliable. These are basics.
With zModem, your data is OK, even is USB is 20 seconds down :)

And.. yes, it might be needed to switch to USB 2.0 (Teensy 4) to get more headroom. But that's even worse with python..
 
Last edited:
Well there are plenty of posts on other forums on transfer problems over serial for arduinos. If there is a bug it's in pyserial or the serial driver.

The original post was about performance for RawHID. That was answered a long time ago, it is the polling clock. Hence the need for something that is USB and not HID.
 
The USB Specifications are availaible via WWW. Reference Manual for the Teensy is on pjrc.com. I don't think anybody has written such a thing for Teensy - and you need a low level PC driver, too. You'll ned a handshake, there, too. Pretty similar to a handshake over emulated serial...

Easier to get the existing stuff working .. :)
 
@FrankB Just picked up on a detail in your note.

According to Paul, flow control is built into the USB protocol that transfers the serial data. It sounds like it is supposed to be a reliable transfer, in the formal sense of the term. That means there should be clean errors returned, and not crashes or hangs, when it fails.

That it runs in c-code with a light load does not bear on the problem except to say the hardware is capable of the transfer rate.
 
@FrankB PyUSB seems pretty good actually. I am using it for this, and to talk to the usb adapter for an ocean optics spectrometer. It is layered on libusb.
 
FlowControl: PY's problem is a layer higher.
Ok, then use libUSB.

maybe, someday, when it rains and it is cold outside, and the end of the world is near, I write some code for reliable RX in python. Or I just port one of the old existing protocols... to teensy and use a 40 year old program on the pc, just for fun.
 
I am not sure that the teensy monitor will survive prolonged high speed transfers, or how you would prove it. For one thing it probably couldn't keep up in the display. So it is not really that relevant. But by all means, crank it up to 1MB/s and let it go a for a few hours and lets see what happens.

It does indeed keep up. I'm personally tested this many times. You can too, without writing a single line of code. Just put this program on your Teensy

https://github.com/PaulStoffregen/USB-Serial-Print-Speed-Test/blob/master/usb_serial_print_speed.ino

Then open the Arduino Serial Monitor and let it run as long as you like. I've personally let it run for days with Teensy 4.0 which transmits so much faster than any Teensy 3.x board! Windows has some issues, but Linux is highly reliable.

If I thought there was a genuine issue here, I'd run it yet again. But everything about this thread looks like a very high ratio of complaining to actual test results demonstrating the problem. @DrM - if you want me or others to take this concern about USB serial speed & reliability seriously, you need to actually show us the tests you've done.
 
Did a little test:
Code:
void setup() {
 Serial.begin(9600);
 delay(10000);
 for (int i=0; i<100000; i++)
    Serial.print("123456789\n");
}

void loop() {}

Opened Teraterm (EDIT: no, sry, H-Term), logged output to file.

Not a single missing or wrong byte. Ok, i used a T4, was too lazy to take the 3.2 out.. NOTE: MUCH faster than a T3.2
Ir you don't believe me, here is the file (997k packed to about ~2k - fantastic ;) ):

I had IP-Live TV running in the background (VLC) on my 3rd screen, and yes, my email-program, github client, my always running "winamp" (muted). and excel with a large sheet. Edit: Almost forgot to mention Arduino... and H-Term. Not to mention all the windows-typical background stuff... like firewall and myriads of "services".

And even WITHOUT protocol or flow control.

All this with a old AMD Ryzen 5 2.4GHz, running Windows.
So... again.. if python can't do this, don't use it. Or add a protocol.

There isno reason to invent a new USB transfer and to spend weeks implementing it.

Edit: did it again and measured the time. 41 Milliseconds for 1e6 bytes. Edit: is that ~23MegaBytes /s?
So much for "computer sience"

@Paul: would be awsome if you *someday* added a "Log to file" to the serial monitor.
 

Attachments

  • output_2021-08-01_23-14-02.zip
    2.1 KB · Views: 66
Last edited:
would be awsome if you *someday* added a "Log to file" to the serial monitor.

Yes, that would be really nice!

As you know, I'm currently working on flash encryption, and after that I'm going to give into NativeEthernet and try to fix the server port exhaustion bug.

But sometime later this year I am going to work on the serial monitor. The Arduino devs want to finalize a pluggable serial monitor protocol using localhost TCP/IP... and I'm wanting to get away from the mistake of using stdin/stdout on Windows. I will be asking for help beta testing when working on that, so then would be a perfect time to remind me about logging.

At this moment (putting a simple GUI on top of the encryption stuff) the idea of more Java isn't very appealing. Just spent half this weekend dealing with kludgy Java GUI stuff like JLabel doesn't support size constraint by the layout stuff like GridBagLayout & GridBagConstraints & setMaximumSize(), but does if you embed html+css in the label text.
 
.. html/css for a label?

Modern times.

Yes, If I don't forget it, I'll remember you...
 
Last edited:
@PaulStoffregen

I started a thread for the Serial transfer problem and provided code and results,

https://forum.pjrc.com/threads/67870-Test-of-Serial-Transfer-fails-for-large-transfers


This thread was to ask a question about USB. I really did not intend to have a long discussion about the problem I am having with the serial interface, and posting code on that point seemed unrelated to the original question. But since that was a point of contention, I posted the above.

The motivation for an all USB solution, is code portability. I want to avoid having to write a c code to go between python and the serial interface, and, then write another for each platform that this will run on. And, anyway it would be just another layer of queuing that I would rather do without.

Or, another way to look at it, PyUSB seems to work better than PySerial, so I want to use USB if I can.
 
Last edited:
Status
Not open for further replies.
Back
Top