Reducing Latency between landscape server and registered device

Hey, I’m working on reducing the latency between the server and the registered device by adjusting the polling interval .

My goal is to have the device check the server more frequently for updates to ensure a more responsive UI. Right now it takes a couple of minutes to dispatch scripts on the device.

From configure hook, I can see we don’t have this option. I have tried config app in landscape snap, by decreasing the exchange interval

# skipping registration because the device is already registered
sudo landscape-client.config --exchange-interval=10 --skip-registration --silent

Despite these changes, I haven’t seen the improvement I was hoping for.

Has anyone dealt with a similar issue or have suggestions on how to further reduce this latency? Any advice or alternative approaches would be greatly appreciated.

Thanks in advance!

1 Like

Hey @mikecw , do you have any idea?

I haven’t played with these settings as I’m not too concerned with responsiveness, but it depends on what you are trying to achieve.

For example, if you are trying to see snap updates more rapidly you may want to look at the snap_monitor_interval setting. Or package_monitor_interval.

Those settings are in seconds though so I would be cautious of turning them down too low as the client may stuggle.

My concern was mostly about running scripts, there is some latency between when we dispatch the script and when the Broker places it on the device and runs it.

I was wondering if you guys have a parameter to tune this.

You could try ping_interval which is how often the client checks for messages. Then I think if a script is pending it will be classed as an urgent exchange so you could reduce urgent_exchange_interval.

Those are the only settings for the interaction between server and client but are not tested for anything too rapid fire.

1 Like

Awesome, reducing all of these three variables seems to make the client a lot more responsive :slight_smile: Not sure which variable does what xD but ok.

Is it possible to do a feature request to support these variables in the configure script of landscape-client so we can set defaults for them for our devices?

Yeah OK. I’ll stick it in the queue.

1 Like

Done. It’s in the build/approve queue - it’ll be in edge/beta as soon as that’s done.

1 Like

We have tested revision 269 and it fails to come online.

I see by now there is already 279 and 289. Where can I track which revision belongs to what change?

@mikecw I tested 279 as well and it also doesn’t come online (on first boot at least)

Are you guys aware of this and looking into this?

We are really waiting for this feature :smiley:

Urm… no I wasn’t - let me try and get someone on it. Can you quickly give me a run-down of your steps to reproduce please? Thanks

Hi @Charlee,

We’re getting into this - can you please just confirm your initial configuration? Are you using wait-for-serial?

Thanks

Dear Mike,

Yes, we are using that, config:

  ffnH0sJpX3NFAclH777M8BdXIWpo93af:
    landscape-url: "https://landscape.canonical.com"
    account-name: "$OUR_ACCOUNT_NAME"
    registration-key: "$LANDSCAPE_REGISTRATION_KEY"
    log-level: debug # TODO change to info before production (see XCP-139)
    auto-register:
      enabled: true
      computer-title-pattern: ${serial}
      wait-for-serial-as: true
    ping-interval: 30
    exchange-interval: 30
    urgent-exchange-interval: 30

Thanks. I think it may relate to a change in the wait-for-serial. Hopefully should be a quick fix.

1 Like

There is more problems I have with the newer versions… If I refresh to 279 it also seems that execute-script functionality does not work properly anymore, not sure if that is due to the same issue…

Hi @Charlee,

Does the model assertion you’re using include a serial-authority field? If it doesn’t, please add serial-authority: ["generic"]. This will tell the device to request a serial assertion from the global store. If that field is not provided, the device blocks indefinitely waiting for the serial. There’s a longer explanation here.

If you do have that specified, please share the model assertion & gadget.yaml in full I try reproduce the issue. Please redact any confidential information like keys, accounts, etc.

Thanks,
Stephen

Dear Stephen,

We do not have serial-authority: ["generic"] in our model, but we are also not connecting to the Global store. We have our own Brand Store, maybe that is your issue with reproducing?

I doubt we are waiting indefinitely for a serial, as requesting a serial and registering with it to Landscape seems to work on landscape-client revision 244, just not in later versions.

My model looks like this:

{
    "type": "model",
    "authority-id": "$OUR_BRANDSTORE_ID",
    "brand-id": "$OUR_BRANDSTORE_ID",
    "series": "16",
    "model": "$OUR_BRANDSTORE_MODEL",
    "store" :  "YfJGFtlNlwr8LfeoakLO",
    "architecture": "amd64",
    "base": "core22",
    "grade": "signed",
    "timestamp": "2024-09-27T12:23:20+00:00",
    "revision" : "6",
    "validation-sets" : [
        {
            "account-id" : "$OUR_BRANDSTORE_ID",
            "name" : "$VALIDATIONSET_NAME",
            "sequence" : "6",
            "mode" : "prefer-enforce"
        }
    ],
    "snaps": [
      ...
    ]
}

The gadget defaults for Landscape I already sent, is there any other info you need? It is based on the intel gadget-pc by canonical.

@st3v3nmw FYI if you need logs I can get them for you…

@Charlee, yes the logs would be very useful (broker, manager, monitor, & watchdog logs)…

@st3v3nmw is there any channel where I can send them that is not public? I am not sure what information in there is secret and its a lot of logs so don’t feel like cleaning everything