Call Search
     

New to Ham Radio?
My Profile

Community
Articles
Forums
News
Reviews
Friends Remembered
Strays
Survey Question

Operating
Contesting
DX Cluster Spots
Propagation

Resources
Calendar
Classifieds
Ham Exams
Ham Links
List Archives
News Articles
Product Reviews
QSL Managers

Site Info
eHam Help (FAQ)
Support the site
The eHam Team
Advertising Info
Vision Statement
About eHam.net

donate to eham
   Home   Help Search  
Pages: [1] 2 Next   Go Down
  Print  
Author Topic: Flex engineering?  (Read 6942 times)
K1ZH
Member

Posts: 10




Ignore
« on: September 30, 2017, 11:06:13 PM »

I was perusing the Flex message board and came across this https://community.flexradio.com/flexradio/topics/2-x-upgrade-has-been-a-nightmare-several-problems-but-this-is-a-show-stopper. The OP is a Flex-user who is having a heck-of-a-time trying to get SmartLink to work. What caught my eye was the response by Steve Hicks toward the end of the thread. He is actually trying to blame the OP's issue on an open-source router that "rejects fragmented UDP packets". To me, that seems like crazy-talk.

So, what we learn in the thread is that SmartLink establishes a UDP connection between SmartSDR and the radio to carry a stream of data. I expected that SmartLink would have included a decent streaming protocol. But I see that was not the case - instead SmartLink just blindly shoves large UDP datagrams onto the internet while the Flex-engineers cross their fingers. You might get away with transmitting large UDP datagrams over a LAN, but there's no way you should implement such a primitive protocol across the internet.

Here is the problem. The source IP-layer is responsible for fragmenting the UDP datagrams into MTU-sized packets. The destination IP-layer is responsible for reassembly of the fragments into UDP datagrams. Since the IP-layers have no concept of retransmission, if just one of the datagram-fragments is dropped, the destination IP-layer will eventually time-out waiting for the dropped packet, after which, it will be forced to drop the entire datagram.

Of course, this is why TCP was invented. It handles retransmission, reordering, pacing, etc. However, TCP can cause problems for streams that carry time-critical data; by the time a dropped packet is retransmitted, it's too late to be of any use. Thus, it is normal to use UDP for time-critical streams. However, it is also normal to build something on top of UDP to help minimize the effect of lost packets. Let's take RTP as an example. Many toll-quality voice services use RTP to carry the time-critical voice data over the internet. One of RTP's responsibilities is to break the voice data into small chunks and send the data as an independent UDP packet. The idea here is that if a single packet is dropped, the loss of data is 'tolerable' to the listener. Sometimes the voice codecs are designed to help 'smooth-over' small gaps in the data stream, as well. There is also an RFC describing a method to carry FEC data over RTP which can be used to recover lost packets.
« Last Edit: September 30, 2017, 11:23:46 PM by K1ZH » Logged
KA4DPO
Member

Posts: 780




Ignore
« Reply #1 on: October 01, 2017, 07:43:06 AM »

I wonder how long it will be before the OP's post gets closed?

https://community.flexradio.com/flexradio/topics/community-posts-getting-closed
Logged
W3RSW
Member

Posts: 536




Ignore
« Reply #2 on: October 01, 2017, 01:41:33 PM »

 'ZH, Pretty decent analysis of the problem. Beyond my experience but appears accurate. I wouldn't call it a show stopper quite yet given all the other abilities of Flexs' user interface, interoperability and ability to meet the competition with likable offerings.

I suspect Flex will address the issue if sufficient number of users experience same problems.
Regardless, the majority of Flexs' software is a tour de force and further along than say the "big three." It takes a heck of a lot of interfacing to get where Flex has gone so far in automatic plug-n-play.
Anyway as many have stated in regards to Flex, "patience" required from a relatively small outfit.

Not a Flex owner but admire Flexs' models, from sound card era to complete internally operated rigs, even knobs.   Grin  I currently have Anan products with the myriad of issues there too. All fun.

-Rick, W3RSW
« Last Edit: October 01, 2017, 01:43:38 PM by W3RSW » Logged

Rick, W3RSW
K3TIM
Member

Posts: 123




Ignore
« Reply #3 on: October 04, 2017, 06:49:17 AM »

UDP - I've used a Maestro as well as a W10 laptop remotely with the FRS Smartlink and the performance is very good. This is using WiFi as well as a smartphone as a hotspot. The network meter will show a fractional percentage loss but I haven't heard it reflected in the audio or in the panafall.

An ISP at a particular home I was visiting was not playing well with Smartlink. A month later, while visiting, I was surprised when the setup worked. The ISP apparently did some changes of their network and viola.

Since the SDR magic is done in the radio 'server', the datalink rates are low. I was observing 72kbs which depends on the panafall rates etc.

