Well..by "busy" I mean he's got only 2 idle cores when running. The other 6 are not pegged at all but run 25-50% or so. 73 Mike W9MDB
-----Original Message----- From: KI7MT [mailto:[email protected]] Sent: Wednesday, July 29, 2015 11:26 PM To: WSJT software development Subject: Re: [wsjt-devel] UDP messages dropped I wouldn't think the box is loaded to hard with an 8350 engine, those have a bit of pep to them, unless he's go allot of background tasking going on. Way OT here, but: I've had a pile of the AMD FX Black edition CPU's at one point, and still have a couple in the basement running as servers. Early models were not too good, but the 8-Series seems ok. My next build is going to be on a Tyan or Supermicro motherboard, with at least 2x 6-Series Opteron's, like the 6344's or there about would be nice.. I'd like a 4-hole motherboard, but that can get expensive in a hurry :-) 73's Greg, KI7MT On 07/29/2015 09:48 PM, Michael Black wrote: > Ran some tests and confirmed WSJT-X was sending out all packets. > Interesting that when we used multicast no packets got dropped > ever.only when using unicast localhost. > > > > Laurie said JTAlert only has a 128 byte buffer so that may explain the > problem. He's aware now and hopefully we'll have a fix soon. > > > > I have to write a test program for my friend as his system appears to > be single-threading WSJT-X. He's running a Flex 3000 so his 8-core > system is still pretty busy but the JT9 decodes have a noticeable > delay after the JT65 and are all bunched together. > > So I'll create a program to test how many cores his system reports. > Is an AMD 8350 CPU. > > > > 73 > > Mike W9MDB > > > > From: Bill Somerville [mailto:[email protected]] > Sent: Wednesday, July 29, 2015 10:30 AM > To: [email protected] > Subject: Re: [wsjt-devel] UDP messages dropped > > > > 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:[email protected]] > Sent: Wednesday, July 29, 2015 10:08 AM > To: [email protected] > 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:[email protected]] > Sent: Wednesday, July 29, 2015 9:47 AM > To: [email protected] > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > ---------------------------------------------------------------------------- -- _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
