Today is...
Saturday, June 15, 2019
The OPC Community Forum.
DDE versus OPC performance benchmarks?
I have been to the OPC Programmers Connection and the OPC Foundation, but what I can't find is any concrete examples of DDE's limitations.
By Warren Postma on 15 February, 2000 - 12:50 pm

I have been to the OPC Programmers Connection and the OPC Foundation, but what I can't find is any concrete examples of DDE's limitations. Are there
any benchmarks to demonstrate within an order of magnitude what both are capable of, locally and over a network. Obviously in these areas, Your
Mileage May Vary, but at least an overview of performance ability would be good.

I have programmers here telling me that they can get 20 ms updates via DDE with up to 30 points per second "and that's good enough" sort of thing, and what I keep telling them is that the reason OPC was invented was so that we could do hundreds or thousands of points per second, and so on.

Unfortunately, I'm completely unarmed with any documentation on the subject, and all I can do is present my own experience that DDE sucks, from my
experience using WonderWare. Faced with a half dozen programmers all crying to go ahead with the easy way out (DDE) for all their drivers from now on, can I stop them, or at least give them pause to think about DDE's limits somehow? It seems silly to me to be implementing DDE servers in the year 2000.

Warren

Warren,
The fact that DDE opens up a conversation for each and every item is one significant limitation. So if you have 100 items to read, with plain old DDE (as opposed to FastDDE or AdvanceDDE), you're limited to 1 item at a
time and you end up with a lot of topics open. The problem gets worse in that most plain DDE clients have a hard limit of about 50 or so (one of the other gurus on the list I'm sure will tell you the exact #) topics open at at time. This exact limit is why Wonderware made FastDDE and ROckwell made AdvanceDDE - they let you write batches of items in a single topic. There
were other reasons they made their versions (in deference to those folks), but that was a big one.

Having said all that, there was a presentation done at the ISA show in October 1999 on the DDE vs. OPC performance issue and it had hard data --
that should be available at the OPC foundation site -- Tom Burke of Rockwell and Carl Hoffman of Wonderware authored it and did the testing. If I recall their results accurately, the big result was that when you had multiple clients connected to an OPC server, the OPC server was tons faster than the DDE server with multiple clients connected to it. Again that presentation ought to be on the OPC foundation website.

Sincerely,

John Weber - President
jweber@softwaretoolbox.com
Software Toolbox, Inc.
3030-B Whitehall Park Drive
Charlotte, NC USA 28273
Ph: 704-587-9545, Fax: 704-587-9796
http://www.softwaretoolbox.com

By Michael Johnson on 17 February, 2000 - 4:58 pm

We are using WonderWare's OPCLink as a OPC Client on 4 machines and RSLinx as a OPC Server. We find that the response time to the drives ( which are on a Profibus network ) is much much quicker when we tried the same application with DDE. Also, setting up the communication is alot easier. I personally like OPC alot. I think DDE is a joke and should be banned from ever being used.

By Jamil, Babar on 16 February, 2000 - 2:00 pm

DDE Multiplexing issue is something that made me think of alternate protocols. When multiple clients request data from one DDE server the DDE
server stops serving clients after a certain limit. Therefore only a certain number of clients can be served per DDE server.

By Wally Pratt on 17 February, 2000 - 3:27 pm

Dear Warren,

I do not think the choice between OPC and DDE is completely a technical one. The real question is which will give you the best connectivity?
Before developing the HART OPC Server identifying which technology will give access to the largest number of host/MMI applications was critical.
For example (if memory serves me right) DDE works on the idea of topics. The topics and context of the message is defined by the DDE
developer (i.e. he gets to invent his own protocol). That means every time a host encounters a DDE server special programming maybe required. This is a barrier to widespread adoption by host applications.

On the other hand, OPC defines the context of the messages much more clearly. In other words the data that is moved between your product and
another application is well defined. This reduces the barriers between software components more then DDE does.

In addition, the number of companies adopting OPC in this industry ensures easy connection to a very large number of products.

OBTW. DDE has always been a dog (performance wise)

best regards
Wally Pratt
Senior Engineer
HART Communication Foundation
http://www.hartcomm.org

Dear Warren,
Another main topic is the fact that OPC uses COM and DCOM technology. This means completely open visibility on NT stations through registries. OPC
means more than data access, it is arriving alarm and server, and historical datas. One of the main company working on OPC is Softing. In their site
(www.softing.com), it is to find a lot of technical documentation and test performance


Best Regards
Luca ing. Marani
Consulente Tecnico

Via G=2E Spaziani, 41
37138 Verona

Tel=2E: +39 (045) 8393626
Cell=2E: +39 (335) 5250661
Fax: +39 (045) 8393612

By Mike Schoonmaker on 22 February, 2000 - 11:41 am

I can speak of one installation that we had, where a customer wished to move 400 16-bit values from our control software product into another SCADA package, specifically Citect. This customer had originally implemented DDE, and was updating the 400 tags at a rate of 22 seconds for one full round of updates. Needless to say, this customer was not completely enthralled with the system, and contactes us for assistance. We found that Citect had recently offered a OPC Client, so we made arrangements with Citect to acquire this system. Once the OPC connection was installed, the customer was successful at getting the 400 16-bit values in 15 MILLIseconds!!

Mike Schoonmaker
Think & Do Software, Inc.
http://www.thinkndo.com

By Philip Glass on 23 February, 2000 - 5:58 pm

DDE is a slug but you should be able to update 400 registers in about 4-8 seconds, not 22.
I hate DDE just as much as the next guy but I can generally achieve 100 16-bit register updates per second (+/- 500 ms). I do have to question the 15 ms updates with OPC. That doesn't sound right.

Philip L. Glass

I have to agree that 400 16-bit values in 15 MILLIseconds is a bit fast for me to believe, unless you had a very fast OPC server platform and a very big pipe into it. That is approx 27000 updates per second.

Trung Nguyen and myself did a number of OPC stress tests last year, which we formally presented in a paper at the CPPA Technical Conference in early February. Basically we ran the OPC stress tests with a mixture of different
vendors' hardware and software and tried to see what was possible and what wasn't. Using a dedicated Pentium 400 we managed 5000 undates per second and may have been able to get 8,000 if we had tried harder. But 26,000 would have been
too much.

That said, it still beats DDE by a mile.

Regards
Eric Byres
Artemis Industrial Networking
ericb@istar.ca

By Martin Roberts on 1 March, 2000 - 3:36 pm

What is the big deal ? If you ask an AB PLC for a continuous block of 400 16-bit registers using TCP/IP it can send it back in around 11 milliseconds. Citect keeps details statistics on all I/O communication and whenever I visit a plant I always have a looks at these statistics. They normally show a response time between 10 and 12 milliseconds. Getting that data from the
I/O Server to its clients is simply a matter of bashing bytes around in the computer address space if the client is on the same computer. If it takes Citect an extra 4 milliseconds on a fast computer to move the data, what is the problem? Today's fast computers can execute several million instructions in 4 milliseconds. What you should be asking is why is there so much overhead in moving 800 bytes of data from one spot to another.

Only last week I was testing a third party software product which uses OPC to get it's data. As I can get my Citect licences for free, I naturally used Citect as the OPC Server. I benchmarked the performance of this third party
software product to see what it is capable of. On my slow-ish 200 MHz Pentium II computer I was able to get 55,000 tags a second through the
system. But think about it, 55,000 tags is only 0.110 Meg of real data (yes there is overhead data as well). My computer can move up to 2000 MB of data per second when that data is stored in the primary CPU cache. I know this as I have benchmarked my computers performance and every other piece of software that we have ever produced. So even at this so called fast 55,000
tags a second, the OPC server is less than 0.01% efficient in moving the data.

Martin Roberts
R & D Director
Ci Technologies Pty Ltd, Australia
martinroberts@cit.com.au

By Johan Bengtsson on 3 March, 2000 - 1:23 pm

What difference does it make if you double or half the amount of data? probably not much (probably not double or half the time). I think some of the delay is related to task switches
and other similar overhead (not moving data) and little from actually moving it.

Could you test that with the rest of the configuration the same and post the result?


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------

By Philip Glass on 5 March, 2000 - 1:14 pm

> From: Martin Roberts <MartinRoberts@cit.com.au>
>
> What is the big deal ? If you ask an AB PLC for a continuous block of 400 16-bit registers using TCP/IP it can send it back in around 11 milliseconds.<

OK. Best case scenario but let's assume the following:
400 16-bit registers / 11 milliseconds = 36360 registers / sec.

<snip>
> On my slow-ish 200 MHz
> Pentium II computer I was able to get 55,000 tags a second through the
> system.
<snip>

That's 55,000 discrete tags, right?
That equates to 3438 register updates per second.
I'll buy those numbers.

> -----Original Message-----
> From: "Eric Byres" <eric.byres@artemisnetworks.com>

<snip>
> wasn't. Using a dedicated Pentium 400 we managed 5000 undates per second and may have been able to get 8,000 if we had tried harder. But 26,000 would have been too much.<
<snip>

I would buy those figures as well.

<snip>
> From: "Glass, Philip" <PGlass@brwncald.com>
>
> DDE is a slug but you should be able to update 400 registers
> in about 4-8
> seconds, not 22. ...<clip>

I've done some testing and tweaking on an application using a DDE server recently and I found the best I can muster is approximately 600 16-bit register updates per second. That's with DDE, not OPC... DDE!! Obviously OPC is going to be considerably faster but nobody's been able to
present a comparison of the two using the same data and same equipment which is what the original poster was seeking to find.

By Martin Roberts on 6 March, 2000 - 5:14 pm

>That's 55,000 discrete tags, right? That equates to 3438 register updates per second. I'll buy those numbers.<

OK, where do I send the Invoice? :-) But seriously, the test contained 45% digital tags, with the remainder 16 or 32 bit integers. Yes, the 400 16-bit registers may be good case but not quite the best. The best case is when you read 2K bytes of data in one continuous block. The AB response time is quite flat as the Ethernet bandwidth is so high. In theory the maximum performance peeks at 2k / 11 milliseconds = 90,000 registers /sec per PLC.

