Odd network problem with OS 2.10

[stoic-one]

When connected to my network, I'm getting ST145 and ST146 comm warnings.
I've replicated this with the following CPU's:
BX-DM1E-M-D manufactured 08/24 shipped with 2.10.3, the software will not let me roll this unit back to an earlier version.
BX-DM1E-M manufactured 03/24 updated from 2.9.8 to 2.10.3
BX-DM1E-36ER3-D manufactured 05/24 updated from 2.9.9 to 2.10.3

If I alternate back and forth between 2.9.x and 2.10.x, in the above cases, when 2.10.x OS is installed I get a network error. I can still connect with the processor, but it's slower than normal.

It's an all gigabit home network, but needless to say there's a fair amount of non-industrial stuff going on in the background. I've isolated it to HDMI over Ethernet device. When I disconnect it the error clears when using 2.10.x.

I also tried this with a T1H-DM1E manufactured 06/19
Which did NOT have this problem after being updated from 2.9.6 to 2.10.2, it's a Do-More, but it's not a BRX.

I'm not saying there's a problem Host necessarily needs to fix here as I've never observed this in an actual installation at a customer site. Of course 2.10 is also relatively new, so who knows...

I am however curious what might be the differences between 2.9.x and 2.10.x on the BRX platform that would cause this.

[BobO]

Certain hardware cannot roll back because there were hardware changes that require newer firmware. Yet another pain caused by the supply chain crisis.

This error happens when all of the packet buffers are used, generally with packets the PLC isn't sure what to do with. Sometimes it is transient due to a massive broadcast packet burst, but sometimes stuff is hung in the stack. There may be things we can do to mitigate it if we could determine what's getting stuck. There are some network diagnostics in 2.10 (BRX) that might give us some insight into what's happening. If it is pretty repeatable, we can talk you through what it takes to get the diagnostic dump.

[stoic-one]

Good morning BobO, I'm open to whatever you would need done to drill down into this.

[BobO]

Good morning BobO, I'm open to whatever you would need done to drill down into this.

Hit us at support@hosteng.com and I'll give them heads up.

[stoic-one]

Done

[BobO]

Just to tie this one up for any who may search later...

There was a video broadcast device that was filling the PLC's receive queue. The PLC did handle the traffic correctly; the flags are there to communicate the overrun. Despite the OP not seeing the "problem" on 2.9.x, we did duplicate it easily there as well. Most likely the load was just slightly over the threshold to get flagged on 2.10.x  and the older firmware version didn't quite get to the level to trigger the alarm. We added Ethernet/IP Scanner in 2.10.x, which added some additional multicast code to the IP stack, which could have easily shifted the stack performance enough for 2.9.x and 2.10.x to be slightly different.

Bottom line: PLC is working as designed. Broadcast traffic should be limited/isolated on control networks. It isn't a problem and we do use broadcasts ourselves, but high bandwidth devices like video feeds either need to use unicast or be isolated from time critical networks, particularly when using embedded devices that may not be capable of doing everything they do (like PLC's solving logic) and handling high bandwidth network data.