Logged

_..--
k3Tim - MSEE - PE - PPSEL / IFR USPTO:8063955:4462102:9,332,179:9,363,445
K1ZH
Member

Posts: 10




Ignore
« Reply #4 on: October 04, 2017, 11:28:44 AM »

The key to understanding the problem in this case is that the OP said in his first post that everything works fine if he uses a VPN. He is only having issues when he tries to use SmartLink.

VPNs employ TCP to receive the benefit of guaranteed data delivery. On the other hand, SmartLink employs UDP which tells you that the OP's problem stems from the issue of dropped packets. Thus, what SmartLink lacks is a more appropriate transmission protocol and/or a more robust application layer.

I feel like this whole thread is just stating the obvious, but I felt the need to correct Hicks' "pass the buck" statement which blames a fictional router for their own engineering snafu. The idea that an in-service router has a completely broken IP-layer, and it is only a problem for SmartLink is simply laughable.
« Last Edit: October 04, 2017, 11:50:20 AM by K1ZH » Logged
N6YFM
Member

Posts: 502




Ignore
« Reply #5 on: October 04, 2017, 01:27:43 PM »

The key to understanding the problem in this case is that the OP said in his first post that everything works fine if he uses a VPN. He is only having issues when he tries to use SmartLink.

VPNs employ TCP to receive the benefit of guaranteed data delivery. On the other hand, SmartLink employs UDP which tells you that the OP's problem stems from the issue of dropped packets. Thus, what SmartLink lacks is a more appropriate transmission protocol and/or a more robust application layer.

I feel like this whole thread is just stating the obvious, but I felt the need to correct Hicks' "pass the buck" statement which blames a fictional router for their own engineering snafu. The idea that an in-service router has a completely broken IP-layer, and it is only a problem for SmartLink is simply laughable.

Working as a Network Admin and OS Software Engineer for the last 25 years for Sun Micro and now Oracle,
we knew this all the way back in 1994;   ONLY use udp for local area network, and never for Wide Area Nets.
In 1994 we tried using udp for Network File System for a short time, only to suffer massive data corruption.
Using TCP ever since, all fine.    If Flex engineering used udp for Smartlink, then they hired the wrong
software engineer(s) with little real world experience.

[Don't talk to me about music and video streaming; lossy is OK there, since your ear and your eye don't
give a rip if you miss a packet now and then (using udp protocol).    But, if transferring files or control
commands, you really DON'T want to miss a critical piece, do you? :-)   Then we use TCP to guarantee
delivery of the packet.]

But; as someone who has worked in the industry for many decades, let me fairly state, THIS IS NOT on Flex.
Engineers come from the same bell-curve as everyone else.  You hire people and hope for the best, but sometimes
Titanic sinks, Space shuttles blow up, bridges collapse, and trains go BOOM.

Every company I ever worked at had products with lots of flaws, since WE (humans) are not perfect.
You should only be able to see inside the database of how many bugs YOUR cell phone shipped with :-)
Or how many bugs/flaws YOUR car shipped with.

But, that said, you are right that Flex's public forum "face" should smart-up a little, and simply say thanks
for the problem report, rather than pointing a finger.

Flex is listening.  They come out with approx. quarterly updates.   It is easy for them to change/fix this
if they choose.   No worries.  It would not keep me from buying a Flex, since, as the other person admitted,
a work-around for now is to simply use VPN while waiting for proper fix.

Be honest;  the bulk of the main product works great, else NO ONE would buy them.
There are a few rough edges, like with all products.  [Flex is still WORLDs better than MFJ,
and has more working features than comparable $$$ Icom products for the same price.]
There is really no right or wrong answer here;  It's about which model car YOU happen to like.
They ALL get you on the air.

Cheers,

Neal
« Last Edit: October 04, 2017, 01:40:47 PM by N6YFM » Logged
W6RZ
Member

Posts: 161




Ignore
« Reply #6 on: October 04, 2017, 02:23:40 PM »

Most likely they chose UDP for latency considerations.
Logged
W9IQ
Member

Posts: 1706




Ignore
« Reply #7 on: October 04, 2017, 02:44:17 PM »

On the other hand, what is the justification for not using a VPN for remote access (setting aside snide answers such as ignorance, laziness, and apathy)?

- Glenn W9IQ
« Last Edit: October 04, 2017, 02:52:59 PM by W9IQ » Logged

- Glenn W9IQ

I never make a mistake. I thought I did once but I was wrong.
K0UA
Member

Posts: 1380




Ignore
« Reply #8 on: October 04, 2017, 03:23:43 PM »

On the other hand, what is the justification for not using a VPN for remote access (setting aside snide answers such as ignorance, laziness, and apathy)?

- Glenn W9IQ

You make a very good point.
Logged
K6JH
Member

Posts: 402




