Bill
The length of the UDP packet does not seem to be the issue. It turns out
that the packet loss rate that I'm seeing has gone *way* down and is now
negligible. I suspect that there was a congested link somewhere. However, I
can only spot lost packets if I get the occasional packet -- and it app
On 07/06/2020 02:23, Philip Gladstone wrote:
There are a (small) number of WSJT-X users who have difficulty
reporting their spots to pskreporter. Some of these are in "difficult"
areas of network connectivity (e.g. Marine Mobile) and I suspect that
the UDP transport is losing most of their pack
-
"Hi, I'd like to hear a TCP joke."
-
"Hello, would you like to hear a TCP joke?"
-
"Yes, I'd like to hear a TCP joke."
-
"OK, I'll tell you a TCP joke."
-
"Ok, I will hear a TCP joke."
-
"Are you ready to hear a TCP joke?"
-
"Yes, I am ready to hea
Wow -- that generated a lot of discussion. In no particular order:
* Yes, the test server should be working on UDP and TCP.
* Yes, you can send the UDP packets when they are full. The 5 minute
constraint is a hold over from the days when there were only a couple of
spots in that time and I wanted
Since you're already batching the reports in 5 minute intervals I wouldn't keep
the connection open.Just make it, report, and close it. And if it gets an
error just drop 'em and maybe stuff a message in the decode window (rather than
a dialog box) that says "PSK Reporter error" maybe with the e
Hi Peter et all, I have some experience in DMR & multimode servers
using udp for voice packets in the 'one shot hope for the best result'
connectionless nature of UDP traffic needed to
handle the immense traffic load and also multiple streams together, such
as the DMR openbridge system,
How
On 07/06/2020 02:23, Philip Gladstone wrote:
There are a (small) number of WSJT-X users who have difficulty
reporting their spots to pskreporter. Some of these are in "difficult"
areas of network connectivity (e.g. Marine Mobile) and I suspect that
the UDP transport is losing most of their pack
s best) implemented there.
>
> 73
>
> Steve I
> VK3VM / VK3SIR
>
> *From:* Peter Sumner
> *Sent:* Sunday, 7 June 2020 3:43 PM
> *To:* WSJT software development
> *Subject:* Re: [wsjt-devel] WSJT-X and PSKReporter
>
> Hi Adrian, messages via TCP put a
Hi Peter:
While its true that the TCP protocol puts additional computing requirements on
both the sender (the local PC) and the recipient to guarantee the reliable,
ordered, and error-checked delivery of data, these additional requirements are
nearly insignificant in modern fast networks and ne
To: WSJT software development
Subject: Re: [wsjt-devel] WSJT-X and PSKReporter
Hi Adrian, messages via TCP put a requirement on the local PC to handle errors
which all add complexity and resources to do it. The messages have to be sent,
an answer waited for and if no answer, sent again until a
Hi Adrian, messages via TCP put a requirement on the local PC to handle
errors which all add complexity and resources to do it. The messages have
to be sent, an answer waited for and if no answer, sent again until a time
out is received, then handle this time out... UDP on the other hand is a
send
This sounds like a great idea. I am surprised it is not already done via
tcp.
On 7/6/20 11:23 am, Philip Gladstone wrote:
There are a (small) number of WSJT-X users who have difficulty
reporting their spots to pskreporter. Some of these are in "difficult"
areas of network connectivity (e.g. M
There are a (small) number of WSJT-X users who have difficulty reporting
their spots to pskreporter. Some of these are in "difficult" areas of
network connectivity (e.g. Marine Mobile) and I suspect that the UDP
transport is losing most of their packets. The general loss rate seems to
be around 1%-
13 matches
Mail list logo
