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. 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. 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. 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. 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. 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. 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. Conclusions ----------- You might think that I will come out strongly against Erlang. In fact I am now fairly convinced it is an appropriate route, but I had to come to that conclusion myself rather than accept the arguments I was given, none of which I found very convincing. Maybe I misheard, didn't want to hear or just got lost in the mathematical purity and jargon of the solution. These are my reasons, please feel free to add/subtract according to taste. 1. Erlang is a very mature language and should be low risk in terms of robustness. Yes, it will break if you hit it hard enough, everything has its breaking point. 2. It makes concurrency and communication trivial to implement and it does it with style. I have to caveat this by saying that's only really true if you stay in the language so part of the plan must be to do as much as possible in the language and build robust easy to use bridges to those parts that cannot be in Erlang. 3. Part of my plan long term would be to build everything possible from the GUI layer as Erlang native nodes and just leave the thinest possible UI with a multi-language binding to a client library into Erlang. 4. The Virtual Radio concept is to me much more about abstracting the radio (DSP, HW and potentially other control elements of a radio) to a common interface irrespective of platform or distribution than it is to providing a switching centre for multiple radios. It brings a common interface to all platforms which is something I have long wanted. The language choice probably makes it no simpler or harder for one radio but if talking 100's then it's a good choice. The VR for one radio is not complex so I will probably roll my own. 5. I leave performance as an outstanding issue. Nodes are separate execution environments, operating system processes if you like. Communication between nodes is sockets even when those nodes are on the same machine. The more nodes in the data path the longer the potential latency which *could* rise to unacceptable levels. In systems that can run co-located (all on the same machine) or distributed there is always that trade-off between running in distributed mode in a co-located environment or short-circuiting the calls in some way at the expense of writing abstraction layers. 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 _______________________________________________ FlexRadio mailing list [email protected] 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
