On 29/07/2015 16:19, Michael Black wrote:
Hi Mike,
Actually just tested and looks like JTAlert is doing multicast too.
So I'll see about tracking this with him.
That can't be so if you cannot change the server address, multicast will
only work with a multicast group address as it requires cooperation from
the NIC and any routers in the network path.
Beware of running multiple servers on the same host without multicast
addressing, in that case each datagram will only be delivered to one
application and appear dropped to the other(s).
I watched his system for a while and didn't see interspersed JT9's but
I'll watch close next time.
Gotta' get some activity on the bands to see this I think. I'll watch
my own system but can't say I've noticed this (and not sure I would
have either since I wasn't looking for it).
Was really obvious on his systems since he doesn't have many JT9's and
they were all missing from JTAlert.
I'm not sure of the underlying logic which causes UDP reordering. I
went through an argument with a banking software firm many years ago
having to inform them that TCP wasn't a guaranteed protocol which they
though it was and they were blaming our software for dropping
transactions when it wasn't our fault at all and they finally had to
add another layer of ACK/NAK to the transactions to ensure end-to-end
integrity even over dropped connections.
UDP reordering usually requires a complex network of routers (the
Internet usually) it can happen if a router fails, has to retry or,
decides a lower cost path is possible. Not really relevant to our
application although WSJT-X doesn't make any assumptions about where on
the Internet the UDP server lives.
Thanks and I'll let you know the results.
73
Mike W9MDB
73
Bill
G4WJS.
*From:*Bill Somerville [mailto:g4...@classdesign.com]
*Sent:* Wednesday, July 29, 2015 10:08 AM
*To:* wsjt-devel@lists.sourceforge.net
*Subject:* Re: [wsjt-devel] UDP messages dropped
On 29/07/2015 15:58, Michael Black wrote:
Hi Mike,
Actually he's running a Flex 3000 and an 8-core machine.
Interesting, is it possible he has set CPU affinity. Maybe it was just
that all the JT9 decodes took longer than the longest JT65 decode but
that is fairly unusual.
JTAlert doesn't currently allow setting the IP address so it's not
multi-cast. I'll see if about getting that done though.
It's not quite as simple as setting the address, a multicast server
has to join the group as well.
Side-by-side is good idea.
And a sequence number does take a step towards TCP but is still not a
bad idea so you can at least detect dropped packets. People could be
using this now and not know they are missing decodes.
Datagrams can also be delivered out of order so it gets complicated
fast. Anyway on a loopback connector neither out of order delivery nor
dropped datagrams should happen unless the receiver is really slow
about responding to received datagrams.
I would really prefer to see confirmation that datagrams are really
going missing by using message_aggregator before we start changing code.
73
Mike W9MDB
73
Bill
G4WJS.
*From:*Bill Somerville [mailto:g4...@classdesign.com]
*Sent:* Wednesday, July 29, 2015 9:47 AM
*To:* wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
*Subject:* Re: [wsjt-devel] UDP messages dropped
On 29/07/2015 15:37, Michael Black wrote:
Hi Mike,
Testing JTAlert 2.6.10 beta with WSJTX 5728 on a friend's setup.
20M came alive yesterday and we observed JTAlert missing, for
example, ALL of the JT9 decodes (which were bunched at the end of
his Band Activity window).
If all the JT9 decodes are together I assume the CPU in use has only
one or two cores as the MT decoding doesn't seem to be active.
It was random…frequently all the JT9's were missed, and sometimes some
random others, sometimes all of them were OK.
So it appears to be some timing issue.
UDP is also known as "Unreliable Data Protocol" but it shouldn't drop
packets very frequently (if at all) on a local network connection.
Can you verify the same behaviour using message_aggregator? I don't
know if JTAlert is multicast compliant but if it is you could use
239.255.0.1 as an address and have JTAlert and message_aggregator both
receiving the messages in parallel for a double verification. Dropped
datagrams on a loopback connector are very unlikely.
So…to help trace this down can we add a 1-byte rolling sequence number
to the Decode message? That would help the client detect any dropped
packets.
That is missing the point of UDP!
Is the access to the socket write from WSJT-X multi-threaded between
JT65 and JT9? Not sure what behavior might in that case.
The UDP messages are sent from the main GUI thread, there are no MT
implications.
73
Mike W9MDB
73
Bill
G4WJS.
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
