# Native USB port speed not as expected? **URL:** \ **Category:** Due\ **Created:** [October 25, 2021, 4:39am UTC](https://forum.arduino.cc/t/native-usb-port-speed-not-as-expected/918198 "2021-10-25T04:39:22Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![glock\_k](https://avatars.discourse-cdn.com/v4/letter/g/9e8a1a/32.png) [@glock\_k](https://forum.arduino.cc/u/glock_k)\ **Post date:** [October 25, 2021, 4:39am UTC](https://forum.arduino.cc/t/native-usb-port-speed-not-as-expected/918198/1 "2021-10-25T04:39:22Z")
Hi everyone! I'm trying to use Arduino Due for my little project and was expecting the communication bandwidth to be at least ~15MB/s for my use. I saw that the Native port supports up to 480MB/s throughput while Arduino due runs at ~80MHz, so I assumed it would definitely satisfy my request. However, I tried to implement a very simple program testing if I could get the communication right. The result shows the speed is only around 520KB/s. I'm posting my code below - Generally due reads some unsigned int data from the SerialUSB then returns them back. I tried to send 2560 packages and it took about 20 seconds too complete. With the array length of each package being 256 the speed is roughly only 520KB/s, far away from the 480MB/s or 80MHz clock speed can do. I'm very new to Arduino and definitely do not understand how it works very well. Is this just the normal speed or did I do something wrong? Could it be Serial buffer issue or the power supply to the board (I'm only using USB as a power source)? Thank you! ```cpp const int length_pack=256; unsigned int data_in[length_pack]; unsigned int n[2]; void setup() { SerialUSB.begin (230400); //does not matter for Native Port while(!SerialUSB){} } void loop() { if (SerialUSB.available()) { SerialUSB.readBytes((uint8_t*)n,4) SerialUSB.readBytes((uint8_t*)data_in,length_pack*4); SerialUSB.write((uint8_t*)data_in,length_pack*4); } } ``` ---
**Author:** ![westfw](https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/westfw/32/213443_2.png) [@westfw](https://forum.arduino.cc/u/westfw)\ **Post date:** [October 26, 2021, 1:06am UTC](https://forum.arduino.cc/t/native-usb-port-speed-not-as-expected/918198/2 "2021-10-26T01:06:00Z")
> [@glock\_k](#): > > the speed is roughly only 520KB/s While the Due theoretically supports high-speed USB, I doubt whether the Due Serial driver, or the CDC Driver in most host implementations, will implement that sort of speed on a COM port. ---
**Author:** ![Icebuster](https://avatars.discourse-cdn.com/v4/letter/i/9de053/32.png) [@Icebuster](https://forum.arduino.cc/u/Icebuster)\ **Post date:** [October 26, 2021, 2:31am UTC](https://forum.arduino.cc/t/native-usb-port-speed-not-as-expected/918198/3 "2021-10-26T02:31:42Z")
For speed testing, I suggest doing writes in big chunks. Reading/writing 4 bytes at a time is very inefficient for USB. When using 480 Mbits/sec USB the fundamental packet size is 512 bytes. Try writes in 512, 1024, 2048, or 4096 chunks. Whatever you use on the PC should also read in multiples of 512 bytes. Also for max speed, test reading and writing separately. ---
**Author:** ![glock\_k](https://avatars.discourse-cdn.com/v4/letter/g/9e8a1a/32.png) [@glock\_k](https://forum.arduino.cc/u/glock_k)\ **Post date:** [October 28, 2021, 6:20pm UTC](https://forum.arduino.cc/t/native-usb-port-speed-not-as-expected/918198/4 "2021-10-28T18:20:27Z")
> [@Icebuster](#): > > st doing writes in big chunks. Reading/writing > 4 bytes at a time is very inefficient for USB. When using 480 Mbits/sec > USB the fundamental packet size is 512 bytes. Try writes in 512, 1024, > 2048, or 4096 chunks. Thanks for your suggestion Icebuster! However, I think arduino only provides readBytes function for receiving binary data, and as I've tested, weirdly if the board sends out more than 256 unsigned int (1024 bytes, using SerialUSB.write) at a time the read on the PC side would fail. Do you have any suggestion for a better way of implementing this? ---
**Author:** ![glock\_k](https://avatars.discourse-cdn.com/v4/letter/g/9e8a1a/32.png) [@glock\_k](https://forum.arduino.cc/u/glock_k)\ **Post date:** [October 28, 2021, 6:21pm UTC](https://forum.arduino.cc/t/native-usb-port-speed-not-as-expected/918198/5 "2021-10-28T18:21:19Z")
That's indeed what I'm worried about... ---
**Author:** ![anon94801460](https://avatars.discourse-cdn.com/v4/letter/a/278dde/32.png) [@anon94801460](https://forum.arduino.cc/u/anon94801460)\ **Post date:** [October 28, 2021, 7:06pm UTC](https://forum.arduino.cc/t/native-usb-port-speed-not-as-expected/918198/6 "2021-10-28T19:06:13Z")
The Teensy 3.2 would probably be a better choice. Paul Stoffregen spent a lot of time optimizing the native USB serial data transfer. ---
**Author:** ![Icebuster](https://avatars.discourse-cdn.com/v4/letter/i/9de053/32.png) [@Icebuster](https://forum.arduino.cc/u/Icebuster)\ **Post date:** [October 28, 2021, 10:40pm UTC](https://forum.arduino.cc/t/native-usb-port-speed-not-as-expected/918198/7 "2021-10-28T22:40:31Z")
> [@dependence of DUE Native USB port transfer speed on data length](https://forum.arduino.cc/t/dependence-of-due-native-usb-port-transfer-speed-on-data-length/150762): > > I'm working on writing a reusable Arduino \<-\> Python communications library for scientific instruments, and as part of that I would like to transfer data at high speed to Python running on a host PC. I tested the transfer rate from both the programming and native USB ports and don't fully understand the results. I tried transferring strings with 1 to 10000 characters (call the number of characters N). Each string was written with one call to Serial.print() or SerialUSB.print(), and read by a Pyt… ---
**Author:** ![system](https://dub1.discourse-cdn.com/arduino/user_avatar/forum.arduino.cc/system/32/1140315_2.png) [@system](https://forum.arduino.cc/u/system)\ **Post date:** [April 26, 2022, 10:41pm UTC](https://forum.arduino.cc/t/native-usb-port-speed-not-as-expected/918198/8 "2022-04-26T22:41:06Z")
Closed on April 26, 2022, 10:41pm UTC This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.