Serial ports slow to open (500 mSeconds).

I have a custom application that uses standard serial ports along with the standard modem control lines (DTR, DSR etc). I have noticed with Sequoia that the call to open a port went from 10mSeconds to 500mSeconds regardless of machine architecture (M1, M2, Intel etc). Has anyone else experienced this and / or have a solution? The issue with the delay is that I am using one of the control lines as a control signal and need to get the state of the line changed to the opposite of the default immediately after opening the port.

Mac mini, macOS 13.5

Posted on Sep 18, 2024 1:51 PM

Reply
Question marked as Top-ranking reply

Posted on Feb 17, 2025 1:06 AM

I've found a workaround for this: keep the file open forever. In my case,

exec {fd}>/dev/**.usbserial-DK0IN5ZV


Other processes (e.g. scripts, picocom, pyserial) can still access /dev/**.usbserial-DK0IN5ZV.

Keeping the file open saves 0.5s open time + 1.5s close time.

I can't use tty.usbserial anymore, but **.usbserial is adequate for my needs.


And when I want to close it,

exec {fd}>&-

14 replies
Question marked as Top-ranking reply

Feb 17, 2025 1:06 AM in response to MrSilkyMac

I've found a workaround for this: keep the file open forever. In my case,

exec {fd}>/dev/**.usbserial-DK0IN5ZV


Other processes (e.g. scripts, picocom, pyserial) can still access /dev/**.usbserial-DK0IN5ZV.

Keeping the file open saves 0.5s open time + 1.5s close time.

I can't use tty.usbserial anymore, but **.usbserial is adequate for my needs.


And when I want to close it,

exec {fd}>&-

Dec 2, 2024 7:54 PM in response to telescope_dog

Interesting about the manufacturer app functioning without delay. I don't have a PL2303 on hand to test, but I confirmed that my FTDI devices have a long delay just for the `open()` and `close()` syscalls on Sequoia 15.1.1. The below code compiles with clang, so you can build and run with `clang -o porttest porttest.c && ./porttest /path/to/port`.


#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <time.h>
#include <unistd.h>

double diff_timespec(const struct timespec *lhs, const struct timespec *rhs)
{
    return lhs->tv_sec - rhs->tv_sec + (lhs->tv_nsec - rhs->tv_nsec) / 1000000000.0;
}

int main(int argc, char ** argv)
{
    if (argc != 2)
    {
        printf("Usage: %s <port>\n", argv[0]);
        return 1;
    }
    for (int i = 0; i < 5; ++i)
    {
        struct timespec start, opened, closed;
        clock_gettime(CLOCK_MONOTONIC, &start);
        int fd = open(argv[1], O_RDWR | O_NONBLOCK);
        if (fd < 0)
        {
            printf("Opening %s failed with errno %d (%s)\n", argv[1], errno, strerror(errno));
            return 2;
        }
        clock_gettime(CLOCK_MONOTONIC, &opened);
        printf("opened %d in %lf\n", i, diff_timespec(&opened, &start));
        if (close(fd) < 0)
        {
            printf("Closing %s failed with errno %d (%s)\n", argv[1], errno, strerror(errno));
            return 2;
        }
        clock_gettime(CLOCK_MONOTONIC, &closed);
        printf("closed %d in %lf\n", i, diff_timespec(&closed, &opened));
    }
}


I consistently get ~0.5 seconds to open, ~1.5 seconds to close:

❯ clang -o porttest porttest.c && ./porttest /dev/my-port-devname                                                                                                                                                            10s 19:45:11
opened 0 in 0.513056
closed 0 in 1.509778
opened 1 in 0.511126
closed 1 in 1.509884
opened 2 in 0.516253
closed 2 in 1.507144
opened 3 in 0.512745
closed 3 in 1.508266
opened 4 in 0.511512
closed 4 in 1.50949


Oct 10, 2024 1:16 AM in response to MrSilkyMac

Hello,


I have encountered a similar issue after updating to Sequoia (15.0.1).


When comparing the log timestamps while running my app on previous macOS version (14.5) and current (15.0.1), I noticed an approximate 2-second delay before the close function completes.


I am using an FT2232-based adapter, and I observe the same behavior between both recent versions (15.0 and 15.0.1).


This issue seems to occur on both M-series and Intel-based Macs.

Nov 28, 2024 5:40 AM in response to peterk24

I have little else to offer, but have been scouring the internet for a clue on my issue and this is the closest discussion I've found. I control a "goto" telescope mount with my M1. The mount is a PL2303-based device. As with you all, no problems with previous versions of MacOS, but I'm noticing delays similar to these with every command that I give my mount, which renders it unusable (for example, it has to execute guide commands with minimal latency to keep it centered on an object, which isn't remotely possible with delays this long).


I've found one piece of software, from the mount manufacturer, that functions without any delay, so I know that it's possible to use this device with Sequoia. Unfortunately that software doesn't have all of the functionality that I need, and suffers from other issues besides...


Unfortunately driver-writing is beyond my personal technical capabilities. Do we think this is an issue with the PL2303/FTDI drivers, and/or the transition from KEXT to Driverkit, or something else? Since the mount manufacturer's software functions without any delay, I wonder if the problem occurs between the control software and the driver itself? I'm at my wit's end here...

Nov 29, 2024 2:38 AM in response to telescope_dog

I am trying to refactor the part of my app that is responsible for detecting connected devices (open port, send payload, receive, close port...) moving all the serial port calls to a different thread.


Although in my case it solved the freezing issues, it also brought a whole lot of other different problems. When running the same app bundle - runs fine in Sonoma, but crashes on Sequoia... (this is now a completely new issue... AFAIK this is not related...)


So this issue has to be related to how a certain applications use the serial ports (what function calls they use, app structure, used frameworks, libraries...) some may be affected, in others it may not even be noticeable.



Does the application you're using automatically detect the connected device? Or do you have to manually specify it somewhere (pick a concrete port).

Because if it does some sort of detection in the background at all times, it could be causing slowdowns in the rest of the application (trying to scan device on a new different port, opening it - causing the freeze and affecting the active communication for the other port).


Well, restructuring my own application is one thing, but how to solve this issue for existing software, that does not get updated / cannot be modified etc? I have no idea.




Nov 29, 2024 8:09 AM in response to MrSilkyMac

Having similar issues since upgrading to Sequoia. I use an ESP-Prog to program an ESP32-based custom PCB. It worked flawlessly upto and including Sonoma, but on Sequoia, uploading causes the board to reboot before the upload starts, and (more critically) when it switches over from uploading to monitoring the serial output from the board, the first couple of dozen lines are corrupted. In other words it's not just an annoying delay, but also causes a synchronisation error that can cause data loss.


I'm using the FTDI VCP driver 1.5.0 from ftdichip.com to provide the /dev/tty.usbserial-* device required by PlatformIO. I've tried completely uninstalling and reinstalling it and the result is the same.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Serial ports slow to open (500 mSeconds).

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.