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:g4...@classdesign.com] > Sent: Wednesday, July 29, 2015 10:30 AM > To: wsjt-devel@lists.sourceforge.net > 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: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 > 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 > ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
