CAN@Net NT 200 Throughput

Ixxat Support CAN Bridges/Gateways
#1

I have an CAN@Net NT 200 card. I have the card setup as an ASCII Gateway. What kind of transmission rate limit can I expect from the card?

It appears with the card receiving 4 CAN IDs of 8 bytes each at 200 Hz that the received information is not consistent.

Is there a better method to receive data?

Thanks,
Eldon

#2

Hello @eldonz,

As mentioned over the phone I have created an internal ticket to investigate this issue. Once I have reviewed this with my colleagues in Germany I will follow up with you.

Regards,
Deryck

#5

Deryck,

Any update?

Thanks,
Eldon

#6

Apologies I had messaged you through the support ticket I had made for this issue. Here is the message I sent you earlier in the week.

Would you be able to provide a description of the inconsistent data you are getting from the CAN@net? My colleagues are looking for more detail then what I was able to provide following our phone conversation.

I believe you discussed this issue with the TCP stack but I want to make sure you still have this info from my colleagues.

The ascii interface is a standard TCP port.
The user, who implements an application on the ascii interface, should be aware of some common issues of TCP.
See for example the document from Microsoft:
Design issues - Sending small data segments over TCP with Winsock
https://support.microsoft.com/en-us/help/214397/design-issues-sending-small-data-segments-over-tcp-with-winsock

This document handles also the “200ms delayed ACK” mechanism of TCP. To work around this, you can do:

  1. disable the delayed ACK on the host machine for the whole network adapter:
    See for example: http://freevbsite1.blogspot.com/2015/07/disable-tcp-ack-delay-time-on-windows-7.html

  2. Send cyclically (e.g. 30ms) a message from the host machine e.g a CAN status request (“CAN 3 STATUS”).
    This request/response messages work around the 200ms delayed ACK

#8

Deryck,

Any thing new on the problem?

Thanks,
Eldon

#9

Would you be able to provide a description of the inconsistent data you are getting from the CAN@net? My colleagues are looking for more detail then what I was able to provide following our phone conversation.

I believe you discussed this issue with the TCP stack but I want to make sure you still have this info from my colleagues.

The ascii interface is a standard TCP port.
The user, who implements an application on the ascii interface, should be aware of some common issues of TCP.
See for example the document from Microsoft:
Design issues - Sending small data segments over TCP with Winsock

This document handles also the “200ms delayed ACK” mechanism of TCP. To work around this, you can do:

disable the delayed ACK on the host machine for the whole network adapter:
See for example: http://freevbsite1.blogspot.com/2015/07/disable-tcp-ack-delay-time-on-windows-7.html

Send cyclically (e.g. 30ms) a message from the host machine e.g a CAN status request (“CAN 3 STATUS”).
This request/response messages work around the 200ms delayed ACK

#11

Deryck,

I followed up with an email when you first asked this question. Did you not receive it? You might want to check your SPAM folder. I’ve included my response below:

As I mentioned earlier, I have already changed the Win OS settings for TCP Ack issues as I’m aware that this can be an issue from previous experience with other TCP/IP equipment.

I have a timer that is looking at the time between CAN messages as they are received. The CAN messages are coming across at 200 Hz and the time between messages is typically 4-5 mS which is correct. The problem is I will get other times around 7-9 mS.

What is the number of CAN messages that I can expect to be able to receive per second using the ASCII Gateway?

Is there a better interface that I should be using that would help with this issue?

Thanks,
Eldon

#12

Hi Eldonz,

Sorry for they delay I am waiting to hear back from my colleagues in Germany regarding these questions.

The data you are receiving is it just missing CAN frames? or is it particular transactions missing? Is there any consistency with what is missing?

Deryck

#14

Deryck,

Anything back from Germany?

Thanks,
Eldon

#15

Hi Eldonz,

I apologize for the delay I typically hear back from them quicker, will be checking I checked in with them last week and still never hear back. I will check in with them and follow up with you. With the holiday I will most likely get back to you Monday.

Deryck

#16

  1. As you wrote you are losing some of a messages or they are coming in inconsistently and not at the same rate they are sent on the CAN bus.

    “I have an CAN@Net NT 200 card.
    I have the card setup as an ASCII Gateway.
    What kind of transmission rate limit can I expect from the card?
    It appears with the card receiving 4 CAN IDs of 8 bytes each
    at 200 Hz that the received information is not consistent.”

    4 (Msg) x 200 (Hz) = 800 Msg/Sec

    The CAN@net NT can receive about 8000 Msg/Sec.
    The CAN@net NT can transmit about 4000 Msg/Sec.

  2. Is there a better interface that I should be using that would help with this issue?

    The CAN@net NT has a better performance than
    the performance of the CANblue II.

    The best performance you can get using a PCIe slot boards like CAN-IB200/PCIe.
    The average response time of the CANblue II is about 13ms.
    The average response time of the CAN@net NT is about 4ms.
    The average response time of the USB-to-CAN V2 is about 1ms.
    The average response time of the CAN-IB200/PCIe is less than 0,5ms.

  3. I have a timer that is looking at the time between CAN messages as they are received.
    The CAN messages are coming across at 200 Hz and
    the time between messages is typically 4-5 mS which is correct.
    The problem is I will get other times around 7-9 mS.

    I would say that the 9ms runaways are not the worst runaways for Ethernet, because
    the Ethernet and Windows operating system are not real-time able

#17

Topic closed due to inactivity.