Slow EXI conversion during CurrentDemandResponse in DIN

[kojtp2]

Slow EXI conversion during CurrentDemandResponse in DIN

[shalinnijel2]

I'll try and give this a go on my raspberry pi and see what I get (sometime this week(end) ) and update it here. As a test, could you switch LOG_LEVEL to INFO in the .env file and also set MESSAGE_LOG_EXI to False and retry, please? I believe you have already checked if there is anything else consuming memory, disabled GUI etc.

In Josev_pro we use a Rust version of the EXI codec (which is blazing fast) which is available with Josev_pro.

[kojtp2]

@shalinnijel2 yes, I checked if logging in anyway slowed down the conversion performance and it looks like it doesn't have a big impact. I didn't mention it before, but I run it natively, not in a container.
Log below:

INFO 2022-11-06 00:33:24,317 - iso15118.shared.comm_session (231): PreChargeReq received
INFO 2022-11-06 00:33:24,522 - iso15118.shared.comm_session (415): Sending PreChargeRes
INFO 2022-11-06 00:33:24,843 - iso15118.shared.comm_session (231): PowerDeliveryReq received
INFO 2022-11-06 00:33:24,844 - iso15118.shared.states (137): Entered state PowerDelivery
INFO 2022-11-06 00:33:24,845 - iso15118.shared.states (141): Waiting for up to 60.0 s
DEBUG 2022-11-06 00:33:24,845 - iso15118.secc.states.din_spec_states (652): ChargeProgress set to Ready
INFO 2022-11-06 00:33:25,067 - iso15118.shared.comm_session (415): Sending PowerDeliveryRes
INFO 2022-11-06 00:33:25,070 - iso15118.shared.states (137): Entered state CurrentDemand
INFO 2022-11-06 00:33:25,072 - iso15118.shared.states (141): Waiting for up to 60.0 s
INFO 2022-11-06 00:33:25,311 - iso15118.shared.comm_session (231): CurrentDemandReq received
INFO 2022-11-06 00:33:25,564 - iso15118.shared.comm_session (415): Sending CurrentDemandRes
INFO 2022-11-06 00:33:25,833 - iso15118.shared.comm_session (231): CurrentDemandReq received
INFO 2022-11-06 00:33:26,082 - iso15118.shared.comm_session (415): Sending CurrentDemandRes
INFO 2022-11-06 00:33:26,415 - iso15118.shared.comm_session (231): CurrentDemandReq received
INFO 2022-11-06 00:33:26,645 - iso15118.shared.comm_session (415): Sending CurrentDemandRes
INFO 2022-11-06 00:33:26,981 - iso15118.shared.comm_session (231): CurrentDemandReq received
INFO 2022-11-06 00:33:27,157 - iso15118.shared.comm_session (415): Sending CurrentDemandRes
INFO 2022-11-06 00:33:27,505 - iso15118.shared.comm_session (231): CurrentDemandReq received
INFO 2022-11-06 00:33:27,685 - iso15118.shared.comm_session (415): Sending CurrentDemandRes
INFO 2022-11-06 00:33:27,983 - iso15118.shared.comm_session (231): CurrentDemandReq received
INFO 2022-11-06 00:33:28,164 - iso15118.shared.comm_session (415): Sending CurrentDemandRes
INFO 2022-11-06 00:33:28,464 - iso15118.shared.comm_session (231): CurrentDemandReq received
INFO 2022-11-06 00:33:28,696 - iso15118.shared.comm_session (415): Sending CurrentDemandRes
INFO 2022-11-06 00:33:29,009 - iso15118.shared.comm_session (231): CurrentDemandReq received
INFO 2022-11-06 00:33:29,119 - iso15118.shared.comm_session (415): Sending CurrentDemandRes
INFO 2022-11-06 00:33:29,281 - iso15118.shared.comm_session (231): PowerDeliveryReq received
INFO 2022-11-06 00:33:29,283 - iso15118.shared.states (137): Entered state PowerDelivery
INFO 2022-11-06 00:33:29,285 - iso15118.shared.states (141): Waiting for up to 60.0 s
DEBUG 2022-11-06 00:33:29,286 - iso15118.secc.states.din_spec_states (652): ChargeProgress set to Stopping
DEBUG 2022-11-06 00:33:29,287 - iso15118.secc.states.din_spec_states (669): PowerDeliveryReq ready_to_charge field set to false. Stay in this state and expect WeldingDetectionReq/SessionStopReq

[lovalova1991]

Hello there, same issue from my side. Especially during a tesla charge, average timing of a currentDemandRes is 100ms in a dual core celeron.
Digging up a little bit with the code, the most demanding thing in term of timing is the exi conversion (obviously..)
Tesla waits circa 4 minutes and after stops the charge without saying anything, simply turning up the CP value to 9V.

The timings with the ISO protocol are pretty similar and the charging process runs smoothly.
Any suggestion?

[tropxy]

Hi @lovalova1991, the fact is that the Java EXI codec is too slow to keep up with the DC timing constraints...the community version primarily intention was to provide a reference implementation of the ISO and DIN and in terms of performance is not suitable for field testing. As mentioned, by Shalin, in the josev_pro version we are using a proprietary battle tested Rust version of the codec, which outperforms the Java version.

I have the intention of, in the near future, to include bindings to the OpenV2G C based EXI codec: https://github.com/chargebyte/openv2g for the community version, but for now I would suggest the following:

• Test with Python 3.11 - Python 3.11 has a big performance boost in comparison to its predecessors: https://docs.python.org/3/whatsnew/3.11.html#summary-release-highlights
• Try testing it in a more powerful target

Let me know your results, if you try it. Thanks!

[hughsheehy]

A question around this. Is the exificient coded as implemented in the JAR file a "plain vanilla" implementation?

One of the guys in our team might be able to work in the reference implementation of exificient that's available in C++....but if the jar file has changes from the plain vanilla exificient implementation then he'd need to know about them.