Film-Tech Forum ARCHIVE: Jumbo Frames crash JNIOR

This is topic Jumbo Frames crash JNIOR in forum Digital Cinema Forum at Film-Tech Forum ARCHIVE.

To visit this topic, use this URL:
https://ft-forum.com/ft/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic;f=16;t=003487

Posted by Bruce Cloutier (Member # 9615) on 11-04-2018, 03:25 PM:

The Series 4 JNIOR has trouble with "Jumbo Frames" and by extension "Super Jumbo Frames". Okay, these are frames/packets on the network that exceed the standard MTU of about 1500 bytes. I suspect that IMAX installations use these large packets. This has been permitted by network standards for a few years now I think. These frames can contain well over 9,000 bytes each. As you might imagine it is more efficient that way.

Does anyone know for sure if this is the case for IMAX or if any other systems document use of the larger network frames?

This is my bad as they say. I have corrected the incompatibility in JANOS v1.7.1 which is currently a Release Candidate. I'll get this out before the end of the year.

Normally this is not a problem as network switches would keep the large frames from ever reaching the JNIOR. That would explain how we have gone so long without discovering this issue. I suspect that some routers when configured for 10Mbps half duplex operate as a hub and end up sending the frame to the JNIOR (albeit very slowly).

I understand that some NCM techs have known for a while to make sure that routers are not configured for 10Mbps when using the JNIOR. These things should always be configured to auto-negotiate IMHO. But the issue, I am pretty sure, are these Jumbo Frames.

The JNIOR crashes when connected to the malconfigured (again IMHO) network carrying these frames and may need to be rebuilt/reloaded. So it is not a nice thing. Sorry about that. Thankfully this has not been a frequent issue for anyone.

If anyone has experienced this and would like to confirm the correction for me/us please get in touch. I would be happy to supply the Release Candidate code for your use. I am waiting to hear from the recent site but they have reconfigured the router and now assume that the issue has been rectified. They've masked the symptom which is an acceptable work-around. I would like to confirm the solution if I can.

Posted by Leo Enticknap (Member # 534) on 11-04-2018, 04:43 PM:

Jumbo frames are quite frequently used to transfer DCP content between TMSes and screen servers. I recently set up a management LAN using an MTU of 9,000 for these transfers, but all the switches are managed and there are no JNIORs in that system. From what you describe, I'd guess that this is only likely to cause a problem in a management LAN in which the switches are unmanaged, jumbo frames are in use between two unrelated (to the JNIOR) devices, and there are JNIORs present on that subnet.

Posted by Marcel Birgelen (Member # 6801) on 11-04-2018, 06:48 PM:

Jumbo Frames make sense where large chunks of data are being transferred. So, you can see them on the networks or VLANs between TMSes and Screen Servers, like Leo mentioned, but also often on "storage networks", e.g. the networks that connect servers to storage backends like NASes and IP-based SANs (especially iSCSI).

Many modern switches allow jumbo frames to be enabled on a VLAN and/or port-basis. So, some switches effectively allow you to block jumbo frames from ever reaching a device behind a specific port, by simply dropping those frames.

In the past, it was also pretty usual to have to enable the Jumbo Frames support on switches, but more modern switches tend to enable the support by default.

Please remember that Jumbo Frames arriving at your port may not be faulty frame switching, but it could also be broadcast packets with a very large MTU on a broadcast domain that supports large MTUs and jumbo frames.

Posted by Bruce Cloutier (Member # 9615) on 11-05-2018, 06:30 AM:

That's a good point regarding a broadcasted Jumbo Frame.

For us this was just a glitch resulting from an oversight. Yeah, basically a bug. Frames are transferred from the Ethernet PHY chip to the processor in a linked list of small buffers. Well, I failed to create a large enough destination packet buffer to accommodate the large Jumbo Frames. So the feared "buffer overrun" occurs and the heap memory is pooched. We never caught it at INTEG as we have nothing pushing around Jumbo Frames. We have some media systems in here for development support but they are not configured to support content.

It is fixed in JANOS v1.7.1 and those who update will no longer have an issue should they install on a network pushing Jumbo Frames around. This brings us back to the auto-update question (prior topic) because my bet is that you folks will run into this having procrastinated the update. If it is not broke then don't fix it, well, not until it does break.

The concern is that the memory issue can scramble up the JNIOR enough for it to have to be reset and restored to factory content through an All-In-One update. We would support you through that but since we are into these sayings... An ounce of prevention is...

We are pushing to qualify v1.7.1 for release. It actually corrects a couple of 'gremlins' that we had been chasing for quite a while. It is the most stable version to date. I would just like to confirm the performance in the face of these Jumbo Frames. The latest site may not help us now that they feel they have gotten past the problem. Nevertheless we need to ship new JNIORs with it ASAP.