Archive
 
 
  Topic: Are Dropouts a common problem? (30 replies)
#21     Fri Jun 15, 2007 4:10 pm
W7RJR
Spokane, WA
 
Join Date: Oct 2006
Posts: 114
Subject:


KE7ELT wrote:
Hi
W7RJR, i want to apologize if i offened you i did not mean tyo do so, what i eman about attacking is Doug gave a answer but no one is satisfied , it seems to me that the only answer doug can give is one that everyone thnks he should give , bottom line is you cant satisfy everyone all the time ,and Discussion is good , Ham radio is a brotherhood, again i apologize i hope we can takon cq100 one of thesedays

73s Rich


Hello Rich

No offense taken. I understand how this program means a lot to those who cannot get on-the-air. I think it is a wonderfully innovative creation. I think a lot of people are well satisfied with the program. In fact, the vast majority of Eham.net reviews are positive. The author was well intended by using TCP/IP as it makes installation a breeze and allows many to use it through wireless access points. I really appreciate that when I use it while at the RV campground.

Discussion is good, even when we disagree.

Yes, I hope to have a QSO in the near future.

Good luck!

73
__________________
#22     Mon Jun 18, 2007 1:13 pm
K3KGX
Beaver Falls, PA
 
Join Date: Feb 2007
Posts: 4
Subject: Dropouts

Hi all .. I just wanted to add my 2 cents worth on the dropouts. Yes I have been experiencing dropouts more lately. It seems that it happens only on CW and PSK31 on my end. I don't know what the solution is. Fone seems to fine here. I have tried Hamscope, Mixw and Multipsk software programs and dropouts occur on each one. Hamscope seems to be a little better. It will copy when some of the others print garbage. I giuess this is just like "real radio" with QRM and QRN and something we might have to live with. I tend to agree with Doug that it is not in his program. It is a fine a program and works!!!! We all need to remember, this is just a hobby .... 73's and see you on CQ100

Dan, K3KGX
__________________
#23     Mon Jun 18, 2007 1:39 pm
VE3EFC
 
Join Date: Aug 2006
Posts: 724
Subject:

Hi Dan. Sometimes it might sound like a breakup when really your CPU is over worked. Norton anti-virus uses a lot of CPU. If you are running many other programs like PSK software, your CPU may have difficulty keeping up.

Press Control_Alt_Delete then click PERFORMANCE to see how hard your CPU is working.

73, Doug
__________________
#24     Mon Jun 18, 2007 2:05 pm
W7RJR
Spokane, WA
 
Join Date: Oct 2006
Posts: 114
Subject:


VE3EFC wrote:
Hi Dan. Sometimes it might sound like a breakup when really your CPU is over worked. Norton anti-virus uses a lot of CPU. If you are running many other programs like PSK software, your CPU may have difficulty keeping up.

Press Control_Alt_Delete then click PERFORMANCE to see how hard your CPU is working.

73, Doug


Hello Doug

While this is a possible scenario it would not be common. Would you mind addressing and discussing the performance issues between TCP and UDP? If this is not the problem then your response will help clear it up.


Thanks

73
__________________
#25     Tue Jun 19, 2007 8:27 am
VE3EFC
 
Join Date: Aug 2006
Posts: 724
Subject:

Hi Bob. I fully agree with you that TCP is more sensative to a bad internet connection. However, I would rather lose 5% of people with bad connections than losing 30% of people with port forwarding problems.

If 30% of Echolink users have port trouble, they can come to Qsonet. If 5% of Qsonet users have connection problems they can go to Echolink. I am just trying to explain my reasoning. I am willing to change this opinion if I am wrong. I guess each person's opinion on this subject will depend whether they are part of the 5%, part of the 30% or part of neither.

The other big advantage of TCP is it allows Qsonet to be used in airports, hotels, cafes, RV parks, schools, offices etc.

I always intended for Qsonet to fill a nitch that had been ignored by other programs. I never intended it to be another Echolink with a pretty skin.

73, Doug
__________________
#26     Tue Jun 19, 2007 12:14 pm
W7RJR
Spokane, WA
 
Join Date: Oct 2006
Posts: 114
Subject:

Hi Doug

I understand your rationale for using TCP. I think it is incorrect to say that TCP is more sensitive to a 'bad' internet connection. Here's why.

TCP is the most commonly used transport protocol. Most internet applications employ it because it is reliable. There are a couple of well known exceptions with VOIP being one of them.

As pointed out by a number of people here the internet is not perfect. Packets get misrouted or dropped; data arrives out of order. When an application cannot 'tolerate' such discrepancies TCP is the proper choice.
TCP must maintain a constant connection with the server. It must also constantly negotiate errors with the server in the form of a handshake. This overhead often brings the data stream to a crawl, resulting in poor performance. If the client computer also has additional background internet related processes they will add to the delay creating time outs, dropped IP segments, etc. These are dropouts. If severe enough the connection may be lost requiring logging back in again. This process can be examined in detail with a packet analyzer.

On the other hand, UDP does not require a constant connection to the server nor does it negotiate errors. Packets that are missed are simply ignored (dropped). Data that arrives out of order is handled at a higher level of the stack. This results in an extremely fast data stream or very high performance.

