Stream reservation taking more time than expected.

[JXter]

While checking openavb_harness in PC, I am observing seconds of variation in the stream reservation. Sometimes it completes the reservation immediately and sometimes it takes about 10 seconds for the reservation to happen.

[1545043541:427867440 OPENAVB HAL Ethernet] INFO: TX buffers: 40
[1545043541:427877861 OPENAVB HAL Ethernet] INFO: IGB launch time feature is DISABLED
[1545043541:448069595 OPENAVB Endpoint SRP] INFO: detected domain Class A PRIO=3 VID=0002...
[1545043541:448074168 OPENAVB Endpoint SRP] INFO: detected domain Class B PRIO=2 VID=0002...
[1545043541:449900928 OPENAVB Talker / Listener] INFO: Looking up symbol for function: openavbMapH264Initialize
[1545043541:449918655 OPENAVB Talker / Listener] INFO: Looking up symbol for function: openavbIntfH264RtpGstInitialize
[1545043541:451608459 OPENAVB Listener] INFO: Attach ba:bc:1a:ba:bc:1a/55

After waiting.

[1545043544:268996029 OPENAVB Endpoint] INFO: SRP listener callback uid=55: tlkrDecl=1
[1545043544:269240723 OPENAVB Listener] INFO: Starting stream: ba:bc:1a:ba:bc:1a/55

After debugging I found that, endpoint is waiting for some events from mrpd and this is causing the difference. In MRPD, I found 4 timer values, defined as

#define MRP_JOINTIMER_VAL   100 /* join timeout in msec */
#define MRP_LVTIMER_VAL     1000    /* leave timeout in msec */
#define MRP_LVATIMER_VAL    10000   /* leaveall timeout in msec */
#define MRP_PERIODTIMER_VAL 1000    /* periodic timeout in msec */

I am not sure, changing this value is the right way of solving this. Is there any better way to fix this?

[andrew-elder]

You could turn on mrpd debug logging if you need to see more information. Are you saying that you are watching the talker and there is a delay for the mrpd daemon running on the talker to report that a Listener Ready attribute from the listener has been registered? Do you know for sure when the Listener Ready was observed by mrpd? It may be that the listener side is slow to declare it.

I'm not aware that the type of issue you report here is an issue with mrpd. I'm not saying that it isn't possible, I just haven't observed it.

[JXter]

I am observing on the listener side and listener endpoint is waiting for the talker declaration. Since I have started talker first, in wireshark I am seeing talker declarations packets has arrived at the interface before starting listener itself.

[JXter]

When a new listener tries to join a stream, will the mrpd immediately give information about talker declarations registered or will it wait for the next talker declaration to arrive in listener side?

[pinealservo]

The 10 second issue sounds like it's having to wait for a LeaveAll timer to expire. I'm afraid I can't remember the details of what APIs are used by the endpoint to communicate with mrpd and whether mrpd will store talker advertise registrations for which no declared listener ready declaration exists locally.

You wouldn't want to change the LeaveAll timer itself, but you might want to trigger a LeaveAll when the endpoint connects to mrpd and lets it know what it's interested in, to force its peer to re-declare, if it's not storing the talker attributes of the other endpoint.

As Andrew suggested, I'd try turning on more verbose logging from the different pieces to see how they're interacting and how that matches up with wireshark traces. I don't recall running into this issue before, but it's possible I never ran things in exactly the configuration you are.