However it is a little more complex that that. The performance of the OPC server is governed by two factors:

1). The raw response time from the PLC (which is what we have been talking about).

2). The CPU overhead moving the data from the server to the clients (copying data, status flags, context switching etc).

Moving data between two processes on the same computer can be quite expensive. If I am using a COM Local Server my slow-ish 200 MHz Pentium II
computer the performance peeks at 7000 calls a second. If I was running a very simple OPC server which was running as a local server and required a
context switch for each tag. Then I would be limited to a maximum of 7,000 tags per second even if my PLC data responded in 0 milliseconds. I was able to get 55,000 tags a second on my computer because the Citect OPC Server does not do a context switch or local server COM call for each tag.

So when you ask about discrete tags, yes you can jam more bits in one PLC message and it would effect the performance of factor 1). However it does not make much difference with factor 2), as there is so much overhead associated with each tag that the actual data becomes insignificant.

However even this is not the limit of performance as all the above talks about using a single PLC. If you add a second PLC, your factor 1) performance will double. This is because the I/O server can send another request to the second PLC while it is waiting for the first to respond. You
can keep adding more PLCs and you get a linear increase in performance, until you saturate the Ethernet at extreme data rates. However splitting
your data over many PLC's will not help with factor 2). Eventually the I/O servers will be swamped with so much data it will not be able to keep up. So you have to use faster or several I/O Servers. So even 55,000 tags/second is not a true limit.

