Add benchmarks

[baptiste0928]

I think it might be interesting to add benchmarks to get an idea of remoc performance and avoid regressions. This could be done with criterion since it supports async benchmarks.

Benchmarks could also be made to compare remoc to other similar libs like tarpc and with a raw TCP socket (to get an idea of the performance overhead introduced by remoc).

[surban]

This would indeed be interesting.

However, we would need a more elaborate simulation of TCP that takes the latency between two endpoints into account. This is necessary since chmux uses credits-based flow control, which may be negatively affected by the connection latency if the receive buffer is chosen too small for the connection speed.

[dragonnn]

However, we would need a more elaborate simulation of TCP that takes the latency between two endpoints into account. This is necessary since chmux uses credits-based flow control, which may be negatively affected by the connection latency if the receive buffer is chosen too small for the connection speed.

Do you have any comment/opinion about using remoc over Unix Sockets? I can confirm that it works but didn't do any comparison against tcp when it comes to performance

[surban]

Do you have any comment/opinion about using remoc over Unix Sockets? I can confirm that it works but didn't do any comparison against tcp when it comes to performance

It should work just fine when you use Connect::io_buffered. This will minimize system calls by buffering packets internally and performing one system call to send the buffered data when the buffer is full (or no more data is available for sending).

[dragonnn]

Some recommendations for the buffer size? And as far I understand, for regular tcp port io_buffered is not recommend due network having the own buffers already?

[surban]

Some recommendations for the buffer size?

I would choose the same size as the socket send buffer (readable from /proc/sys/net/core/wmem_max and is about 200 KB on my system).

And as far I understand, for regular tcp port io_buffered is not recommend due network having the own buffers already?

The kernel is buffering TCP data before sending it over the network, however without user space buffering you may have a high overhead of system calls. Thus I am also using Connect::io_buffered for TCP and have observed no negative effects so far. I am using a buffer size of 64 KB and have no trouble streaming JPEG live images from a camera connected to a RPi 4 using a rch::watch channel at 30 fps.