Thank you for the lengthy responses Saturation of the link is indeed possible with a UM application, if you use large packets. For the application(s) in use / mind , the traffic pattern is many, tiny packets.
Currently we use an abandoned kernel driver SCTP by Bruce Cran for the SCTP protocol. Which has served well. However when we re write SCTP in C# we arrive at performance, similar, in terms of packets per second to the SCTP kernel driver.
I take your point on jitter and latency on Windows with time scheduler slices. Well known to us from earlier historic endeavours.
However having googled various presentations etc from Microsoft for DPDK or PDCI they seemed to indicate a reduction in latency and jitter, whilst increasing pps and via a UM apps using kernel bypass. Which seemed to be exactly what we were looking for. IE UM apps and custom UM protocol(s) with improved pps, whilst avoiding? driver work. What we struggled to do was to find examples, or an example, in order to build and test, to see if it was a fit for our plans, or even if our plans are feasible on current platform.
We are looking to build a new base with custom telecom protocols onto which we can then add service layers, such as GSM call control, SS7 firewall credit balance check, fraud prevention etc. The services require differing performance, some are 100pps and millisecond latency, some would be 10kpps, and sub millisecond latency and million of pps( ie SS7 firewall etc, high volume call control). The more performance we can build into the core, the wider range of services we can build on top of it.
We are at the stage, and have the time and resource, to decide which routes are available and which of those routes would be the right one for us. c#UM and some sort of magical?, low latency, jitter and high throughput packet interface are, of course the preferred route. Driver work and downright horrible low level APIs are also possible, and so is a shift to Linux.
Our in house experience and tooling is windows and C# for last 10 years or so, but we started with assembly, Pascal,C, C++ a long, long time ago.
The struggle we have at the moment is evaluating one possible route, ie the musing from Microsoft regarding DPDK port or PDCI for lack of documentation and examples. Weâd like to do that before taking the larger, more involved steps, of lower levels languages, driver development or shift to Linux. Each of which, for us, having associated cost to gain experience etc.
We wanted to evaluate, the perceived easiest route for us, given infrastructure and knowledge, and wondered if anyone had been ahead of us and could point the route to something we could test.
We tried stack exchange but when we get into these sorts of realms the pool of those who require such tends to shrink somewhat. Fast packet processing on Windows seems to be rather new, relatively, speaking.
Best Regards,
Simon