On Sun, Jul 11, 2021 at 6:42 PM Chris Johns <chr...@rtems.org> wrote: > > On 10/7/21 1:28 pm, Vijay Kumar Banerjee wrote: > > On Fri, Jul 9, 2021 at 8:25 PM Chris Johns <chr...@rtems.org> wrote: > >> > >> On 2/7/21 4:40 am, Vijay Kumar Banerjee wrote: > >>> I'm planning to do a throughput analysis on the RTEMS network stacks > >>> and I'm looking for some suggestions on the tools/applications for > >>> that if anyone has done something like that before. > >> > >> This is a great project. > >> > >>> If such application has not been used with RTEMS, then I might be > >>> willing to port it to RTEMS or write one from scratch as a net-demo > >>> maybe. Any resource/advice for that is welcome and much appreciated. > >> > >> Throughput is one parameter when dealing with networking and it is > >> important in > >> some applications while latency is another parameter that can be critical. > >> Consider a voice switch with operators using Push To Talk (PTT) buttons to > >> activate a radio's transmitter, an enable packet needs to be delivered > >> within > >> 10msec max in all cases. > >> > > This is an interesting point. Thanks for mentioning latency. > > In RTEMS and in an RTOS in general I also consider the latency for separate > socket paths to separate readers and/or concurrent readers and writers as > something important. A lot of stacks maintain a single giant lock for the > stack > and that serialises the processing through the stack. Libbsd does not have > this > limitation with it's fine grain locking. A protocol such as PTP benefits from > deterministic handling of packets. > Interesting. I'm making notes, I'll look at latency from different protocols.
> >> I would look at removing the networking fabric from the analysis because > >> it is > >> subjective and can be effected by the NIC hardware, PHY configuration plus > >> any > >> externally connected equipment. > >> > > I'm approaching this by running different network stacks over the same > > hardware. I have a uC5282 that runs legacy networking and I have > > ported the driver to libbsd nexus device (dhcp doesn't work yet) and > > I'm able to see some difference in the round trip time over loopback > > with different stacks. > > Will your analysis look at architectures that support SMP and have various > cache > configurations? On a Zynq libbsd creates over 4000 locks and so there may be a > performance hit on smaller single core systems compared with multi-core > architectures that can run concurrent threads in the stack at the same time. > Yes, we plan to look at multicore architecture as well. Getting the target to support all three stacks would be the real challenge. > I think the 5282 may bias the results in a particular way and other archs will > bias in a different way. I do not see this as wrong or a problem, rather it is > something that needs to be accounted for so readers of the analysis do not get > the wrong impression. > We intend to analyze boards over multiple arch. > >> In terms of network stack performance for RTEMS you need to consider the > >> protocol, buffering used, size of the buffer pool, transmit and receive > >> paths, > >> they will have different characteristics, and target's memory effects such > >> as > >> caches. On top of this is filtering, ie packet filtering, and the types of > >> access. > >> > > Thanks for these interesting attributes to consider. I have done > > preliminary analysis over ICMP with packets of same size over > > different network stacks on the same board. > > > >> With libbsd there are a number of sysctl settings that effect the > >> performance. > >> How will you manage these? > >> > > I'm not sure. I didn't know about the possible performance difference > > based on sysctl settings. This would be relevant for any user and I > > would like to explore it. Could you please point to some resources or > > examples? > > There are a lot of posts on the net on this topic (search: "freebsd tune > network > sysctl") and the values can be technical but they do make a difference for > different data workflows. There is no single set of values what work > universally > and for libbsd this is OK because I encourage users to explore the settings > and > see what works for them. There can be a memory used vs performance trade off. > We > support the sysctl API and there is a sysctl command for the shell. > I found some nice articles, thanks. I'll explore it further. Thank you for the great points, it helped me get a better idea of what I should be looking at. Best regards, Vijay > Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel