Rookie Question: Ethernet PHY and communication buffer sizes

TinyCLR OS
#1

Hi all, this is more of question on what I could be doing to make my ethernet communication faster. We are heavily utilizing VNC across most of the products we make, however, I find myself bottlenecked by what appears to be a buffer issue. the SC20260D doesn’t seem to have any trouble sending an entire frame buffer at once (768 KB, in this case), but on the receiving end I find myself only able to receive about 2KB at a time. It takes about 300 - 350 ms to read the frame off of the socket, depending on the CPU load at the time. I increased the receive buffer size to 1.5 MB on the client socket using socket options, but this doesn’t seem to help.

  • Is there anything else I can check to try to speed it up?
  • is using large buffers helpful or harmful? I have more than enough ram at runtime.
  • There doesn’t seem to be a way to force the link speed to 100 mbits - could this be the issue?

I know this is somewhat open ended, but I’m mostly trying to find ways to improve the user experience. Functionally, it works great, but I’m just trying to make it that much better.

#2

2KB/350ms mean ~6K/sec. This is slow. We will check.

No. But I don’t think it helps if problem is something else.

Auto-negotiation will detect 10 or 100. If not detect active link then 100 is default.

So the setting speed is 99% 100Mbs, unless your network speed is 10 and if this case, force SITCore 100 doesn’t help at all anyway.

#3

Hello, as quick tested, we use Lucas’s example from the link below:

Socket.receive or socket.send crashes entire OS - TinyCLR OS - GHI Electronics’ Forums

The speed is ~25Kbs and this is not maximum because after he got data chunk, he process them, and sender wait for response before send next chunk.

But 25KB/s is much faster than 6KB/s. Mean something causes the speed slow.

Could you send a simple project?

#4

I think the yellow light is on mean 100Mbs already. Look at your yellow light on ethernet port (SITCore)

#5

Yellow light is on - 100 Mbps seems to be active.

#6

My actual data rate is about 2.2 MB/s. I can transmit about 3 frames a second (this is just an industrial remote touch screen and buttons, it’s perfectly usable, just slow) - it takes 350 MS for it to read the full 768KB frame buffer.

I was more saying that every time I read data off the socket it can only read 2KB at a time. it basically will sit and repeatedly poll the socket until all the data is received. the frame processing time is basically negligible - if i do a compressed frame with half the data it can transmit in ~180 ms, so my bottleneck is somewhere in transmission. 100 Mb/s has a theoretical throughput of 6 times that, so I’m wondering if I’m not properly using the Ethernet hardware.

edit: here is my read code

int offset = 0;
int read = 0;
int bytesToRead;
int len = bytesToRead = fb.Data.Length;
lock (fb.Data)
{
    int available;
    while (offset < len && !Timeout)
    {
       while ((available = VncSocket.Available) == 0) //this forces CPU to prioritize reading socket data instead of checking for touch and key events, decreases read time by 20ms or so
          if (Timeout)
             break; 
                              
       read = VncSocket.Receive(fb.Data, offset, bytesToRead, SocketFlags.None);
       // read calls return 2KB or less of data per iteration                         

       offset += read;
       bytesToRead -= read;

       if (Timeout)
           break;


        if (TouchEvents.Count > 0)
        {
             TouchEvent t = (TouchEvent)TouchEvents.Dequeue();
             WritePointerEvent(t);
        
         }
         if (KeyEvents.Count > 0)
         {
              KeyEvent key = (KeyEvent)KeyEvents.Dequeue();
              WriteKeyEvent(key);
         }

    }
    FrameReadTimeout.Change(-1, -1);
}

I was musing that I have a Steam Link, running off of a Cortex-A9 at home which has 100 Mbps ethernet and can handle remote display streaming at 1080P / 60 Hz. While this is not a great comparison as it is a bespoke, highly optimized (likely using some flavor of insane image compression) and fully custom solution and also wildly overkill for my use case, it seems like the horsepower is there, I just need to figure out how to leverage it. It may not be possible with how TinyCLR interfaces with the hardware, which is fine, but I’m more approaching it from the assumption that I’m doing something wrong.

#7

I thought you can read only 2K every 350ms.

But you could get the speed is 2.2MB then it is good, I think.

I don’t think you can get exactly 100Mbs by counting how much data you received. Data you get is actual data. There is frame, header, checksum… a lot happened internally that you don’t see.

#8

TCP overhead is 20 bytes per MTU/packet