Very slow ISO14230 sendmessage

[sevtix]

Hi!

Im using following code to send an empty 128 byte ISO 14230 K-Line message: Problem is that this takes more than 760ms to send!! And thus a high DefaultTxTimeout is necessary The read is absolutely fine though..

In other applications (using other libraries? but same driver for sure) its working much much faster. I also tried various Tactrix interfaces.. no luck

What could be the issue?

Using: Tactrix Openport 2.0 Api Version: 04.04 Firmware: 1.17.4877

using SAE.J2534;
using System;
using System.Diagnostics;

namespace KlineSend2
{
    internal class Program
    {
        static void Main(string[] args)
        {
            API fac = APIFactory.GetAPI("C:\\WINDOWS\\SysWOW64\\op20pt32.dll");
            Device dev = fac.GetDevice();

            Channel channel = dev.GetChannel(Protocol.ISO14230, Baud.ISO14230, ConnectFlag.NONE, true);
            MessageFilter emptyFilter = new MessageFilter(UserFilterType.PASSALL, new byte[] { });

            channel.StartMsgFilter(emptyFilter);
            channel.DefaultTxTimeout = 2500;
            Console.WriteLine($"{dev.APIVersion} {dev.FirmwareVersion} {channel.ProtocolID}");

            byte[] bytes = new byte[128];
            Message message = new Message(bytes);

            while (true) {
                Stopwatch s = new Stopwatch();
                s.Start();
                channel.SendMessage(message);
                s.Stop();
                Console.WriteLine($"{s.ElapsedMilliseconds}ms"); // about 765ms !
            }

        }
    }
}

[BrianHumlicek]

The only thing my library does before calling the API is copy the data to the unmanaged heap. I don't think this is a performance issue with J2534Sharp, despite you observing no issue with the unmanaged driver.

The only thing I could suggest is, try repeating the stopwatch/send message a second time, and see if it is a "warm up" issue.

Brian

[sevtix]

Hi Brian

Unfortunately the higher the payload the higher the delay.. 4 bytes vs 1 byte: payload is 9.5 times slower.

(ignore iso9141 here) :D

[BrianHumlicek]

Is your computer using swap memory or something?

Let me know what happens when you call it twice. - Disregard this, I just looked closely at the screenshot.

Brian

[sevtix]

Hi Brian No.. I actually tried that on my HP 1030 G8 notebook and on a decent gaming pc aswell. 1:1 the same "delay" no matter what I try :(

I don't think it's the driver because (as said earlier) I have other ECU flashing apps which utilize that exact driver. They are working pretty fast even with cheap 20$ tactrix clones.. The read is absolutely fine.

Do you have any other idea?

Thanks so much Severin

[BrianHumlicek]

Well, the next step would probably be to download and compile J2534Sharp if you haven't already, and insert your stopwatch code inside the base send message to confirm if it's the driver call or not. This might also be a good reason for me to add some instrumentation to the base code just for this reason.

J2534Sharp has been around a while and has been used in thousands of applications. There is one code path for sending messages so it's unlikely there is a latent issue (but not impossible).

My uninformed, highly speculative guess is, you are actually using a different driver/api than the applications you are comparing to because J2534sharp actually lets you specify the file name for the 2534 DLL, vs. only pulling it from the registry.

If by some chance it turns out to be the copy to the unmanaged heap that is causing the slowdown, it might be a nudge for me to rewrite things to use Span instead of the heap objects I'm using now. Span wasn't available when J2534Sharp was originally written, and the heap objects I invented were my answer at the time. Span would be far superior for memory usage, and may provide a modest performance boost. Truly though, if the heap copy is the source of your delay, I believe the actual issue is elsewhere as doing a memcopy over a few bytes should be so fast it should be almost unnoticeable. Certainly not in the millisecond range.

Brian