smart sdr version 3

Steve K9ZW

Pat N6PAT

Huh???

KC2QMA_John

James Whiteway

Bill is not an employee of FRS as far as I know. Just very much into their products. Even though he and I may have different opinions of FRS and their business model at times, I do respect his opinion. And his quotes from FRS at times has kept me from having to dig for answers. ( I've never found a single quote of his to not be correct,yet) James WD5GWY

Bill -VA3WTB

I have..lol

Ted VE3TRQ

Bill's only fault is his enthusiasm :-) Merry Christmas, and I hope FRS _does_ deliver us a present sooner rather than later.

Mike-VA3MW

Pat

I don't think we have any machines running on Windows 8.1 in house.  Windows 8.1 was not one of Microsoft's best releases and it was pretty much left in the dust but most of the customer base.  It is also End of Lifed by Microsoft on January 9, 2018.  I will also make an executive guess that no one on our Alpha team is running it since it was too bloated and just plain slow. 

You would do yourself a favour to upgrade to Win 10 Pro for  many reasons.

I have no idea how many customers are running SmartSDR on Windows 8.1, but it might be a small install base.   I did check with Tim and he has to see an issue that is unique to Windows 8 if that helps at all.

I think Steve addressed some other concerns.    

Mike 

Mike-VA3MW

Hi Salvador

Thanks for this.  I have seen the same issue from time to time (not all the time) and reported on on #4949.    I do use SmartEther VPN with encryption turned off - or I used to.  I am 100% SmartLink now.

I talked to engineering about it there is a slight be of overhead on SmartLink channel, but it continues to be a Peer to Peer connection between the radio and the end user.  

On your 2 screen shots, you are seeing about 50ms overhead.  When I ran long term tests, the difference was about 25ms (this is not an official FRS test, just me being a typical user).  

What I can say is that 50ms made no difference on my operating experience either for rag chewing on contesting and my internet at my remote end is pretty limited.

Mike

Mike-VA3MW

Burt, can you explain, step by step what you are trying to do?  There might be a bug in there on 2.4.9, but I have yet to be able to recreate it.  

In order for us to deal with it, we need to recreate it.

Take some time and elaborate please.

Mike-VA3MW

Yes, there was a v3 link in the store.  It is part of getting ready for the release when it happens.  It is actually somewhat hidden and you can't find it normally, but not hard for people like Jean.   

You do that well in advance just so you can test things.  Not a big deal.

As for when, Steve N5AC answered below.  Feel free to read on.

KC8P

Pat N6PAT

Mike,

According to Tim Flex stopped supporting SSDR on versions of Windows that reached EOL. Therefore, Flex stopped supporting SSDR for my 8.1 machine almost a year ago right around when Flex released V2.

So I purchased for $199 SSDR that was not going to be supported by Flex because I was using a version of Windows that had just reached EOL.

Did Flex inform anyone of this when they stopped the support for 8.1? I didn't see any notice. Do you think I would have paid $199 for software if I thought it wasn't being supported?

Why did I have to ask about this 6 times and never get an answer until I opened a ticket? I asked Steve directly a few days ago and he answered a different question but ignored this question.

I paid $7,000 for my 6700 and I expect better customer service than this. Flex has made a great radio. I think it's the best on the market and I say so on QRZ almost every day. Unfortunately I would not rate your customer service  as high

Mike VE3CKO

Mark WS7M

Would be nice, but if I were FRS I would not release over the holidays just to keep the customer support down during the holidays.

But yes... Looking forward to it.

Mike-VA3MW

So, I had to do some digging on this after I consulted with Eric.  The, I had to convert that to something we could all understand.  Thanks to Google, I found that it worded nicely.  Short story is that it is not uncommon for RTT to be longer than Ping as RTT is calculated totally differently.

Round-trip time (RTT) is the time it takes for a packet to go from the sending endpoint to the receiving endpoint and back. There are many factors that affect RTT, including propagation delay, processing delay, queuing delay, and encoding delay. These factors are generally constant for a given pair of communicating endpoints. In addition, network congestion can add a dynamic component to RTT.  

Propagation delay is usually the dominant component in RTT. It ranges from a few milliseconds to hundreds of milliseconds depending on whether the endpoints are separated by a few kilometers or by an entire ocean.

The remaining components (processing, queuing, and encoding delays) can vary by the number of nodes in the network connecting endpoints. When only a few router hops separate endpoints, these factors are negligible.

In real-time communications, we must consider the impact of network topology on RTT. Any infrastructure-based topology introduces incremental delay as compared to a peer-to-peer connection. 

Round-trip time and ping time are often considered synonymous. While ping time may provide a good RTT estimate, it differs in that most ping tests are executed within the transport protocol using ICMP packets. In contrast, RTT is measured at the application layer and includes the additional processing delay produced by higher level protocols and applications (e.g. HTTPS or other protocols).

Network latency is closely related, but different than RTT. Latency is the time it takes for a packet to go from the sending endpoint to the receiving endpoint. Many factors may affect the latency of a service. Latency is not explicitly equal to half of RTT, because delay may be asymmetrical between any two given endpoints. RTT includes processing delay at the echoing endpoint.


I hope that helps explain it (and, I learned something as well).

Mike 

KC8P

Mike-VA3MW

Hi Mario

Not in the near future, only as they are headsdown in V3.  And, I mean seriously heads down.  That is why they haven't been online as much as they have in the past.  We have a bug logged on this (4949 I think the number is).    Getting them to go back and dig at published code will distract them from the current goals of V3.  Your question is similar to those I've seen in the gaming community.

But, I did discuss it with them and he did confirm that between the application and the priority that they are processed that this ok.   Yes, it is the application level RTT.

Personally I operate 100% HF remote for DX and Contests and haven't ever seen it as a problem that impacted my operating at 100ms.  If the number was never published, then we would never know.

What I don't know is if ICMP Ping is a measure of the time from sent to received, or is it just the time for my packet to reach the far end.  

The other thing to consider is that Ping using windows and ICMP is only 32 bytes long and in Linux is 56 bytes.  With SmartSDR showing RTT, that packet is significantly longer, so while you may see much longer times that your ping times, we really aren't moving the same type of payload with the priority.

Mike

Neal Pollack, N6YFM

mikeatthebeach .

Life is too short so I use CATSync Web SDR with SmartSDR SSDR and mute My Flex Receiver which is questionable and mute it and use WebSDR receivers Since I cannot take out interference with phasing similar to Anan100D to geout Plasma TV Interference, Solar Panels and Plant **** grow lights Just my two cents Life is too short to wait for stuff “fixes” that may never be !

KC8P

KC8P

Al_NN4ZZ

Hi Neal,
My background is in IT also and includes mainframe, mini and micro systems and software.  Our systems also served many customers but is much smaller in scale than the systems you described.  We probably have on the order of a hundred active defects across all of them at one time.  If a bug doesn't have any real impact (e.g. a typo in an error message) then it might just be closed. 

The SSDR ecosystem would be smaller in scale that either of these examples.  So I would have expected significantly fewer than 1,000 active defects for SSDR.  It would be interesting to get the FRS perspective since I'm sure they use a defect tracking system and could provide a number.  Typically the defect trackers contain a lot of detail on the defect.  Some of the detail can be supposition, or confusing without the full context and proprietary so I understand why FRS would not want to publish the list.  

But every defect must have been discovered by someone (tester, coder, user) and then documented.  1,000 active defects in SSDR defect log still sounds quite high to me.  

I guess the number will be speculation unless Steve or someone from FRS wants to provide the details. 

Regards,  Al / NN4ZZ  
al (at) nn4zz (dot) com

 

Neal Pollack, N6YFM

There is no reason for any appliance or electronics company to disclose
this information, since the general public simply does not understand the
process and economics, and that information would be used by their
competitors marketing group, who would never disclose THEIR own bug

Mark WS7M

I've always worked for smaller companies except for one small stint for Agilent which really was not fun.

My software work has been highly technical.  For years I wrote software to measure tiny things.  During those years I was far more comfortable thinking in micro-inches than anything else.   

During that time I wrote software that helped build many of the rotating disks by manufacturers like Seagate, Tandum, Micropolis and many others. 

During this period in time our bug lists were always very small.  First the software was small but bugs meant a line was down usually so we spent lots of time with extensive verification and validation plans and we practiced fault tolerant methods whenever possible.   Still we had bugs and as described here we had a process for deciding if a bug was worth fixing or not.

These days I work in the research medical industry on a very complex piece of software that captures data at very high event rates and plots this data on graphs for the user while computing statistics on the data and controlling the instrument at the same time.

I would honestly say our software is more bug prone now down it was in my disk drive years because as a research tool these users sort of expect it.  It drives me crazy but that is the mind set.  

I have no issue with another $199 for 3.0 when it is released.  Each day I connect to my radio and listen to the world I realize it is a heck of lot cheaper than travel.

KC8P

I don't know any private software company that disclose their bug list publicly....SmartSDR is a proprietary software that comes with support, if you experience particular issue contact them and they will tell you if this is a bug or not...on another end if you dealing with open software package with community support and contribution you will easily find a bug tracker for every single issue, but this is a little bit different story...

Also, if there is well known bug affecting software the common practice is to create a KB article with workaround until permanent fix will be avaiable to help the customer and reduce the number support requests.

 

Pat N6PAT

KC8P

Pat N6PAT

You need to review what the FRS employees said in their posts.

KC8P

Jon_KF2E

"and what will happen on July 15, 2015 for Windows Server 2003."

Did they miss the date or has it already happened?

Jon