ATK update rate - TANGO Controls

# 5 years ago
Amato	Hi all, I have what I suspect is a dumb question. When I inspect a device via ATKPanel, or generate a GUI via JDraw synoptic, it appears that the generated code is updating only once every 10 seconds regardless of what device servers are available or what device I'm interrogating. I'm a bit confused as I can see that either the attributes are being polled more often via jive; I have a hook written into the device server that flags whenever a poll happens and I can see both the polls happening at n Hz intervals from Jive, iTango, or whatever, while ATKPanel or a jdraw synopic seem to generate their own poll call every 10 seconds. I have changed the refresh rate in ATKPanel and that doesn't seem to make a difference, either. I haven't tried running the synoptic encapsulated in Taurus but I would expect that would have the same behaviour. Am I missing the point of ATK and it in fact is only supposed to update at .1Hz?

# 5 years ago

Hi all,

I have what I suspect is a dumb question.

When I inspect a device via ATKPanel, or generate a GUI via JDraw synoptic, it appears that the generated code is updating only once every 10 seconds regardless of what device servers are available or what device I'm interrogating. I'm a bit confused as I can see that either the attributes are being polled more often via jive; I have a hook written into the device server that flags whenever a poll happens and I can see both the polls happening at n Hz intervals from Jive, iTango, or whatever, while ATKPanel or a jdraw synopic seem to generate their own poll call every 10 seconds.

I have changed the refresh rate in ATKPanel and that doesn't seem to make a difference, either.

I haven't tried running the synoptic encapsulated in Taurus but I would expect that would have the same behaviour.

Am I missing the point of ATK and it in fact is only supposed to update at .1Hz?

# 5 years ago
Andy	Hi Amato, this sounds like a classic case of events not being received. In this case there is a "keep-alive" feature which tries to re-subscribe to the events every 10s and at the same time updates the value. When events do not work it is often because of the host names which are resolved differently by the client and server either because they are running on different hosts and/or because the TANGO_HOST is specified differently. This problem has been fixed in V9.3.x. A release is pending. You can try to download one of the nightly builds or build the latest version from source. If this is not an option you can try to fix the problem with the TANGO_HOST by send us your configuration. An even easier solution is to switch to polling in the client. Hope that helps Andy

# 5 years ago

Andy

Hi Amato,

this sounds like a classic case of events not being received. In this case there is a "keep-alive" feature which tries to re-subscribe to the events every 10s and at the same time updates the value. When events do not work it is often because of the host names which are resolved differently by the client and server either because they are running on different hosts and/or because the TANGO_HOST is specified differently. This problem has been fixed in V9.3.x. A release is pending. You can try to download one of the nightly builds or build the latest version from source.

If this is not an option you can try to fix the problem with the TANGO_HOST by send us your configuration.

An even easier solution is to switch to polling in the client.

Hope that helps

Andy

# 5 years ago
Amato	I thought that might be the case, but the server and ATK client is running on the same system. I tried using localhost:10000 and localhost.localdomain.:10000 but both have the same behaviour. Should I be sticking tango://localhost:10000 for now? I'll run the new build tonight, too. Thanks for the help!

# 5 years ago
Reynald	Hi, As Andy, my advice would be to use the same TANGO_HOST value on the device server side and on the client side, with the same case. But I've seen some cases where this was not enough. You could also try to execute DbGetCSDbServerList command on the Tango Database device (usually named sys/database/2). Could you try to use one of the values returned by this DbGetCSDbServerList command as TANGO_HOST, with the same case, on client and device server side? Please remember that if you are starting your device server with the Starter device server, you need to ensure that the Starter is also using this same TANGO_HOST. Could you please try that? Kind regards, Reynald Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 5 years ago

Reynald

Hi,

As Andy, my advice would be to use the same TANGO_HOST value on the device server side and on the client side, with the same case.
But I've seen some cases where this was not enough.

You could also try to execute DbGetCSDbServerList command on the Tango Database device (usually named sys/database/2).
Could you try to use one of the values returned by this DbGetCSDbServerList command as TANGO_HOST, with the same case, on client and device server side?
Please remember that if you are starting your device server with the Starter device server, you need to ensure that the Starter is also using this same TANGO_HOST.

Could you please try that?
Kind regards,

Reynald

Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.

