Bob Cowdery wrote: > This thread has got broken into so many fragments I can't find a > suitable message to reply to so I'm going to try and recompose my > thoughts here. > > I don't feel my fundamental issues got answered so I have drawn my own > conclusions. I'm pleased it provoked some discussion. My intention is > simply to understand the motivation and where it's come from. > > <snip> > >> Lightweight threads aka processes. I don't think we are running >> > massive > >> numbers of threads and threads are not particularly difficult in most >> modern languages. >> > > Frank Brickle wrote: > Not so. We are talking about hundreds and potentially thousands of > threads. Remember that we're talking about an environment that can > support 2^N simultaneous radios on one processor, where is easily 6 or > 7. This is not speculation. It's happening right now with DttSP, > although not on an SDR-1000. > </snip> > > I think there is a very strong clue here. The architecture is aimed at > supporting a radio factory. The major motivation to my mind therefore > comes from the idea of a virtual radio or radio kernel architecture to > support 10's or 100's of real and virtual radios. I have to question how > relevant this is to most people. Most of us have one radio and are > unlikely to have more. > So this argument would seem to imply we should do the wrong thing for 2 radios just because most people have 1? As soon as I got to two, I saw I need a better mousetrap. The first time I started down the path of building ONE virtual radio from several distributed pieces, I needed a better mousetrap. The gist of the argument appears to be "I do not need XYZ to do the subset of the problem I am focusing at this time so I will not attempt to find a globally best solution by applying a greedy algorithm to decision making". However, let's take your relevance remark as primarily rhetorical (given what is written below) and say this. Erlang will cost us nothing in terms of performance on the one radio set up. The computational complexity of what is to be done here in the switching station/application manager is not even worth mentioning compared to painting the power spectrum on the GUI and is much less than the DSP which is also less than painting the power spectrum on the GUI. > Erlang is a good language, as a language; probably excellent as a > switching station and a composer of real hardware into virtual radios. > That part of the system is obviously going to be written in Erlang. > Correct. > However, is Erland a good language for DSP. I would say it's probably > too slow having tried to do DSP in Python. I am not talking from > definite experience here but my guess is DSP will stay in C although it > could have some orchestration from Erlang in the same way that GNU Radio > is orchestrated by Python. > Correct. It will be EXTREMELY hard to beat the basic performance of DttSP in a high level language. There are some hotspots that I know require work (such as the agc code and all of the nonlinear functions in it) but until somebody decides the GUI code needs serious replacement, worrying about the agc code is nibbling at the edges and a waste of time. > Is Erlang a good language for a UI. From what I can glean, probably not. > It has no native toolkit and its bindings to C toolkits seem to be in > disrepair. My guess therefore is that people won't be writing UI's in > Erlang, they will continue to be in a variety of other languages. A > client library will have to be provided for UI's to connect to the > Erlang system. The library will need bindings to various languages. Some > such libraries already exist and might provide starting points. > I do not want to touch a GUI until it is written. Since I won't be writing it but Eric, John, Edson, et. al. will be, they can write it in machine language for all I care. > Is it a good language for HW control. It's probably as good as any > other. The task is not processor intensive and has been done in at least > C, C#, Python and Squeak. My guess however is that it will stay in C as > the main implementation. > > I have no intention at this time on replacing the C/C++ code for hardware control. I need to FINISH the hardware control for the Linux world so they can transmit!
> The net result is that there is at worst one native Erlang node which is > the virtual radio (that function itself could of course be distributed, > but essentially one node). Only that node can take full advantage of > Erlang the language, the rest are just using it as a transport. > Correct. > I think the world according to most people is GUI and DSP although I > still maintain the Console is really a number of functions, only one of > which is the GUI. These other functions e.g application logic, model, > CAT are potential candidates for being native Erlang nodes. That does > require that the vast majority of what's in the PowerSDR Console is > rewritten in Erlang. I've not heard anybody say that is part of the > plan. > Cat interpretation by the virtual radio will be done in erlang. The actual hardware interfaces, which I believe are being done mostly by Bob Tracy now, are in C#. I see no advantage to changing this at this time. He is willing to do the work, it costs me and others nothing at this point. Should we, as a group, decide to replace the C# with an Erlang module, it will work for me. > Conclusions > ----------- > > --- snip --- All seems reasonable. > Maybe now I will actually get on and do something. I doubt many people > are concerned whether I endorse Erlang or not but for the record I do at > present and if anything I produce is useful I will of course share it. > > P.S. I have no experience in this environment, zilch, nothing. I hope > the reality is as good as the theory! > > 73 > Bob > G3UKB > > I have two contest stations in mind when I think of the system (outside of my work place). One is that operated by Eric Scace, K3NA for all contests and the other is the one operated by W2GD for 160 meter contests. I am certain that if the system is optimized for that level of demand (as well as the demands of my work), we will all benefit. I did the 100 receivers for work that Frank was mentioning. We all definitely benefited from this kind of large scale thinking. We got float arithmetic, SIMD optimization of hot spots, and much more directly from this work. It was a major advance for all of us, not just the customer who needed 100 receivers to run on one old 2 GHz Pentium III Xeon Dell server. Bob N4HY -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman "You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat." - Einstein _______________________________________________ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Homepage: http://www.flex-radio.com