>What difference does it make if you double or half the amount of data? probably not much (probably not double or half the time). I think some of the delay is related to task switches and other similar overhead (not moving data) and little from actually moving it.<

>Could you test that with the rest of the configuration the same and post the result? <

Johan, In direct answer to your question. If I doubled or halved the amount of data to the AB PLC, then so long as the data was within a 2K block then the PLC would still respond in 11 milliseconds. As soon as I went outside of the 2K block then I would get another request and the response time would increase to 22 milliseconds. Yes you are correct, a lot of the delay will be related to task switches and other overhead. If you double or halved the data then that overhead may be doubled or halved, depending no how well the OPC server is designed. Doubling or halving the data on your particular system will depend on the relationship between the factor 1). and 2).
performances of your PLC, the speed of your computer, if you are running the OPC server In-Proc, Local Server or Remote Server, etc, etc.

If we get back to the original question the reason DDE servers are so slow is all due to factor 2). The PLC is exactly the same between OPC and DDE servers, so the factor 1) is the same. With a DDE server design the interface is limited via the DDE specification. The same can be true for OPC servers, it depends on the internal design of the OPC server.

Martin Roberts
R & D Director
Ci Technologies Pty Ltd, Australia
martinroberts@cit.com.au

By Mike Schoonmaker on 25 February, 2000 - 3:54 pm