# 5 years ago
Amato	Hi guys, thank you for the information. I am running both the server and the client on the same machine and they share the same TANGO_HOST var. I checked to make sure it wasn't changing between different shells. Here are some following combinations I have tried: localhost:10000 - 10 second behavior localhost.localdomain.:10000 - 10 second behavior 127.0.0.1:10000 - 10 second behavior (?!?!) I then executed the command Reynald pointed me to and it returned this: rarerf-pc.fios-router.home:10000 … which makes a modicum of sense. I'm also wondering whether this is a function of the DNS of the FIOS router I use, as I've had some wonky DNS resolution in the past that caused names that shouldn't resolve to resolve. After I used this as the TANGO_HOST for all devices the update rate now is correct! I'll still move on to 9.3 later today to check. That said, I am still scratching my head how forcing TANGO_HOST to an actual IP address would have the same behavior, but hey, if it's patched going forward and what I have works, shrug and move on :) Thank you gentlemen!

# 5 years ago

Amato

Hi guys, thank you for the information.

I am running both the server and the client on the same machine and they share the same TANGO_HOST var. I checked to make sure it wasn't changing between different shells.

Here are some following combinations I have tried:
localhost:10000 - 10 second behavior
localhost.localdomain.:10000 - 10 second behavior
127.0.0.1:10000 - 10 second behavior (?!?!)

I then executed the command Reynald pointed me to and it returned this:

rarerf-pc.fios-router.home:10000

… which makes a modicum of sense. I'm also wondering whether this is a function of the DNS of the FIOS router I use, as I've had some wonky DNS resolution in the past that caused names that shouldn't resolve to resolve.

After I used this as the TANGO_HOST for all devices the update rate now is correct! I'll still move on to 9.3 later today to check. That said, I am still scratching my head how forcing TANGO_HOST to an actual IP address would have the same behavior, but hey, if it's patched going forward and what I have works, shrug and move on :)

Thank you gentlemen!

# 5 years ago
Andy	Dear Amato, good to hear that you have something that works! Let me try to explain why the IP address for the TANGO_HOST works. Tango events are based on ZMQ publish subscribe sockets. There are fewer event channels than device attributes (one per device I think). In order to avoid sending all events for a device to all clients a filter is used to send only those events to the clients which have subscribed for events from that attribute. The filter is based on the full attribute name i.e. including the TANGO_HOST. All fine up to here except that the TANGO_HOST is converted to an ip address in the client using a different code in C++ and Java. This results in the filters being different in the client and server when using eg. localhost, and events are not received by the client (ATKPanel). Tango 9.3.x has fixed this so that the filter is the same in the client and server. BTW Tango 9.3.3 is in the process of being released in the next days … Cheers Andy

# 5 years ago

Andy

Dear Amato,

good to hear that you have something that works! Let me try to explain why the IP address for the TANGO_HOST works. Tango events are based on ZMQ publish subscribe sockets. There are fewer event channels than device attributes (one per device I think). In order to avoid sending all events for a device to all clients a filter is used to send only those events to the clients which have subscribed for events from that attribute. The filter is based on the full attribute name i.e. including the TANGO_HOST. All fine up to here except that the TANGO_HOST is converted to an ip address in the client using a different code in C++ and Java. This results in the filters being different in the client and server when using eg. localhost, and events are not received by the client (ATKPanel).

Tango 9.3.x has fixed this so that the filter is the same in the client and server.

BTW Tango 9.3.3 is in the process of being released in the next days …

Cheers

Andy

# 5 years ago
Amato	That’s the thing: the IP address DID NOT WORK, which was mind bending to me.

# 5 years ago
Reynald	Andy The filter is based on the full attribute name i.e. including the TANGO_HOST. All fine up to here except that the TANGO_HOST is converted to an ip address in the client using a different code in C++ and Java. The TANGO_HOST is not converted to an ip address in the event filter. This is not true. It is converted to a fully qualified domain name. This is why the DNS configuration is important in this situation. Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 5 years ago

Reynald

Andy
The filter is based on the full attribute name i.e. including the TANGO_HOST. All fine up to here except that the TANGO_HOST is converted to an ip address in the client using a different code in C++ and Java.

The TANGO_HOST is not converted to an ip address in the event filter. This is not true. It is converted to a fully qualified domain name. This is why the DNS configuration is important in this situation.

Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.

# 5 years ago
Reynald	And to be complete and to come back to one of the points from Andy, the way to compute this event filter name was slightly different on Java and C++ and was giving different names in some situations (depending on how your DNS was configured). In the next cppTango release (9.3.3), the device server will inform the client during the subscription phase about the event channel which will be used for the attribute events and for the heartbeat events. You will also need to update JTango to benefit from this feature from your Java clients. Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 5 years ago

Reynald

And to be complete and to come back to one of the points from Andy, the way to compute this event filter name was slightly different on Java and C++ and was giving different names in some situations (depending on how your DNS was configured).
In the next cppTango release (9.3.3), the device server will inform the client during the subscription phase about the event channel which will be used for the attribute events and for the heartbeat events.
You will also need to update JTango to benefit from this feature from your Java clients.

Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.

# 5 years ago
Andy	Reynald, thanks for the correction! Andy