[SVE2][TC-LVL-4.1] Reading the current-level while it is ramping up causes timing issues

[pankore]

Problem

• In TC-LVL-4.1, step 4a, we move the current-level with command ./chip-tool levelcontrol move 0 5 0 0 1 1 , with starting current-level of 50
• After 10 seconds, we read the current-level using ./chip-tool levelcontrol read current-level 1 1 while the current-level is still ramping up. Doing this read causes the DUT to pause the ramping up of current-level value and process the read request
• Subsequent read current-level will return inaccurate readings as the ramping up is delayed

[jmartinez-silabs]

Not something I noticed on our platform. How inaccurate is the value you then read?

[pankore]

At the end of 42 seconds, expected value is 254, I got about ~235. Any idea how do I fix this?
Platform is Ameba.

[bzbarsky-apple]

@pankore So the issue is that the CASE establishment from the non-interactive chip-tool invocation takes up a big chunk of server time for the crypto, right?

[pankore]

@bzbarsky-apple, yes that is correct. With interactive mode (and timing myself manually) DUT can reach 254 within the time frame. However this is an automated TC so I can't use interactive mode in this case.

[bzbarsky-apple]

I wonder whether we should do something like #21755 but for level control....

[pankore]

Thanks @andrei-menzopol for the fix.
However, the CASE latency for some DUT is in terms of seconds, which is much larger than the tick period which is in milliseconds most of the time. So even with best effort to reduce the wait time to 0 for the next tick, it will not fix the delay.
May I suggest that the test script account for these latency? Or maybe use interactive mode so that CASE will not cause huge delays on every read request.

[andrei-menzopol]

You're welcome @pankore.
Yes, the crypto operations from the CASE session establishment cause the timer to be delayed until the establishment is finished, causing the test to fail.
I agree, this compensation is not a solution that would help all vendors. Though, I think this is a issue that each vendor should investigate on their platforms: decrease the CASE time, make sure CASE Resumption works etc.