You are not logged in. Please login or register.
RME User Forum → AVB/Dante - Network based devices → 1620 AVB/Milan Interopability Testing - Video
Hey I made a video to demonstrate and memorialize my testing of a 1620 working (or not) with various other Milan devices and setups.
It would be great if the various manufacturers could work together to fix these issues, but I doubt it will happen.
Hi, thanks for the extensive testing and report!
Did you by any chance download the network state from Hive or Milan Manager after the errors occurred? In particular it would be interesting to see what changed between the no-errors-small-netgear(10G2F) network and the has-errors-small-netgear network. Because that worked first for a couple of days, and then for some reason it started presenting errors (I believe after a week in?).
Could you also provide the exact firmware versions of the Netgear switches that were installed on all switches?
Thanks,
Max
RME
All the Netgears are running 13.0.5.16 which is the latest available through their website.
I did not grab any logs from Milan Manager or Hive, i DID grab some tech support download files from the large Netgear switches from from various points including:
Large Netgear during errors.
Large Netgear right after a re-boot not yet presenting errors.
Small Netgear when not presenting errors - about 3 days in.
Large Netgear in the P1-P1 test which worked fine the entire time.
Are you in touch with the ProAV support team of Netgear? Have you supplied them with the video link and log files? You can PM me with any details and I will chime in to your support request. You can also CC: me on your conversation with them, I am sure both sides have an interest to understand the underlying problem.
I have been in touch with Netgear AV Support.
At one point early on in the process they logged in remotely to one of our test setups to see if they could determine a root cause, with no luck.
I did also send them my testing video and i believe they have watched it.
I will try to loop you in.
From what I see in the videos, it seems your M4250 switches became gPTP grandmaster. The switches are not certified for AVB as grandmaster, in fact I have doubt that they could reliably act as one over long periods of time because they do not have a clock for gPTP (this was confirmed by Netgear years ago). You could try to go into the Main UI: Switching > 802.1AS > configure local clock priority 1 and 2 to "255", which ensures that it does not become grandmaster.
At one point early on in the process they logged in remotely to one of our test setups to see if they could determine a root cause, with no luck.
I read in Netgear's support case (thanks for looping me in) that they apparently did find a root cause weeks ago and are asking us whether we could provide "some flexibility in delaying MSRP/gPTP initialization on our end". I was not aware of that until yesterday.
It is NOT safe to assume all Milan devices will work well together.
MILAN describes endpoints that are connected over AVB switches. In the configuration you tested, you are not using a tested or certified AVB switch.
It appears beyond the Milan "standards" the manufacturers don't/can't test their products thoroughly with other manufacturer's units.
They are tested extensively with other manufacturers units. However with over 130 certified switches on the market, it would take forever to test all product combinations. When we confirm that you are on a certified switch (hardware, firmware, configuration), we test immediately to confirm if you indeed found a problem that we could address with an update.
It would be great if manufacturers like #RME and #Netgear would try to address these issues, but it seems unlikely.
Please always confirm with Netgear that you are using the device in its certified configuration.
I am not sure I totally understand your statement, that we are testing with a non-certified AVB switch?
The netgear M4250 is indeed a AVB certified switch. And we use the standard Netgear AVB "profiles". I believe the entire line of M4250 series is AVB certified.
In fact, in our troubleshooting we had Netgear remote in and re-load the firmware and re-establish all the profiles. It still failed.
Regarding the gPTP master:
I have previously queried Netgear regards to their ability to act as a gPTP master, and this functionality has been added.
In fact, when searching this problem, I found an old post on this forum that led me to ask Netgear. The old post, wherein it was stated Netgear cannot function as a clock is now incorrect.
Here is what they said in an email:
"Hi Jon,
we've done some changes in recent firmware, the switch can now act as the Grandmaster (GM) for gPTP.
In the main UI, you’ll find the option to adjust priorities under the 802.1AS settings. Here, you can configure both Priority 1 and Priority 2 values.
I’m currently not in my office, but if you have trouble locating the settings, I’d be happy to send you the steps tomorrow morning.
With the switch set as GM, this should resolve the issue on your end.
Thank you, "
When I searched the release notes of their firmware, it appears that this was added on their firmware 13.0.4.23
"Added 802.1AS Grand Master capability"
https://kb.netgear.com/000066227/M4250- … -13-0-4-23
I would further add: the test wherein we ran P1-P1 through Netgear switches, the Netgears WERE the gPTP master and this ran successfully for several days. I recall I noted on each system a shot of the gPTP master, including this system.
I understand this might not be a solvable problem, and I believe this is one of the risks of using an open protocol such as Milan.
I guess if nothing can be done, we will just lick our wounds, and move on. We have over a hundred netgear switches (all running AVB) and only about 15 RME units, so I guess the RME, sadly, will not win out......
OH, and I would just add with regards to:
However with over 130 certified switches on the market
I agree there a LOT of switches on the market, but really in Pro-AV, at least in the US, there are really only 3 brands IMHO:
Netgear, L-acoustics, Luminex
And from that, for audio, I mostly see Netgear and L-acoustics.
I have not seen a Cisco or Extreme or anything else deployed for for Milan in an audio environment.
But that is just my opinion and experience.
Hi Jon,
as you can see in the certificate, the switches were certified when gPTP GM functionality was not included (firmware 13.0.2.x):
https://cms.avnu.org/certificate/502
I had found similar issues after 3 days operation back in 2022. Back then, Netgear PM responded that the 4250 cannot act as GM and that this is a hardware restriction (it could at that time not be added because the device does not have a clock for that). Now they have re-added the GM functionality (probably using an existing clock that now serves multiple purposes), but I have confirmation from Netgear that this has not been tested or certified at AVNU.
Fair enough, that they have added their gPTP support after certification.
The issue for us: if you have a network of all netgear switches and a P1 talking to some LA12x, the BMCA selects our Mac's network adapter as the gPTP. This is not ideal for a number of reasons including:
1) the mac is a transient member of the network. And when it leaves, although fast, the network does have to switch the gPTP GM , and this does not always happen without hiccups in our experience.
What we have seen: your show is about over, 5 minutes left, so you decide to shut down your Mac, and everything flashes "Orange". This is unsettling.
And we have no way to influence the BMCA to select another clock such as an endpoint (the p1 or the 1620) that I know of.
There is no "priority" setting accessible like on the switches.
So the solution we were given by Netgear was to influence the BMCA by adjusting the switch's priority settings.
I guess I can ask Netgear about the status of their switch certification as it relates to gPTP. But I suppose it is academic at this point.
I could also run a long test with 1620 feeding a 1620, netgear switches, with another gPTP master, which it might select, or I could influence, say by adding an LS10 with a Priority adjusted, acting JUST as the gPTP master and otherwise not "in the mix", so to speak. But that all might be academic too.
I fully understand your points and I agree that it seems better to let one of the switches become GM. I actually like the fact that Netgear added GM capability, I just have no information on it in terms of how well it is implemented and tested. I am sure Netgear will chime in and give updates on that in the near future and we can provide updates here.
You are right to ask why the CRF output stream of the M-1620 gets into a state where other devices cannot properly lock to it anymore, whereas the P1, also MILAN certified, does not show this behavior in your test. And you are also correct to conclude from this that apparently, two MILAN devices do not behave the same way, and that this is unexpected. As with the other thread you started on the forum about this issue, we do want to get to the bottom of that and understand what is happening.
Since long term tests succeed on Luminex and L'Acoustics switches, it's best if Netgear tells us what is happening. Their initial root cause analysis contained a couple of apparent misunderstandings on how AVB works, so I am waiting for them to re-evaluate if their current stack is in their eyes fully AVB compliant. Once they clear up the misunderstandings and confirm they expect to pass re-certification and can act as GM reliably, we will investigate in detail again. Thanks for your patience.
I could also run a long test with 1620 feeding a 1620, netgear switches, with another gPTP master, which it might select, or I could influence, say by adding an LS10 with a Priority adjusted, acting JUST as the gPTP master and otherwise not "in the mix", so to speak. But that all might be academic too.
If you have the time and capacity to do that test, this would actually be interesting (esp. with LS-10 as a GM).
And if Errors apear in Milan Manager, please save the entire network state in Milan Manager (once before the errors show up, and once after the errors show up). You can save the network state right from the main menu and it creates an mmns file with lots of relevant info for us. Thanks!
OK, test started:
1620 talking to another 1620, using Netgear large switches, with an LS10 attached, NOT passing AVB traffic, but acting as gPTP GM.
I have completed more testing, using a 1620 talker and listener connected via Netgear switches.
In the test, I use an LS10 as the gPTP GM and then switch to the Netgear as the GM.
The results: It does not seem that the 1620 can agree on the network time when using the Netgear as the GM.
It is too bad, as previously in testing the Netgear worked fine using a P1 talker/listener combo.
There is not much that I can do as a consumer except to thoroughly test any potential combinations. It is not safe to assume interoperability between devices.
Thanks for confirming that it works when you use AVB certified switches (you tested almost a week in the video, great!!!). If the P1 is more tolerant to the performance/behavior of the newly added grandmaster capabilities from recent, uncertified Netgear firmware releases than this is understandably annoying for you as a consumer, but impossible for us to prevent as a manufacturer. You did the right thing to contact Netgear about this and we are doing our best to support the case from our side.
Update on some more testing: I just tested for about 12 days with Luminex switches, where they are switches and are set as the gPTP GM.
Worked great, no problem.
So it really comes down to the Netgear's not being suitable to perform the network clock duties. We shall see if they can fix their issues.
RME User Forum → AVB/Dante - Network based devices → 1620 AVB/Milan Interopability Testing - Video
Powered by PunBB, supported by Informer Technologies, Inc.