 Okay guys, so I welcome you to my presentation about the Gunradio runtime and the subtitle is reinventing a very fast wheel. So Derek asked a question who doesn't know Gunradio. I think there were a couple of people who never used it. This will be pretty specific to Gunradio but it may also apply to other digital signal processing frameworks. So yeah, my name is Andre Rode. I will introduce myself right now. I will first talk about the actual state of the Gunradio runtime. So for the upcoming release of Gunradio 3.8 what are new features or are there any. Also I will talk about the Gunradio runtime in the retrospective. So what features did we or the previous developers add to the runtime and how that did that come out in the end and also then the new stuff. So future of the Gunradio runtime. So I talked with at least Marcus and Basti. So we had some like thoughts and what can we do to improve the whole situation to make things faster or yeah to improve on other optimization goals. So yeah, I am actually a double E student at the Kosovo Institute of Technology. My primary focus is on DSP and also communication engineering. I also currently run the Gunradio CI. So the little billboard thing that is building all the poor request stuff and also I'm hurting the web infrastructure so you can see nice things on the website. Yeah, I started using and contributing to Gunradio very recently. So 2016 is just about two years ago. So I'm pretty young in that respect. But I have a great interest and will hopefully contribute more and more to the radio infrastructure. Yeah, and I also have fun with SDR sometimes. So yeah. So what's the current state? So for the upcoming three point eight release, the runtime does not contain like a super new shiny feature we want to like push people to use. It contains a lot of dependency bumps. So the whole Gunradio project is now porting to Qt five and Python three and GTK three and like a lot of stuff is going on, but no like real shiny feature. And this raises the question, are we yet done? So is this whole runtime scheduling thing done and we can now focus on only doing DSP from now on? And unfortunately, this doesn't mean we can't can stop developing like the runtime and scheduler and stop improving basically. We have to improve it and Gunradio is a piece of software basically electrical engineers and communication engineers and DSP engineers are attracted to. So most of the time people work on what they like to do and that's like DSP stuff. Runtime is like it's more computer sciences or you have to do scheduling, you have to do buffer passing or like buffer handling and that's like a necessary evil, but you have to do it to get your samples around. So how did we come to the current state? So I have gone through the get history to like see when new features in the runtime can come in. So basically, Gunradio started out as a simple sample processing framework. So you put in data on the one side, you get data out on the other side without like other stuff messing with it. And then 2000 and it was single threaded. So it was okay at that time for the goal Eric and other people had to solve the to solve. So just in 2008 a multi threaded scheduler, the thread per block scheduler was added to the core. Then also message passing was merged. So message passing is something entirely different compared to the simple streaming. So you're not just like continuously streaming samples. You want to basically have like packetized data or like not back pressure your data. Then also a very nice feature like the tagging capability was merged. So you can now add metadata to your to your samples like which frequency amplitude amplitude but frequency other phase offsets you measured to correct for them. So it was a nice thing and also control port. So this was added to like introspective flow graph to have like also performance counters to see which blocks are performing well, which blocks are like holding up the full processing. Yeah, so it continued and like for the next release, the single threaded scheduler is thrown out. So it's already merged in next. So there will won't be a single threaded scheduler. So we are left with the threat per block scheduler now, which is doing a very good job. But may there might be some improvement still. So achievements, right, radius like the biggest open source DSP project used. We today we had like five, four, five projects using it and it's really good at what it's doing right now. So the back pressure driven architecture is great. You can do the sample processing without hassle. You only have to focus on your own blocks or the simple block API. If you want to write a filter, you just focus on what you have to do to filter the samples, not how to pass around data or to get your data from your radio and then somehow manage to catch up. So this is all done by radio. It's great. Also the strict block boundaries or blocks are not interfering with each other in terms of concurrency issues or locking or something. If you just do like sample processing, you don't have a problem. And this leads to a lot of new projects. And yeah, we today we saw some and there are still hundreds of other projects and companies using radio. So shortcomings. One thing you might notice when you run like a large flow graph with a lot of sample process, sample processing blocks is cash invalidation. So you have like say a hundred blocks doing stuff and then the threat per block scheduler, he will spawn a threat for each block and then calling the work functions of each block. The radio basically hands off the hard work to the OS. And the OS is then taking the threats and schedules them on cores and on hyper threads and is passing memory around and arranging everything, which is the OS is good at that. But the OS doesn't have like the information. How does your flow graph look like? Does it make sense to like keep like one one stream on one threat or one CPU to use the cash and not like invalidate your cash all the time and then to have to move around between different CPU blocks. Also we have a lack of tests for core features. So if people like submit bug reports and fixes for them for core features like tags or or message passing or something, it's not always clear if that only fixes that bug or if it also opens up a new path of bugs coming in. So that's a bad thing. Also the runtime API is sometimes a little hidden. So you can use just the normal features and you will be fine. You won't run into issues. But if you start like using extensive hidden features basically and then we remove them or we update them or something happens, your blocks break. And probably one of the resolutions later will be we want to add like first the API and then like implemented so we have a clear clear line where to go. This probably resulted in just the organic grown code. So you saw the timeline here. So it's like eight to nine years just for the these features. But the development started earlier. So like ten years of code is it's quite natural to have like some organic structures and missing, missing docs. So we also have a lot of lacking threat safety for direct method calls. So if you have like a flow graph in Python, you can actually call into blocks and trigger and call functions. But most of them are not really threat safe and we have no real means to protect that right now. And also we have a lot of varying code quality. So a lot of contributors over the years contributed different parts. So that's also quite natural. So for the varying code quality, I just like plotted the coverage statistics. So in the top we have the DSP things like GR filter and GR analog, which are very good test, tested quite well. So about 80% of the code lines run during tests. And then somewhere in between you have the runtime, which is sometimes tested by accident because it also gets run when you run anything in GR radio. But they're also actually tests in the runtime. But it's about 60% here. And then we have like a whole lot of blocks which is not runtime related but in the GR project with which are like not tested at all during our normal CI tests. So people in counterbugs and they report them. But then some other shortcomings people encounter and also solve in their own project is like the integration with other heterogeneous computing. Like if I don't only have like one CPU, I want to use GPU, I want to use an FPGA or other DSP coprocessors. There's no way of handling these custom DMA buffers in GR radio. So people come up with solutions for the GPU side. There are at least two or three projects who implemented OpenCL and even had buffer passing between blocks. Since the runtime doesn't know anything about it was like finger crossing, I just pass between one GPU and then keep my data on it so I can use the maximum performance. But also like cloud or say remote computing, I want to hand off, so I want to run a flow graph and I want to hand off certain parts to other instances of my like AVI's cluster or something. This is pretty hard to do in GR radio right now. So you have to, you can for example use 0MQ and then have one end implemented and then like run another flow graph on the other side and then you have to manually make sure to everything runs at the same time and is passing the data correctly. Also issue is like low latency applications. This is also, a lot of work was done by Basti, Basti and Blaissel to for the Wi-Fi stuff and basically he had, he also looked into other applications or frameworks and there was this Microsoft SORA, which already implemented this like 10 years ago. And there are also other issues with the current implementation. I skip a little bit to what we thought of for the future of the GR radio runtime. So first I want to compare to other similar projects. So I already mentioned Microsoft SORA. What we mean to design and what's the timeline for this, for our thoughts. So first question is do we need to improve the runtime itself at all? Can't we use just already implemented processing frameworks or other computation frameworks to do the job even in other signal processing frameworks maybe. So we have, I did, it's not a finished list but some projects who are pretty similar to what GR radio is doing. So SORA and there's this SRS LTE which are pretty application specific. So one is about Wi-Fi, the other one is about LTE obviously. And also some other stuff but no other project really matches the goal of GR radio to have like this generic processing and also of the existing ecosystem. So for GR radio there is already a big community and a lot of people doing own projects on top of the framework and basically we think we have to still continue improving the runtime itself and can't just use anything else as of right now. So what are the challenges that are not solved currently? So I did like a list of shortcomings so those are the things we think need to improve and to continue to provide GR radio with a path forward for like new other developments in this regard. And yeah what should an API look like? So that's where like all of you come in also to give us more hints or like tell us what you want to see, what's the current problems or struggling with the runtime. We see some projects, not all of them are open source of course, some are hidden in company walls. And what do we, yeah. And also how can we keep stuff around without reinventing the wheel, like Ms. Leith said. We don't have like questions, answers for all of these questions so we're still in the process of working stuff out. And first thing is design theory. So there's already a thing called like concurrent computing so that it's describing what GR radio is doing if we leave out all the digital signal processing and radio related stuff. Basically what we try to solve is concurrent computing and there's quite some ways to describe this from an academics point of view. So there's like the actor model is a word. For example, Petrinets or other process calculus they are called so we can come up with something that matches what GR radio is doing and try to apply that. And also the design goals in the end they vary because you can optimize for latency. That means in a practical sense you have to squeeze down your buffer sizes to two very small sizes or you want to optimize for throughput. For example, with a GPU you need a couple thousand samples to do like real processing. Okay so our design goals are obviously API before implementation so we are now in the process of designing and coming up with a good API for people to use in their own projects and also throughout the GR radio tree so there are also a lot of blocks there. We want to have configurable scheduling inside the runtime so that means basically you can optimize with very little effort or with not extensive knowledge of the runtime for latency but also can optimize for throughput not only with buffer sizes but with other scheduling paradigms. Also include the buffer management so there was already some work done back in 2013 which didn't come into like the core unfortunately. Also have some more flow graph introspection and with that also remote computation so those two are also pretty close together. If we get better introspection we can also have more schedule offload to other blocks and have this cross network communication basically going. And also we want to keep all the nice features we accumulated over time so we obviously don't want to lose multi-threading. We want to support the synchronous streaming which is the the breaded butter for GR radio and also yeah other features we have. So most importantly we don't want to reinvent the wheel we want to continue with what GR radio has accomplished and also we want to foster other first projects work to keep the maintenance law so we don't want to implement everything ourselves so using existing libraries for for example there's there's an C++ library for the actor model which we might or might not use to implement the scheduler or other projects implementing cross network communications and yeah a lot of things to to look at and yeah we are actually right now we are at the step writing down the API. Now then we want to agree on a technology implementation and yeah implement the API and and the last point is basically probably the hardest is gluing the existing thing together and giving people a path forward to have their out of three modules use their new features and everything we want to provide. So for those things we also need feedback so basically you can write me or Markus an email or Bastian and keep the discussion going or post I can also probably will post on the discuss and radio mailing list to keep this going yeah if you have any questions about what I told you today I'm happy to answer or try to answer I'm also available with the email address or with my nick on select or IRC and yeah we hope to keep everything in everyone here in the loop and the whole community to move forward. Okay. So one of the challenges we always faced with QA was hardware and non x86 processors, do you have plans to talk to my friend about that? Yeah right. So one thing to tackle those problems would be basically writing mock modules or something to to mock up the other side so you can it should be possible so other projects are also doing basically mock modules of hardware devices or other databases or something to to mock the hardware this would be a way to improve that or and the other thing was so there's also ways to run like QEMO or something on ARM I haven't looked into that yet but this could be a path forward to improve like the support for that and all the differences to x86 Can I just make a comment like I would I would say the hardware driver people should be like you know could also help with the mock like they should be there should be a way to test UHD without having used something like that would be that would be really useful. Yeah. Other questions? Alright as you go out take trash with you and take it as far from here as you can Yeah we have time. Yeah we have time. I'm just trying to make my life easier late. You can just I just move. Okay. I have a question. Yeah. So you said like can you like you have a question for me? Yeah. Okay can you just like go back to me? This is the middle of the session. You actually said time line but there is no time. Is it because you don't know how much time you will actually have? That's a problem because every one of us three who already thought of that we all have other things to do and don't get like paid full time to to work on the runtime and the scheduler so we have to like scramble time to to work on that in the free time. Also there there's like no no real time line to finish thinking about the things and start implementing so we need to nail that down pretty soon probably. Yeah but that doesn't like it doesn't match too well to the academic kind of research that we will have to do first. I have to comment on that.