Ignore
« Reply #9 on: October 04, 2017, 04:13:27 PM »

Why does a VPN help? Do ISP's preferentially treat VPN'd packets vs those that are simple, public UDP?

I understand if VPN works, use it. I'm just not a network expert, and want to understand the why better.
Logged

73
Jim K6JH
K1ZH
Member

Posts: 10




Ignore
« Reply #10 on: October 04, 2017, 05:26:59 PM »

Why does a VPN help?

In this case, because the VPN was constructed on top of TCP, and TCP is designed to retransmit sender-data until it is acknowledged by the receiver.

Do ISP's preferentially treat VPN'd packets vs those that are simple, public UDP?

Probably not, unless the owner of the VPN pays for a preferred service.
« Last Edit: October 04, 2017, 05:30:35 PM by K1ZH » Logged
NI8R
Member

Posts: 267




Ignore
« Reply #11 on: October 05, 2017, 01:29:29 AM »

I was perusing the Flex message board and came across this https://community.flexradio.com/flexradio/topics/2-x-upgrade-has-been-a-nightmare-several-problems-but-this-is-a-show-stopper. The OP is a Flex-user who is having a heck-of-a-time trying to get SmartLink to work. What caught my eye was the response by Steve Hicks toward the end of the thread. He is actually trying to blame the OP's issue on an open-source router that "rejects fragmented UDP packets". To me, that seems like crazy-talk.

So, what we learn in the thread is that SmartLink establishes a UDP connection between SmartSDR and the radio to carry a stream of data. I expected that SmartLink would have included a decent streaming protocol. But I see that was not the case - instead SmartLink just blindly shoves large UDP datagrams onto the internet while the Flex-engineers cross their fingers. You might get away with transmitting large UDP datagrams over a LAN, but there's no way you should implement such a primitive protocol across the internet.

Here is the problem. The source IP-layer is responsible for fragmenting the UDP datagrams into MTU-sized packets. The destination IP-layer is responsible for reassembly of the fragments into UDP datagrams. Since the IP-layers have no concept of retransmission, if just one of the datagram-fragments is dropped, the destination IP-layer will eventually time-out waiting for the dropped packet, after which, it will be forced to drop the entire datagram.

Of course, this is why TCP was invented. It handles retransmission, reordering, pacing, etc. However, TCP can cause problems for streams that carry time-critical data; by the time a dropped packet is retransmitted, it's too late to be of any use. Thus, it is normal to use UDP for time-critical streams. However, it is also normal to build something on top of UDP to help minimize the effect of lost packets. Let's take RTP as an example. Many toll-quality voice services use RTP to carry the time-critical voice data over the internet. One of RTP's responsibilities is to break the voice data into small chunks and send the data as an independent UDP packet. The idea here is that if a single packet is dropped, the loss of data is 'tolerable' to the listener. Sometimes the voice codecs are designed to help 'smooth-over' small gaps in the data stream, as well. There is also an RFC describing a method to carry FEC data over RTP which can be used to recover lost packets.

UDP - I've used a Maestro as well as a W10 laptop remotely with the FRS Smartlink and the performance is very good. This is using WiFi as well as a smartphone as a hotspot. The network meter will show a fractional percentage loss but I haven't heard it reflected in the audio or in the panafall.

An ISP at a particular home I was visiting was not playing well with Smartlink. A month later, while visiting, I was surprised when the setup worked. The ISP apparently did some changes of their network and viola.

Since the SDR magic is done in the radio 'server', the datalink rates are low. I was observing 72kbs which depends on the panafall rates etc.




statement from customer :I have a problem

Answer from Flex: your the only one, works great for me.


Tim, I know you are an active part of the flex experience and typically make positive post after someone says something inflammatory about flex. The response should sound something like " we could not reduplicate his exact problem using the same equipment" or " we recommend using these brands of equipment for optimal performance, Avoid brand x" . Anything would be better than " it improved over time viola". The worst internet should be able to stream 72kbs.
Most voip phone carriers have a web check to see how your internet is performing, flex should make a simple app to tell if your system is compatible.
While i agree, not all hams are I.T friendly. Flex is selling to the masses that this is plug and play radio. Folks who buy the Anan are told its a open source project with only user support. While i do not consider either to be complicated, the flex is much easier to use out of the box.

Greg

P.S   Sold the flex 6500 3 weeks ago, never tried anything remote. The dsp is so under developed on this rig, who could stand to turn the noisy thing on. sorry guys , the koolaid was just too sweet. That dust collector sat here for 2 years, used it once a month to keep it from going bad. Like Stan, i will always have my flex experience.
Logged
KA4DPO
Member

Posts: 780




Ignore
« Reply #12 on: October 05, 2017, 08:02:56 AM »