As for 4-8 seconds v. 22 seconds, I can only go on what the client measured, as the machine and equipment was at his location. The OPC connection,
however, was initially tested at our location, and then confirmed at client's as well. Let me also state that the OPC Server was in fact an
out-of-process server at that. An in-process server would be able to provide even better performance.

Mike Schoonmaker
Think & Do Software, Inc.
http://www.thinkndo.com

By Kimberly Wang on 1 March, 2000 - 3:34 pm

I recently have an application that I used Kepware DDE and OPC server to talk to Labview DDE and OPC client with the same program running on the same computer, I got the result that roughly OPC is 3 times faster than DDE, by the way, I only read certain items.

Kimberly

By Michael Johnson on 22 February, 2000 - 1:37 pm

If you use RSLinx as a OPC/DDE server, one can see that it is a lot easier to set up a 1000 points using with OPC then with DDE. Because, with DDE each point has to be pasted to the clipbroad inorder to access to it in any application while with OPC you do not have to.

We use Citect's OPC driver to talk to A-B ControlLogix processors via RSLinx. It works beautifully and the performance is as good as any driver, of any kind, I've seen. One of our servers is talking to about 1000 tags in five processors. That's is a relatively small tag count for a Citect project, but I get the feeling it will scale up nicely.

Mike Ryan
Aerojet Fine Chemicals

By Rod Doolittle on 23 February, 2000 - 6:02 pm

Warren, if you are using Wonderware for your HMI then you have the capability of using Suitelink for your link. Granted, their are limitations to DDE and if you don't know how to write your own OPC server then the next best step is using
Wonderware's suitlink.

If you have a lot of data to move then it is quite a bit faster than DDE. I do not have any specs in comparison to an OPC Server. I do know that Wonderware has quite a few I/O servers and they are optimized for use with their software.

You have to take into consideration the time it will take you to write an OPC server specific for what you are trying to talk to. This can amount to a lot more cost than just buying an I/O Server and a PC Card if it is required with minimal performance gain.

But to answer your question, "Is OPC better than DDE and why?" I can't give you any more info than what you already have. I suggest you try and write
your own OPC server and do the tests yourself.

Just an opinion.

Rod

By Frik Olivier on 15 March, 2000 - 2:04 pm

Hi!
I'm writing OPC Servers and OPC Clients in C++. The Comms between OPC Server and the PLC is limited by the protocol itself and the type of
hardware connection. Some protocols allows bigger blocks of continuous than other. Ethernet will go faster than serial. Some are peer to peer, some are token ring, etc...

So, the data will get to the Server as fast as that.

From there on it's the question of how fast the PC can shift the data from the Server to the Client. Then again are there a few ways of getting the data to the Client.

The Client can request the block of data. (Which most of the time is just a confirmation of whether the registered pointers to the data is still valid, which means that the Client is accessing the data via pointers directly into
the Server, no shifting of data)

Or the Client can register 'Call-back' functions. This means that the Server can (if advised by the Client) send the CHANGED data to the Client. Then the question changes to how much data (people mentioned 90,000 registers) changed since the last PLC read?

The Client can also be set up to read cached data or device data. Another set of differences which can affect the speed of communication.

So, I think it depends on the design of the OPC Server, the design of the OPC Client and the configuration of the two.

But the OPC solution is definitely far better and faster that DDE. Specially over networks!

Frik Olivier
folivier@siliconza.co.za