ESP32 和 Kotlin 服务器之间的套接字延迟不一致

Question

Context:

• I have a Server (Mac Mini) and a Client (ESP32) that are communicating through a socket connection via the WifiClient class.
• The server is connected to the router by ethernet and the client is connected to the router using 2.4ghz WiFi.
• The server is written in Kotlin and is using the default Java socket implementation.
• The client is to assign the colors to Neopixel LEDs (led 1 and 2, respectively) using the FastLED library.

For the sake of testing, the server is sending FF0000|FF0000 and 0000FF|0000FF (as strings) in an alternating pattern 60 times per second. This test works well because if the color updates at a rate of 60 times per second, the LEDs should look purple. If the system is performing poorly, then I will see the individual colors.

Client Github Repo and Server Github Repo for additional context.

The Problem:

I am very clearly seeing alternating blue, red, and purple. This tells me that there are performance problems somewhere, but there are also brief moments where it performs as expected.

My Findings:

I've been logging the times it takes to read out each message on the client:

std::string SocketManager::getNextCommand()
{
    unsigned long start = micros();

    // TODO: Flush isn't working
    // flush(): fail on fd 56, errno: 11, "No more processes"
    // client.flush();

    // We need to read in our next command; wait until command is available.
    String message;
    while (client.connected() && message.length() == 0)
    {
        message = client.readStringUntil('\n');
    }

    unsigned long end = micros();
    Serial.print("Time: ");
    Serial.println(end - start);

    return message.c_str();
}

The times that print out are generally good, but I get periodic spikes about 10 times per second. I have added a log to Pastebin here .

I thought that the clients buffer was becoming saturated when I first saw this. I then lowered the message rate on the server to 2 times per second, but I still was seeing significant variation in message times. That log is here .

I printed out the system time whenever the server sent a message to verify that it is being written at the correct rate. Updating 2 times a second consistently yields gaps of 500ms, so I think it is reasonable to rule out the server. This would suggest that the issue is either the transit time or ESP32 (considering the server is posting at the specified intervals).

The ping between the two devices is 5-10ms when the socket is not active, but is 50-400+ when the socket is active...even if I'm not sending any messages back and forth. Heck - it's that high even when I completely comment out the client's while loop (ie it immediately returns an empty string).

The Question:

It would seem that my central problem is the latency between the devices while the socket is active. At the very least - the ping increase when the socket is active seems within the ballpark of the latency increase while attempting to read the next command.

Do you think that the socket is the primary problem here? If so - why?

It seems strange to me that such a massive latency increase would occur simply by virtue of a socket being active...especially when not transmitting any sizable data back and forth.

Answer 1

I set the performance preferences and disable TCP delay on the server's socket connection based on this thread .

In the server code I set the ServerSocket performance preferences to 1, 2, 0.

val server = ServerSocket(9999)
server.setPerformancePreferences(1, 2, 0)

I also disabled TCP delay on the connection.

while (true) {
    val client = server.accept()
    println("Client connected: ${client.inetAddress.hostAddress}")

    client.soTimeout = 1000
    client.tcpNoDelay = true;

    // Run client in it's own thread.
    thread { ClientHandler(client).run() }
}

This appeared to make a drastic improvement. There are definitely moments where the lights are (mostly) purple. It does seem like the latency degrades over time and the connection may die, so there is still fine tuning to be done.

So - I think this issue is mostly solved (with some fine tuning). That said, I would still appreciate any further input that anybody has.