Clear transmit buffer (of pending queued tx-messages)

Clear transmit buffer (of pending queued tx-messages)

[ajneu]

Hi,

how do you guys handle clearing of the transmit buffer?
(Usage-case example:
Imaging: buffer is filled with tx-messages, but no other participant on the
bus. After 1 minute, those queued tx-messages are outdated. We definitely
want to clear the queue, to prevent those messages from getting sent out, if
a participant connects to the bus again.)


I think... 
that one has to distinguish between 
a) non-blocking or blocking mode of write... on the userspace side;
and 
b) the buffering in qdisc
c) the buffering of tx-messages queued inside the CAN controller itself.

Whew!

Concerning 
a)
Is it correct that I need non-blocking, if I want to prevent userspace
sticking in blocking write calls? 
(Or is it possible to get a blocking write call to return immediately?
Perhaps sending a signal?)

Concerning 
b) and c)
How does one clear the qdisc and messages still queued inside the CAN
controller?
One method is probably using libsocketcan and issuing can_do_stop() followed
by can_do_start()... Would that work?
Any other possibilities?
Anybody willing to share some best practices?

Thanks.
ajneu

Re: Clear transmit buffer (of pending queued tx-messages)

[ajneu]

Oliver Hartkopp <socketcan <at> hartkopp.net> writes:

> 
> The question is whether blocking write (and probably write outdated 
> content) is what you want for CAN.

Oliver Hartkopp posted that on a different thread...
Subject: Re: want blocking writes, but eventually get: errno 105 (No buffer
space available)
Date: 2016-06-22 15:52:04 GMT (15 hours and 32 minutes ago)

OK ->

I've tried non-blocking.
Unfortunately non-blocking will not tell you if messages are delivered or not.

Example:
If I send out 2 messages (non-blocking) with no participant on the bus,
those messages will remain queued.
If 5 minutes later a participant joins the bus, he'll get those 2 very old
messages: outdated content.

What are my options to solve this?
(Can I find out if a message has actually been sent out onto the bus?)
(I'm currently thinking about checking the CAN-Bus status: If NOT
error-active (and high tx count), I know that tx-messages will not get
delivered.
But if I had a few messages in the queue, I still cannot tell which ones got
delivered. Hmmmm...
  ***)
)

Thanks,
ajneu


PS:
  ***)
Perhaps in some cases it does not matter to know which messages actually
still got delivered and which not.
In that case, when the program detects NO-longer-ERROR_ACTIVE, it can enter
into an error-state "waiting for online":
first it does can_do_stop followed by can_do_start, to clear the queue. Then
it just sends periodic messages, until it get's back_to_error_active.
Once it get's back_to_error_active, it it back "online".
Thoughts?

Re: Clear transmit buffer (of pending queued tx-messages)

[Wolfgang Grandegger]

Am 23.06.2016 um 10:45 schrieb ajneu:
> Oliver Hartkopp <socketcan <at> hartkopp.net> writes:
>
>>
>> The question is whether blocking write (and probably write outdated
>> content) is what you want for CAN.
>
> Oliver Hartkopp posted that on a different thread...
> Subject: Re: want blocking writes, but eventually get: errno 105 (No buffer
> space available)
> Date: 2016-06-22 15:52:04 GMT (15 hours and 32 minutes ago)
>
> OK ->
>
> I've tried non-blocking.
> Unfortunately non-blocking will not tell you if messages are delivered or not.
>
> Example:
> If I send out 2 messages (non-blocking) with no participant on the bus,
> those messages will remain queued.

Yes, in software but also hardware queues.

> If 5 minutes later a participant joins the bus, he'll get those 2 very old
> messages: outdated content.

Yep.

> What are my options to solve this?

The only method I know to flush the queue is restarting the device 
(down->up).

> (Can I find out if a message has actually been sent out onto the bus?)

If you really need to known, you could check for the looped back message 
on the same socket enabling CAN_RAW_RECV_OWN_MSGS. But it will slow down 
the message transfers.

> (I'm currently thinking about checking the CAN-Bus status: If NOT
> error-active (and high tx count), I know that tx-messages will not get
> delivered.

Well, the errors could also be caused by other issues. You could check 
for no-ack bus error messages but not all CAN controllers support that 
feature.

> But if I had a few messages in the queue, I still cannot tell which ones got
> delivered. Hmmmm...

See above.

Wolfgang.

Re: Clear transmit buffer (of pending queued tx-messages)

[Kurt Van Dijck]

On 23 June 2016 11:26:17 CEST, Wolfgang Grandegger <wg@grandegger.com> wrote:
>Am 23.06.2016 um 10:45 schrieb ajneu:
>> Oliver Hartkopp <socketcan <at> hartkopp.net> writes:
>>
>>>
>>> The question is whether blocking write (and probably write outdated
>>> content) is what you want for CAN.
>>
>> Oliver Hartkopp posted that on a different thread...
>> Subject: Re: want blocking writes, but eventually get: errno 105 (No
>buffer
>> space available)
>> Date: 2016-06-22 15:52:04 GMT (15 hours and 32 minutes ago)
>>
>> OK ->
>>
>> I've tried non-blocking.
>> Unfortunately non-blocking will not tell you if messages are
>delivered or not.
>>
>> Example:
>> If I send out 2 messages (non-blocking) with no participant on the
>bus,
>> those messages will remain queued.
>
>Yes, in software but also hardware queues.
>
>> If 5 minutes later a participant joins the bus, he'll get those 2
>very old
>> messages: outdated content.
>
>Yep.
>
>> What are my options to solve this?
>
>The only method I know to flush the queue is restarting the device 
>(down->up).
>
>> (Can I find out if a message has actually been sent out onto the
>bus?)
>
>If you really need to known, you could check for the looped back
>message 
>on the same socket enabling CAN_RAW_RECV_OWN_MSGS. But it will slow
>down 
>the message transfers.
>
>> (I'm currently thinking about checking the CAN-Bus status: If NOT
>> error-active (and high tx count), I know that tx-messages will not
>get
>> delivered.
>
>Well, the errors could also be caused by other issues. You could check 
>for no-ack bus error messages but not all CAN controllers support that 
>feature.

CAN is like datagram networks. You will never know if the intended receiver actually got the message until he replies. This semantics impact the communication design. All actions above make the code hard to write but not significant better.

Kurt

Re: Clear transmit buffer (of pending queued tx-messages)

[Tom Evans]

On 23/06/16 18:45, ajneu wrote:
> Oliver Hartkopp <socketcan <at> hartkopp.net> writes:
>
>> The question is whether blocking write (and probably write outdated
>> content) is what you want for CAN.
>
> I've tried non-blocking.

I think you're trying to use the "available tools" to solve a different problem.

> Example:
> If I send out 2 messages (non-blocking) with no participant on the bus,
> those messages will remain queued.
> If 5 minutes later a participant joins the bus, he'll get those 2 very old
> messages: outdated content.
>
> What are my options to solve this?
 >
> (Can I find out if a message has actually been sent out onto the bus?)

Yes. You have THE OTHER END reply to a message stating "I've received it". 
"Message receipt" isn't CAN's problem. That's a higher level construct.

If you don't want the other end getting "outdated content", than have the 
sender queue up unimportant messages that don't have any time sensitive content.

So when the sender comes up it should send an "I'm here" or a "are you there?" 
message, and not send anything else until it gets some form of "I'm alive" 
message from the other end. Then you send "the real content".

Tom