hardbyte / python-can / 6691123424 / 5
71%
main: 71%

LAST BUILD BRANCH: dependabot/pip/dev-deps-f500956268
DEFAULT BRANCH: main
Ran
Files 89
Run time 6s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 63.166% (-0.07%) from 63.235%
6691123424.5

push

github

web-flow 
Configure socketcand TCP socket to reduce latency (#1683)

* Configure TCP socket to reduce latency

TCP_NODELAY disables Nagles algorithm. This improves latency (reduces),
but worsens overall throughput. For the purpose of bridging a CAN bus
over a network connection to socketcand (and given the relatively low
overall bandwidth of CAN), optimizing for latency is more important.

TCP_QUICKACK disables the default delayed ACK timer. This is ~40ms in
linux (not sure about windows). The thing is, TCP_QUICKACK is reset when
you send or receive on the socket, so it needs reenabling each time.
Also, TCP_QUICKACK doesn't seem to be available in windows.

Here's a comment by John Nagle himself that some may find useful:
https://news.ycombinator.com/item?id=10608356

"That still irks me. The real problem is not tinygram prevention. It's
ACK delays, and that stupid fixed timer. They both went into TCP around
the same time, but independently. I did tinygram prevention (the Nagle
algorithm) and Berkeley did delayed ACKs, both in the early 1980s. The
combination of the two is awful. Unfortunately by the time I found about
delayed ACKs, I had changed jobs, was out of networking, and doing a
product for Autodesk on non-networked PCs.  Delayed ACKs are a win only
in certain circumstances - mostly character echo for Telnet. (When
Berkeley installed delayed ACKs, they were doing a lot of Telnet from
terminal concentrators in student terminal rooms to host VAX machines
doing the work. For that particular situation, it made sense.) The
delayed ACK timer is scaled to expected human response time. A delayed
ACK is a bet that the other end will reply to what you just sent almost
immediately. Except for some RPC protocols, this is unlikely. So the ACK
delay mechanism loses the bet, over and over, delaying the ACK, waiting
for a packet on which the ACK can be piggybacked, not getting it, and
then sending the ACK, delayed. There's nothing in TCP ... (continued)

6549 of 10368 relevant lines covered (63.17%)

0.63 hits per line

Source Files on job Unittests-macos-latest-3.8 - 6691123424.5