Closed PeterBowman closed 3 years ago
Use TCP instead of UDP in dumpCanBus (ref)?
Better "fast_tcp" than "tcp", see Port and connection protocols, Configuring YARP Connections and https://github.com/robotology/community/discussions/258.
Tested on the left arm. With syncPeriod
equal to 50 ms, I usually get a ~15-16% CPU usage, with or without a dump port (regardless of being used or not). With the default 0.1 ms delay in RW threads, blocking writes on this port seem to have no effect. Disclaimer: node ID24 is dead, besides I am not using SYNCed RPDOs.
With syncPeriod
equal to 2 ms, there is a difference. If the dump port is commented out, I get a ~24% CPU usage. This is ~5% higher after enabling the port, and almost +15% (~40%) with an active connection to a running dumpCanBus instance.
Results are similar on current master and the WIP feature branch associated to this issue.
PS there is little impact when dropping syncPeriod
to 10-20 ms, it's still ~18% (and 20-21% on an active dumpCanBus connection at 10 ms).
Done at https://github.com/roboticslab-uc3m/yarp-devices/commit/f324d110611751d28e6e0c2d4cc2862365ca278e. The dumpCanBus app has learned to accept a new switch, --with-ts
, which prepends the timestamp in the console output. I'm not adding another option to disable the dump port (yet).
See https://github.com/robotology/yarp/discussions/2533 regarding CPU usage on buffered ports with no active connection.
As observed in https://github.com/roboticslab-uc3m/yarp-devices/issues/160#issuecomment-577650352, the
/dump:o
port publishes at such a high rate that messages are dropped/lost when inspected either throughyarp read
companion command or the dumpCanBus app.I have replicated this behavior in a reader&writer sample scenario:
Command-line arguments allow to tweak the number of messages sent in bursts (default: 10), the delay between messages (default: 0.1 seconds), whether the writer should wait for any writes to complete (default: false), and whether the reader should not drop old messages (default: false). Note the reader also emulates an intensive operation going on each message reception (default: 10 ms).
Per docs:
Our problem is mostly solved with
write(true)
(orwriteStrict()
) andsetStrict(true)
. I observe that messages are dropped whenever any of these is not properly set.Ideas:
writeStrict()
in CanBusControlboard's CAN read/write threads.setStrict()
in dumpCanBus. See warning: "if you can't read them as fast as they come in, watch out".write()
multiple times: read loop, write loop). Consequently, dumpCanBus should be prepared to accept and decode multiple-list bottles.writeStrict()
degrades performance, consider alternatives (aggressive buffering? lower CAN read/write rates?) and/or conditionally disable dump port.By the way, I could have used
setWriteOnly()
instead ofsetInputMode()
here.Also, CAN messages forwarded via YARP could have a timestamp envelope associated and printed on screen by dumpCanBus, if properly configured.