I see a lot of excuses being made here such as, the bulk of the product works great, and lot's of blame being tossed at the users server and VPN setup.  Considering the price of the equipment it should work regardless of the server or ISP being used.  It is for that reason I prefer a stand alone SDR, on in which every available function and feature works without having to reconfigure my network.  I understand that computer junkies like to fool with computer networking and that's OK if you want to spend that much money for an unfinished product but I radios that don't try to be anything else.
Logged
N6YFM
Member

Posts: 502




Ignore
« Reply #13 on: October 05, 2017, 02:30:10 PM »

I see a lot of excuses being made here such as, the bulk of the product works great, and lot's of blame being tossed at the users server and VPN setup.  Considering the price of the equipment it should work regardless of the server or ISP being used.  It is for that reason I prefer a stand alone SDR, on in which every available function and feature works without having to reconfigure my network.  I understand that computer junkies like to fool with computer networking and that's OK if you want to spend that much money for an unfinished product but I radios that don't try to be anything else.

Fair indeed.
And here, you see firsthand the challenges that small companies face with less than 50 employees.
Flex appears to have built some really good hardware, but as someone who works in commercial computer
manufacturing, I can tell you that software is MUCH more expensive and complex to get right than the hardware.
A small company like Flex or Anan just does not have the cash flow to toss 20 full time engineers at ongoing
software design and bug fixing.
As a senior manager of software engineers at a systems manufacturer since 1992, I can tell you how expensive this
is;   We use a benchmark round number of $200,000.00 PER ENGINEER.  This, in many (but not all) geographic locations,
covers the following per engineer:  Salary, office systems, phone, furniture, portion of office rent, utils, payroll taxes, etc.

So 10 engineers costs crudely 2 million and 20 engineers costs crudely 4 million per year.
Now,  you can't stay in business unless you NET *MORE* than the 4 million.
So how many flex radios do you need to sell each year, at what % mark-up, to make a pile
that exceeds $4,000,000.00 dollars?   Put a different way, if you sell a $3,000 radio and make
$500 per radio, you need to sell MORE than 8,000 radios per year just to afford the "SOFTWARE"
engineers I am talking about. And that does not even consider the additional costs
of staff such as marketing, sales, tech support, hw design and assembly, HR, payroll, Finance,
supervisors, facilities, etc.    Flex is not selling 8,000 per year.

Bottom line;   Flex can't afford that many software engineers, so the product fit-n-finish suffers.
The time it takes to get bug fixes and new features to customers suffers.
Icom and Kenwood, and Yaesu can divide those additional costs across many
different product lines (you can use central/shared marketing, legal, support, facilities, sales, etc),
but a small 5 to 25 person company can't.

What is the result?   Look behind the curtain, and you likely have between 1 and 5 sub-contract engineers doing
part time new software development, and part-time customer support duties.
For example, Ham Radio Deluxe has only 1 or 2 engineers, but they are still doing a reasonable amount
of changes and fixes even with that tiny crew.  But major new features?  That gets really tough.
For Flex, you likely have distributed independent contractors out on the net that work from home so
that Flex can avoid all those "Big Boy" costs of running an on-site large company.

It means there is VERY little change that can happen each year, maybe a dozen or less tested bug
fixes each quarterly release/update.

Both Flex and Anon have what looks like "Apple Quality" hardware.   But lacking the deep $$$ pockets
and sheer size, these smaller companies can't afford to have hundreds of software engineers like Apple or Oracle.
So, the overall product has less fit and finish  (I think you called it "unfinished", which is fair).  

In any product, the total user experience is based on how clean and seamless the software and hardware fits together.  
To do that, there is no shortcut;   hundreds (sometimes MANY hundreds) of software engineers.

So both Anan and Flex have plenty of feature bugs and user frustrations, that is almost never the hardware,
and almost ALWAYS the software, which you wait endlessly for, since they lack the manpower.
The user perception of the product always gets down to the quality, and completeness, of the software
that makes the hardware do something.

I personally am having fun with my existing hardware, and am not loosing any sleep while I wait for my
Icom 7610 reservation next year.

Neal
« Last Edit: October 05, 2017, 02:45:55 PM by N6YFM » Logged
KF7DS
Member

Posts: 288




Ignore
« Reply #14 on: October 05, 2017, 11:18:41 PM »

Neal, great summation and explanation......the best I have seen online.

I had a 6300 and 6500 and sold them due to frustrations in the software. New features always lagged behind promised schedules and were, at times, buggy. And, god forbid what an overnight Windows update may do to your ham radio. It seemed I spent more time futzing on the computer than I should, so I sold them.

Over a year of ownership, my IC 7300 has never had a hiccup. It works as designed when I power up and look forward to a 7610 just for these reasons

Don
« Last Edit: October 05, 2017, 11:25:09 PM by KF7DS » Logged
Pages: [1] 2 Next   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!