At first glance it may seem that UDP would be a poor choice because it does not correct errors. The audio waveform is relatively simple. If small parts of it were missing the human ear would not even detect it. Performance is important with VOIP applications because the human ear will detect 'gaps' created by unnecessary error checking. This is why UDP is the industry standard for VOIP and video applications.

As you point out the use of TCP does have a few advantages such as not requiring port forwarding, use with wireless access points, etc. Also, it stands to reason that as long as you have a perfect internet connection TCP will provide a better quality audio waveform. The problem occurs when your connection becomes less than perfect. UDP doesn't care and just keeps on ticking :-)

From a technical standpoint I am convinced that TCP causes the majority of dropouts. They can be minimized by stopping some services and by ending background processes. This is simply not practical.

I have heard several people express a fear of forwarding a port because it may allow hackers in their system or because it is too confusing. If your computer is using a proper firewall these open ports will not be detected by anyone 'port scanning'. Port forwarding is no more difficult to do than making a few entries from your router menu. You can also use port triggering for further security.

Perhaps a future version of CQ100 will incorporate the best of both worlds?

Thanks Doug for providing us with a great program. I look forward to improvements and enhancements. I wish you luck and continued success.

73

Bob, W7RJR
__________________
#27     Tue Jun 19, 2007 2:15 pm
VE3EFC
 
Join Date: Aug 2006
Posts: 724
Subject:

Hi Bob. I fully agree with your comments.

In an ideal world UDP is the way to go for VOIP, the big issue being latency more than dropouts. Ham radio operators are used to working as a one-way conversation, so for this unique group, latency is not important.

So if we forget about latency, we need to trade-off the two issues you raise: 30% who cannot use UDP at all versus 5% who have breakups due to overloaded TCP. For me this decision was easy.

If someone is getting big breakups on TCP, they are still going to be getting smaller breakups on UDP.

We spent several weeks investigating the Jabber protocol which allows a mixture of UDP and TCP, but we found Jabber was very complicated and it did not achieve what was intended.
__________________
#28     Tue Jun 19, 2007 2:47 pm
W7RJR
Spokane, WA
 
Join Date: Oct 2006
Posts: 114
Subject:

Hello Doug

Thanks for agreeing with my previous comments.

I don't understand why you feel latency is not important? It's a major measurement of internet performance. Whether our communication is duplex or simplex seems irrelevant. A hiatus is a hiatus. Latency contributes to delays and TCP performance issues.

Small breakups on UDP will not be detected by the human ear.

I don't know where you got the 30% and 5% figures from. I can only assume they come from your experience with CQPhone users. You feel that 30% of users cannot use UDP. Perhaps this is because they have trouble or don't want to attempt to open a port. They miss out on using other programs.

When you refer to overload I suspect you mean network congestion.
I would suspect a much larger percentage of users would experience that especially when using VOIP with TCP.

Well, it's a design choice. One has to balance the advantages and disadvantages.

Thanks and TTYL.

73
__________________
#29     Tue Jun 19, 2007 4:24 pm
KE7ELT
Laugh, Nevada U.S.A.
 
Join Date: Apr 2007
Posts: 12
Subject: Droputs

Hi doug
i ws in a QSO on 14.195 last night with KB3LVP and it seems we kept getting as droput while talking message scrolled across about of radio screen saying connecting to QSO net 20 meters , i couldnt transmit and had to leave CQ100 and wait a few minutes and restart it this happened about 5 times , dont know what caused it maybe you can help thanks for
the Great program 73s
Rich KE7ELT
__________________
#30     Fri Jun 22, 2007 9:58 am
VE3EFC
 
Join Date: Aug 2006
Posts: 724
Subject:

Hi Bob. With CQPhone, we found a latency exceeding 200 milliseconds made it uncomfortable to carry on a 2 way (telephone-like) conversation. The way hams talk, a latency exceeding 500 milliseconds will not even be noticed. Latency does not cause breakups, but a bad internet connection will cause both. Both problems will be worse on TCP than UDP. My choice of TCP is to solve the port-forwarding problem.

Phone companies do want people to use VOIP, so they are providing DSL modems with UDP ports blocked. Nobody at the phone company will admit their modems are blocking ports, and they will never give you the password to configure your modem. I spent 2 hours on the telephone one afternoon trying to help somebody on Bell South to forward ports through a DSL modem.

If someone is smart enough to open ports through their firewall(s), router and DSL modem, they end up trying to talk to someone who is not so smart and the conversation fails anyway.

I get dozens of emails every day complaining that CQPhone does not work. My decision to use TCP for Qsonet was the best decision I ever made :)

A few months ago I made a presentation to the local radio club about Qsonet. Meetings are held in the college classroom. The CQ100 transceiver immediately connected through the college wireless internet and the demonstration worked perfectly. Later, I was told that a previous demonstration of Echolink failed because echolink could not use the internet.

Qsonet works in schools, corporations, hotel rooms, internet cafes, RV parks - places where a UDP type program could never work.

73, Doug
__________________




Copyright ©2013 Cormac Technologies Inc.