On 2021-09-08 6:26 a.m., zhou wrote:
Hi Marcus,
The LLL errors happened in host when it talks to N321.
N321 is connected to the host through two 10GigE SFP cables directly;
these is no other device in the middle. N321 has one extra RJ45 1GigE
cable for management. This cable is connected to a switch; host is
also connected to this switch.
If N321 receives unsupported protocols on the management port (RJ45)
and then generated Rx drop, it is reasonable. But on SFP ports, I
don't know what protocol they receive apart from broadcast from host
when running uhd_find_device and the configuration commands.
You could use "WireShark" on your host computer to see what is being
sent. Ideally, yes, it would only involve UHD
protocols, and perhaps ARP packets, etc.
Does UHD use IRQ or polling method to retrieve data from NIC?
IRQ vs polling configuration is the domain of your OS Kernel and its
hardware drivers. UHD is not involved at all other
than "just another application". You can use "ethtool" to query and
set these parameters--if your hardware supports them
there are a *large* number of parameters that can be controlled by
ethtool, so I suggest looking at online documentation
for it.
For the ULLL error in host, I doubt on two things:
- tx buffer size: because of the high sampling rate, the tx buffer
needs to be bigger to tolerate fluctuation and interruption during
processing. What command can be used to check tx buffer size?
The "sysctl" commands that you spoke of in earlier e-mails set the
amount of memory used by the kernel drivers for
network buffering.
sysctl net.core.rmem_max
sysctl net.core.wmem_max
Will both print out the current settings
- cpu core allocation, NIC binding. There are 8 cores in host; I use
separate cores for Tx and Rx. In my program, there are four threads
which use 3 cores, but in htop, I can see 8 threads in my process. Are
the extra threads created by UHD?
There are some threading notes here:
https://files.ettus.com/manual/page_general.html#general_threading
I don't believe that UHD creates any threads of its own. It is
conventional for the *application* to create an RX thread, a TX thread,
and a control thread.
For high-bandwidth networking (high sample rates) some customers have
had success using DPDK on their system, if
the 10G network cards they use support DPDK:
https://files.ettus.com/manual/page_dpdk.html
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
