# How you ask depends more than what protocol you use ... (Protocol benchmarks)

**URL:** <https://forum.inductiveautomation.com/t/how-you-ask-depends-more-than-what-protocol-you-use-protocol-benchmarks/117348>\
**Category:** 3rd Party Modules\
**Created:** [October 6, 2026, 7:47am UTC](https://forum.inductiveautomation.com/t/how-you-ask-depends-more-than-what-protocol-you-use-protocol-benchmarks/117348 "2026-10-06T07:47:40Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![christofer.dutz](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/christofer.dutz/32/76634_2.png) [@christofer.dutz](https://forum.inductiveautomation.com/u/christofer.dutz)\
**Post date:** [October 6, 2026, 7:47am UTC](https://forum.inductiveautomation.com/t/how-you-ask-depends-more-than-what-protocol-you-use-protocol-benchmarks/117348/1 "2026-10-06T07:47:40Z")

</div>

Next and last of my OT protocol benchmarks is finally online. Most surprising output: Not the choice of protocol is important, the choice of client seems to be much more important.

So I've tested devices from seven different vendors with ten of our drivers and measured how much bytes go on the network, the response-times and (what I think is really important) how much stress using each protocol causes on the PLC.

Let's say the initial outcome matched my expectation ... the native protocols of each vendor outperforming OPC-UA. What I wasn't expecting however was that OPC-UA didn't perform that badly (I need to adjust my attitude towards that a bit, I guess 😉 ) but what surprised me most is that it mattered most how you use a protocol. Mostly using the normal specced (or in case of un-publicly-specced, the most common open-source implemented path) path was a lot less efficient than if the used client/driver smartly optimizes the features of the protocol.

Most impressed was the results of our latest version of our ToddySoft Connect S7CommPlus driver. Here under heavy load (2500 tags per 500ms) the secure and encrypted S7CommPlus was able to outperform even our optimized S7Comm driver on our oldest and weakest S7-1200.

Here's the full article, if you're interested: [Ten PLC Protocols, Seven Vendors: How You Ask Beats What You Use — ToddySoft](https://toddysoft.com/blog/protocol-comparison/)

I also updated my Siemens specific benchmark document with the results from the newest, optimized S7CommPlus driver here: [Five Doors Into One Siemens Controller: What Each One Costs You — ToddySoft](https://toddysoft.com/blog/protocol-benchmark/)

---

<div class="post-metadata">

**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\
**Post date:** [October 6, 2026, 10:24am UTC](https://forum.inductiveautomation.com/t/how-you-ask-depends-more-than-what-protocol-you-use-protocol-benchmarks/117348/2 "2026-10-06T10:24:38Z")

</div>

Hi Chris,

I did go over the article (even with the unhealthy relationship to Siemens 😉 ).

I would be interested in seeing a benchmark for the C'Logix 5380 CPUs, where the comms run on its own dedicated processor.

---

<div class="post-metadata">

**Author:** ![christofer.dutz](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/christofer.dutz/32/76634_2.png) [@christofer.dutz](https://forum.inductiveautomation.com/u/christofer.dutz)\
**Post date:** [October 6, 2026, 10:56am UTC](https://forum.inductiveautomation.com/t/how-you-ask-depends-more-than-what-protocol-you-use-protocol-benchmarks/117348/3 "2026-10-06T10:56:24Z")

</div>

Hehe ... happy to do that ... just send me one 😉 (It's "slightly" over my budget for just a benchmark ... if enough people buy my drivers, then sure)

I'd really be interested in people trying out my new S7 driver (which includes the S7+) and to give me some feedback on how it compares to that other module that's also sold here (I have heard people complain)