New Contributor
Frequent ContributorThe cause is the clock difference as described by HRZ. Quoting his/her words:
Properly-made switches typically operate at a slightly higher clock than what is required to meet 10 Gbps to avoid packet drops caused by slight mismatch between the clock rate of the switch and connected devices. However, in the case of this FPGA board, the Ethernet IP likely operates at exactly the required clock or maybe even slightly less (e.g. 399.9999 MHz instead of 400.0 MHz), resulting in a few packets being dropped when operating at full speed with minimum inter-frame gap.
New ContributorHi JW. Working with SYeon, I will have to bring this issue (of not meeting the due wire speed with minimum Ethernet IFGs) to the attention of our project community including all 3 Korean mobile operators and major network vendors.
Note that this is one of biggest national R&D projects where a total of 9 Intel N3000 PACs are used to feature 'URLLC (Ultra Resilient and Low Latency Communication)' for 5G MEC (Mobile Edge Computing) use cases. Hence 'non-wire rate' PACs would hardly be made acceptable, considering the stringency of the project.
Can't we expect Intel to deliver the advertised (100% wire speed) feature e.g. by releasing a quick update??
Frequent Contributor@Moon_Lee Performance aside, are you really planning to use Intel's propitiatory and closed-source network IPs which you have no control over, in a national project? A project like this should have very stringent security requirements including absolute avoidance of any piece of proprietary code/IP and I would assume all code for such project would have to be developed in-house to ensure its security and functionality. At the end of the day, if you want to push Intel to do what you want, you would be better off going through your local FAE (i.e. whoever you purchased the boards from); you must have access to a high-level FAE if you are working on a national project.
New Contributor@HRZ Open source adoption has been made common place in national R&Ds, at least here in Korea. I would say, hardening security up to the required level can be agnostic to whether codes are open or closed. Moreover, building everything from a green grass is neither possible nor desirable for modern telco applications these days. Even most of Gov. R&D stakeholders here are well aware of the paradigmatic shift towards Open Networking & Computing. (Well, the only exception would still be the Defense sector though.) No problem at all in our leveraging Intel N3000 PAC platform, as long as Intel stay being a trusted supplier.
So, I am still wondering how Intel would want to react to this non-carrier-grade stigma..?
