Thick vs Thin Client (Pros and Cons)

[Joe]

I hope I put this in the right topic for discussion, if not I apologize sincerely. Well I had to ask, at least for a better understanding and different points of view. I know with the new Saturn version coming up there will be many updates with growth, we are already seeing good software updates and fixes. I know there was a bit of discussion about latency with regards to Saturn and Thetis interfacing through the raspberry pi Ethernet-wise instead of straight to the fpga as the Orion board is now, of course this is the thick client setup; is this a benefit from a latency standpoint with regards to Thetis? I know the raspberry pi will allow thin client, will this entail a new style of Thetis for remote operation? It would seem that there would be another step or driver to interface into Thetis for thick client. Anyway, I am hoping to get a better understanding and a good independent view regarding the thick and thin clients with regards to sdr and why you would want one over the other?

73’s
Joe
WD5Y

[K1LSB]

Laurence has commented that there may be a slight latency penalty in thin-client configuration, see his response to a question asked at the 23:05 minute mark in the YouTube presentation in the link at the bottom of this post:

viewtopic.php?f=47&t=4570#p24081

Mark

[Joe]

Thanks, I’ll check it out. I kind of lean more toward the thick client, I like the idea that I can upgrade cpu, gpu; etc. when I want to. The Orion board does have a pcie interface but the fpga programming is the culprit. Just thoughts.

Thanks,
Joe
WD5Y

[w-u-2-o]

First off, ANY hardware can support thick or thin client operation. From a purely hardware standpoint merely add a dedicated server to whatever you've got, from a bare Hermes board to an ANAN-7000. It's merely a matter of convenience that some hardware has a computer built-in to potentially act as a server. It's a convenience, not a requirement. So from the perspective of the impending G2 units there is absolutely NOTHING special about them from a thick or thin client hardware perspective.

Obviously all of the hardware we can get, again from bare Hermes boards to G2's, or Hermes Lites, or Red Pitaya, whatever, is well supported by thick client software. So what does matter, what always matters, the ONLY thing that matters, is whether or not there will ever be any software to support thin client operation.

The G2's will be special from a software perspective only because they may potentially capture the imagination of software developers where the development of a thin client is concerned. However, such rumblings always seem to revolve around breaking piHPSDR up into client and server pieces. Thus anything that comes of this might never achieve the depth and breadth of functionality found in Thetis. So there is that potential trade-off. Nevertheless, it's very understandable because Thetis is reputed to be a nightmare bowl of spaghetti where the code is concerned and thus breaking piHPSDR up is probably a lot more feasible.

As for which is better, thick or thin, and why, there are many, many variables and trade-offs. From a latency standpoint, when used over a high speed LAN connection thin might have a little more latency but not a lot. Over a remote WAN connection (internet) thick clients are pretty much non-starters so the price is a little more latency from the thin client.

The real beauty of thin client architecture is the incredible flexibility that is afforded the client side developer. The server coughs up all the audio and display data, and can process all the raw audio received from the client. The client only needs to pass that information through, the server does all the heavy lifting. So all the client side designer needs to worry about is displays, controls and audio pass through, no processing or DSP.

[Trucker]

Scott, what you have stated is one of the reasons I originally bought into the Flex 6000 Series radios. All the heavy lifting takes place in the radio. I liked ( and still like) the fact I can create my own client and not worry about how DSP is done as that is something not exposed by the Flex API's.
But, it is also the downside to their system as well. If one wants to improve on features they have baked into the radio's firmware, someone like myself is out of luck as there is no way to make changes to the underlying code that processes things like Automatic Notch Filter, Noise Reduction and so on. ( my two main gripes with Flex radio)
Not that I am able to fix those issues, but, if they were exposed to outside developers, then there is the "potential" to improve upon them. I can build my own interface. But, I cannot go beyond that with the thin client system they have developed. There are positive points for them doing that, ( keeps support from going crazy with people having issues with 3rd party code) But, it makes getting improvements slow from the manufacturer.
That is one of the reasons I bought first, a Hermes Lite 2 so I could try NR2 first in OpenHPSDR and later, Thetis. And once I experienced that, I was hooked and found a great deal on an 8000DLE that I could not pass up. Now, I rarely use my 6600M as the audio , no matter the settings is no where as good as it is with Thetis. And the ANF in Thetis just works.
From my point of view, one has to weigh carefully what is important to them when deciding on which SDR radio they want and the implementation that is done. Flex radios are as close to plug and play as you can get with an SDR radio. But, because of the things I listed above, it is well worth it (for me) to take the time to learn the Anan ecosystem and how best to leverage it to get the most satisfaction out of it.
James
WD5GWY

