Access violation when trying to get temperature metric

[wojsla]

I'm trying to read temperature of Movidius NCS2 using GetMetric method: ExecutableNetwork executable_network = ie.LoadNetwork(network, "MYRIAD"); float temperature = executable_network.GetMetric(METRIC_KEY(DEVICE_THERMAL)).as<float>(); as shown in this link which I've added to the hello_classification sample.

but I'm getting an access violation exception:

the example runs ok without the call to GetMetric. OS Win, VS 2019, Movidius driver installed

[shubha-ramani]

Dear @wojsla Please attach the main.cpp which you've modified (per the classification sample). I will reproduce and file a bug.

Thanks for your cooperation !

Shubha

[wojsla]

main.zip

Main (hell_classification sample) attached.

[shubha-ramani]

Dear @wojsla Thank you for the attached *.zip ! I will take a look.

Shubha

[shubha-ramani]

Dear @wojsla I am sorry but I could not reproduce your results. I used your code and did not have an access violation.

I'm not sure what is wrong but I think it's a systems permission issue in your environment.

Thanks,

Shubha

[wojsla]

Hi @shubha-ramani I am running VS as an admin, but I have done some further testing running the application from console window (with admin rights too) to take VS out of equation. The application runs correctly in release build but not in debug (which I was trying initially) - did you try debug build?

Thanks

[shubha-ramani]

@wojsla Good point, no I did not build in DEBUG. Did you reproduce this using dldt or the packaged version of R2 ? The reason I'm wondering. If you used the packaged version of R2 then you must make sure environment variables point to Debug instead of Release build before you run setupvars.bat . Simply go through setupvars.bat and replace "Release" with "Debug". I am wondering if a similar problem is happening to you (you are referencing Release build but you are running Debug build) - this is a common mistake people make.

Let me know

Thanks,

Shubha

[wojsla]

@shubha-ramani Packaged version of R2. I don't use environment variables and copy dlls (inference engine and opencv) directly to the build directory - as I then package it all for release in production. If I would have wrong dlls, application would have failed on start. Have you been able to reproduce this issue in debug build? Thanks

[shubha-ramani]

Dear @wojsla , I didn't mean to doubt you, so sorry about that. You are absolutely correct ! I reproduced your error on a debug build. I will file a bug straightaway.

Thanks for using OpenVino and sorry for the trouble !

Shubha

[wojsla]

Hi @shubha-ramani Any update on this? Thank you

[marcin-sielski]

Still does not work on 2020.1. nullptr is returned instead. Question is if NCS2 firmware does not support it. If so why it is present in OpenVINO? Future feature?

[brmarkus]

I just tried it under Linux - Release and Debug build - I get an exception with "Parameter is empty!" for the device "MYRIAD" and the metric "DEVICE_THERMAL", using packaged OpenVINO v2020.1.023 ...

The sample "hello_query_device" prints "DEVICE_THERMAL : UNSUPPORTED TYPE".

@shubha-ramani do you get a value returned from the metric? Under MS-Windows-Release.build? Have you tested under Linux as well?

[avitial]

It is necessary to have created and loaded a network to the Myriad plugin before DEVICE_THERMAL metric can be retrieved. Please take a look at the following article on how to do so: Intel® Neural Compute Stick 2 Temperature Reading with OpenVINO™ Toolkit.

Closing this, feel free to reopen and ask additional questions related to this topic.

[pmundt]

I stubbed in loading a random network before querying the metrics and can verify that using both the C++ and Python APIs that reading the DEVICE_THERMAL metric works:

    Device: MYRIAD
    Metrics: 
        DEVICE_THERMAL : 39.3464
        OPTIMIZATION_CAPABILITIES : [ FP16 ]
        RANGE_FOR_ASYNC_INFER_REQUESTS : { 3, 6, 1 }

Having to load a network to query the device temperature, however, is sub-optimal. I would like to be able to expose this data through a prometheus exporter such that it's possible to implement AlertManager alerting rules and take some corrective actions at various thermal trip points (e.g. suspending a service, or triggering a redeployment of the inference microservice onto a different accelerator). I will probably work around this limitation in the interim by just exposing an exporter class I can instantiate in each inference microservice that's using the NCS2, but would obviously prefer to be able to do this from a single exporter without needing to separately instrument each microservice.

[pmundt]

For anyone that's interested, I now have a functional prometheus exporter for anyone interested in monitoring the NCS2 temperature from their inference application.