Closed SumeetPJain closed 10 years ago
Sumeet,
I'm unaware of any issues with MSRP itself. We use it and have 125usec packet throughput through our Extreme AVB switch. Have you done a wireshark capture and confirmed the MSRP bandwidth reservations are what you expect them to be? I'm not using simple talker as a packet source though.
From: "engineerdrmz" notifications@github.com Sent: Thursday, August 15, 2013 2:12 AM To: "intel-ethernet/Open-AVB" Open-AVB@noreply.github.com Subject: [Open-AVB] ~ Ethernet AVB switch ~ (#15)
Hie, We are running talker and listener programs for streaming audio/video data. We are using Intel I210 ethernet AVB cards on both the sides. We are using AVB protocol stack downloaded from this github. When we establish a direct connection between the talker and listener we are able to get the expected Inter packet Gap(IPG) of 125usec but after deploying AVB ethernet switch the expected value gets disturbed and it shows around 900-1000usec. What I am assuming is that the msrp module that we are running on talker side is failing to reserve the resources(bandwidth) along the talker-switch-listener path. Is my assumption correct ? And if not what can be factors that are affecting IPG of packets received at listener side ?
Any help will be a great relief.
Regards, Sumeet Jain
Reply to this email directly or view it on GitHub.
Hello Andrew, Thanks for your time and response. Yes As we are able to receive "Listener Ready" frames on the talker side , we can make out from that that the BW reservations are taking place.And we are able to receive all the packets at the listener side with IPG=900-1000usec. But our expectations for IPG are 125usec. Then afterwards I started looking at gPTP daemon. Actually with gPTP daemon running at the application layer i.e the timestamping is deployed at application layer due to which may be our packets are suffering the delays , latencies and jitter as they have to pass through the PHY interface --> MAC --> Processor --> OS(Schedulinh Algrithms and Software Latencies) --> Application. Now With the switch deployed between the talker and listener , the offset between the master and slave clock will of the order of microseconds due to latency produced by switch(Residence time) and due to the main reason that the timestamping is been done at application layer at both the sides(Talker and Listener). So may this problem can be resolved by having timestamp done at "PHY layer" or at "MAC Layer" that will not into account the software latencies and other delays.
Regards, Sumeet Jain
I'm sorry ... I'm still not clear what the configuration is which is showing the problem, and how the problem is being determined.
Is it [[Talker] [I210 NIC]] <---->[[I210 NIC][Listener]]
or is there a Marvell-based AVB switch (dsp4u?) in between?
And the 'late' packets are being measured at the app layer of the 'listener' side? (tcpdump would likely be more accurate if unfortunately more difficult to decode).
Yes the configuration You are showing is absolutely correct with AVB switch(dsp4u) switch in between the talker and listener. Yes we are using " wireshark" as protocol analyser. And we are receiving all the packets at listener side but not with the expected IPG of 125 usec.
Regards, Sumeet Jain
And without the switch the problem disappears?
You should be able to hook up a listener to a talker directly and they should work … there’s a bug I need to fix in simple_talker where it (should) advertises the default vlan ID and priority in a domain message and then resolve if the switch reports something different … if both listener and talker are using the same settings you won’t see the effect/issue.
ekm
From: engineerdrmz [mailto:notifications@github.com] Sent: Monday, August 19, 2013 9:34 PM To: intel-ethernet/Open-AVB Cc: Mann, Eric Subject: Re: [Open-AVB] ~ Ethernet AVB switch ~ (#15)
Yes the configuration You are showing is absolutely correct with AVB switch(dsp4u) switch in between the talker and listener. Yes we are using " wireshark" as protocol analyser. And we are receiving all the packets at listener side but not with the expected IPG of 125 usec.
Regards, Sumeet Jain
— Reply to this email directly or view it on GitHubhttps://github.com/intel-ethernet/Open-AVB/issues/15#issuecomment-22922017.
Yes without the switch the problem disappears as we are getting the expected IPG of 125usec. Can you give more details on the bug in "Simple_Listener" Program you are talking about ?.
Regards, Sumeet Jain
A feature of AVB is the talker as well as all the switches in-between the talker and the listener 'shape' the stream traffic ... which means as you scale up the number of streams, you may not see packets exactly 125 usec apart. In a simple, single stream case with proper stream reservation however I would expect a packet every 125 usec (for Class A).
The defects I'm talking about are here (in simple_talker.c, and presumably simple_listener as well):
mrp_register_domain(&class_a_id, &a_priority, &a_vid); /* correct - advertise default domain parameters */
/* ... but then simple_talker should call mrp_get_domain() to see if there is a mis-match with the peer */
/* ... and lastly simple_talker should register with the AVB vlan with mvrp as well! */
They are on my list of things to fix ...
Are there still open issues with this thread?
can anyboday share your mail ID or contact info since i am ahving issues at the basic level i need guideance can any one call me up or send me a mail. my mail: admin@debmego.in
i have issues with hardware drivers and simpletalker and listener program is having some issues.
Hie, We are running talker and listener programs for streaming audio/video data. We are using Intel I210 ethernet AVB cards on both the sides. We are using AVB protocol stack downloaded from this github. When we establish a direct connection between the talker and listener we are able to get the expected Inter packet Gap(IPG) of 125usec but after deploying AVB ethernet switch the expected value gets disturbed and it shows around 900-1000usec. What I am assuming is that the msrp module that we are running on talker side is failing to reserve the resources(bandwidth) along the talker-switch-listener path. Is my assumption correct ? And if not what can be factors that are affecting IPG of packets received at listener side ?
Any help will be a great relief.
Regards, Sumeet Jain