[K1LSB]

James,

I had a Flex 6300 at one time, I never was happy with the fact that there was nothing I as an individual could to to improve the rather dismal TX latency (on the order of 100-120ms, if I recall).

I really REALLY appreciate the ability to tweak the buffers and sample rates in Thetis to reduce the TX latency to the absolute minimum that is sustainable by my hardware.

Mark

[w-u-2-o]

James,

There's no reason that everything we know and love about openHPSDR software (Thetis, etc.) can't be replicated in an open source, thin client architecture. All that is necessary (not that it is any kind of small thing!) are the developers who decide they want to do it.

73,

Scott

[Trucker]

James,

There's no reason that everything we know and love about openHPSDR software (Thetis, etc.) can't be replicated in an open source, thin client architecture. All that is necessary (not that it is any kind of small thing!) are the developers who decide they want to do it.

73,

Scott

Scott, I was under the impression ( perhaps mistakenly) that all of the DSP functions in Thetis and OpenHPSDR took place in the code running in the pc. Are you suggesting that the DSP code in Thetis could be moved to the radio itself? Maybe that is a possibility with the new Saturn and it having the Pi board in it. That would, or should, open up the use of pc's with less horse power than what I am using now. I have, in the past, run my Flex radios ( I have had several) with some very under powered tablets running SmartSDR using my home WiFi system. And as long as I didn't open the bandwidth too wide, it worked quite well.
The new Saturn radios appear to offer a lot of potential. Interesting times indeed in the Anan world.
James
WD5GWY

[Trucker]

James,

I had a Flex 6300 at one time, I never was happy with the fact that there was nothing I as an individual could to to improve the rather dismal TX latency (on the order of 100-120ms, if I recall).

I really REALLY appreciate the ability to tweak the buffers and sample rates in Thetis to reduce the TX latency to the absolute minimum that is sustainable by my hardware.

Mark

Mark, I think the latency problem you are referring to was pretty well taken care of in later versions of SmartSDR. I started using the 6000 Series radios with a 6300 and like you, found problems with latency. But, that was with a very early version of SmartSDR. I moved to a 6500 and finally a 6600M. While I have had issues with SmartSDR, in several things, latency now, isn't one of them.
Like you I like the ability to tweak and adjust things in Thetis. ( just have to remember to make a backup before getting too wild) PowerSDR for the older generation of Flex radios had and still has, many adjustments to tweak to get the most one can from the older Flex radios. I have a 5000A and run KE9NS'S version of PowerSDR on it and it works better than my 6600M and SmartSDR.
I love having choices.
James
WD5GWY

[w-u-2-o]

Scott, I was under the impression ( perhaps mistakenly) that all of the DSP functions in Thetis and OpenHPSDR took place in the code running in the pc.

Yes, currently that is the thick client architecture that exists for openHPSDR radios.

Are you suggesting that the DSP code in Thetis could be moved to the radio itself?

Not at all.

First, the box you buy from Apache is NOT a radio! This is a common fallacy, misunderstanding, etc. It is merely the "RF hardware unit". Functionally, most of the radio is contained within the software (Thetis). The box only contains the the parts of the radio on the antenna side of the first IF conversion. PC+software+RF hardware = radio.

Second, somehow you believe that to have a thin client/server architecture there must be some sort of processor "in the box". Again, not at all. For example, if you had a plain old ANAN-7000 without an internal PC, you could simply provision a PC with two Ethernet interfaces to act as the server. One Ethernet connection to the ANAN, the other points to the rest of the world that contains the thin clients. Small form factor PCs with dual NICs are a dime a dozen. Newegg shows 5 pages of them. You can get them really cheap on Aliexpress.

Maybe that is a possibility with the new Saturn and it having the Pi board in it.

Absolutely. It's also a possibility with any other openHPSDR hardware. You could do it with a Red Pitaya board. The server does not have to be "in the box". It can be on top of or next to the box. It can be a Windows PC, a Linux PC, a Pi (which is just a Linux PC), some other sort of general purpose processor (GPP), whatever.

