Rate limit the sending of consecutive frames regardless of server request

[dpatel20]

I am on Windows using Vector HW. I use udsoncan to perform a transfer data operation in 4KB blocks with python-can-isotp as the TP layer.
The server, in its flow control, has stmin=0 so python-can-isotp sends as fast as possible. However, it seems the Vector driver sometimes can't handle the fast rate and throws a XL_ERR_QUEUE_IS_FULL error.

According to this page:

You have a program that writes messages very quickly to the buffer so that the data rate of the real bus is exceeded (e.g. while-/for-loops).

Suggesting that the bus data rate needs to be respected to avoid this error.

Therefore, I'd like to rate limit the transmit. Is there a way to have python-can-isotp set a minimum value for transmit stmin? i.e. if server gives stmin=0, we still limit it to some value (e.g. 1ms separation)? Perhaps based on the bus rate?

[pylessard]

That's a good point. I could allow override of stmin. But even better, we could specify the internal buffer size. Like that it would be possible to do a rate limiter without pausing betwern each consecutive frame.

Will have a look

[pylessard]

Hi @dpatel20
Can You give a try to the branch named support-rate-limiter

Here's the documentation

Set rate_limit_enable = True

Then
The product of rate_limit_max_bitrate and rate_limit_window_size will define the maximum burst size the driver will need to withstand. I suggest you to reduces rate_limit_max_bitrate until everything works as expected

I will merge once you validate that this fixes your problem

[dpatel20]

Hi -

Thanks for the new feature! I have tested it and can confirm it works well. I modify the rate_limit_max_bitrate and it does indeed limit the throughput and I no longer get buffer full errors.

I tried it with a very high busload too and was able to drop the rate_limit_max_bitrate and still get it to work.

[pylessard]

Merged. Will be included in next release.
Thank you for your feedback!

[pylessard]

Documentation is also updated
https://can-isotp.readthedocs.io/en/latest/isotp/implementation.html#rate-limiter

[notmmao]

I'm not sure if I should reopen this issue.

#62
When a TRANSMIT_FF_STANDBY msg is determined to be sent, the tx_state should be changed to WAIT_FC instead of IDLE.
Otherwise I always get error:
Received a FlowControl message while transmission was Idle. Ignoring

my params:
{'tx_padding': 0, 'blocksize': 0, 'rate_limit_enable': True, 'rate_limit_max_bitrate': 64000, 'rate_limit_window_size': 0.001}

[pylessard]

Oh, that looks like a bug indeed.
TRANSMIT_SF_STANDBY --> Should go to IDLE when unlocked
TRANSMIT_FF_STANDBY --> Should go to WAIT_FC when unlocked

[pylessard]

I forgot about this one. Reopening to fix the bug raised by @notmmao

[pylessard]

I fixed this.