Don't get hung up on the "box". The "box" is not important! Some boxes include a GPP inside, and that's convenient, but by no means necessary. Just put one on top!

[Trucker]

Second, somehow you believe that to have a thin client/server architecture there must be some sort of processor "in the box". Again, not at all. For example, if you had a plain old ANAN-7000 without an internal PC, you could simply provision a PC with two Ethernet interfaces to act as the server. One Ethernet connection to the ANAN, the other points to the rest of the world that contains the thin clients. Small form factor PCs with dual NICs are a dime a dozen. Newegg shows 5 pages of them. You can get them really cheap on Aliexpres

I think we are talking about the same thing in a way. I am using my past experience with Flex 6000 Series radios that do have a processor "in the box". Along with a rather large FPGA as well.
It also runs Linux and has server software running. I do realize that the pc/processor/server can exist outside of the radio hardware. And that once passing through the ADC's the FPGA can have code that provides data that can be sent to the pc and it's software that can provide the functions of a radio along with many other things. In the case of the Flex 6000 Series radios all of the processing takes place in the box. All except the presentation of the data. And that takes place either in a Windows pc, the windows based Maestro or the tablet in the front panel of the M model radios.
I have written a crude interface for the Flex radios I have had. Mostly as a learning experience and to keep my 72 year old brain functioning! But, going over the source code for Thetis makes me hesitant to make any changes to see if it I could add something to the mix. My luck I would brick the radio! Although I seriously doubt that as I would never attempt to touch the firmware.
James
WD5GWY

[w-u-2-o]

In the case of the Flex 6000 Series radios all of the processing takes place in the box. All except the presentation of the data. And that takes place either in a Windows pc, the windows based Maestro or the tablet in the front panel of the M model radios.

I suspect most of us are well aware that Flex uses a thin client/server architecture.

But, going over the source code for Thetis makes me hesitant to make any changes to see if it I could add something to the mix. My luck I would brick the radio! Although I seriously doubt that as I would never attempt to touch the firmware.

There is no need to touch the firmware.

Thetis code has been described as a nasty, tangled bowl of spaghetti. Anyone that has looked it it from the perspective of breaking it into client and server pieces has not seen it as something that would make sense. It seems it would be far easier to start completely from scratch.

The server side would be the far easier task. All that is needed is an appropriate layer over/wrapper around wdsp.dll and channelmaster.dll. It's the actual thin client UI design that would be the huge undertaking.

piHPSDR or linHPSDR would be much easier to break into server and thin client pieces.

[Trucker]

I think with the new G2 Saturn radios things will get quite interesting having both thick and thin clients as possible scenarios. I hope they will attract people interested in developing software for them. I am interested in one myself. But, at the same time, I am quite happy with my 8000DLE and Thetis.
James
WD5GWY

[Joe]

I really appreciate the reading and explanations here on thick and thin clients with sdr in mind. Obviously, I’m interested with regards to the 8000dle as I have one as well. I have a lot invested in my setup and very partial to the 8000 hardware , very good design. One thing that really sticks out from Scott’s posting is the setup with the static IP address to the 8000 and another adapter for lan or wan, if I understand correctly, the pc with two adapters - one to the 8000 and the other for outside comms would be the server as it handles the workload and a pc or tablet, etc. would be the client interfaced to the 2nd adapter by wan or lan. Of course if I remember correctly, Scott has mentioned many times about proper protocol, either udp or tcp, I believe? Where I got off-track was the pcie interface, I thought it was a must for this to work? Anyway, I understand that for all of this to come about is in the software. Thanks for the information.

73’s
Joe
WD5Y

[W4WMT]

Thetis code has been described as a nasty, tangled bowl of spaghetti.

I think that is a fair statement as long as you're talking about the Thetis project per se.
The WDSP and ChannelMaster projects, on the other hand, are well structured and well documented IMHO. The learning curve is steep, but enjoyable

73, Bryan

[w-u-2-o]

Thetis code has been described as a nasty, tangled bowl of spaghetti.

I think that is a fair statement as long as you're talking about the Thetis project per se.
The WDSP and ChannelMaster projects, on the other hand, are well structured and well documented IMHO. The learning curve is steep, but enjoyable

73, Bryan

Agreed!