dropped packets when client connected from same machine

Steve-N5AC

Yes, but multicast has it's own problems -- specifically that it puts a load on every computer on the subnet.  Generally, for high-volume data applications multicast goes hand-in-hand with VLAN (or segmented networks).  For now, we've assumed that this solution is too much trouble for the typical amateur radio enthusiast so we have not implemented it.  Incidentally, our government products do multicast over VLAN.

K5CG

Very Good Steve, I'm just grasping at straws here. I was just imagining that with all the 3rd party apps that hams are connecting (DDUtil, HRI Agent, DVKs, S-Meters, CMD Micro, DX Lab Suite, FRStack)... The list is getting long. "If" every app opens a new UDP stream... is there a tipping point where multicast makes sense? Don't feel you need to answer, I'm just thinking out loud here again and learning as I go.

Danny

Dan -- KC4GO

Ah ha, I use a gigabit net wired. And my wireless is AC1900. I have a spare router (older N  Linksys E1000 300 Mbps I can test with using my laptop 
@Mark and Eric 
           Let me know if you want me to configure this network and test. 
Dan -- KC4GO

Steve-N5AC

Yes, there's certainly a place for it.  We could also build an aggregation layer for the PC where it keeps track of everything that PC has subscribed to, asks for it once, and distributes to the clients that asked for it.  Lots of things we could do.  Really the panadapter, waterfall and DAX are the big bandwidth users and they are not typically shared today.  Metering is just not a big enough deal to worry a lot about, but someday we may look into this.

Eric-KE5DTO

Note that while there is duplicate data being sent in these situations, the actual "failure" here (supposed packet loss) would be fixed by not duplicating the data on the same port.

Eric-KE5DTO

Dan -- it would be interesting if you could run a test for me.  Close all the Flex related clients and open them in this order:
1. SmartSDR
2. CAT (optional)
3. DAX (optional)
4. HRI

Then confirm whether you get the reported packet loss.  I suspect you will see it when starting things in this order.

Dan -- KC4GO

After less than a min. Now 9197 ..
Dan -- KC4GO

Eric-KE5DTO

This confirms the theory.  Thanks Dan.

Mark_WS7M

I just tried that order.  0 dropped packets and this is with HRI still not connecting to UDP.

Mark_WS7M

So I guess I'm confused.  Should I modify HRI to connect to or specify then connect to a UDP port to solve this issue from my side?

K5CG

I did the same test sequence, I opened HRI Agent at about 3300 total packets logged (none dropped). By the time I got to 6600 logged (doubled) I had 2130 dropped.

Eric-KE5DTO

If you aren't going to use the UDP data, there is no reason to have a UDP listener.  But I would recommend moving the port the radio uses off of the default 4991 using the client udpport command so as not to confuse the SmartSDR packet count.

Steve-N5AC

Mark, you can look in our code, but as I recall we open ports starting with 4991 NOT in a shared mode until we get one that is ours exclusively.  Then we tell the radio it can send the data to that port.  (this is from memory, but I think it's correct)

Mark_WS7M

Hi Steve.  I built a test version that does what Eric recommended.  After connecting I sent out client udpport 32769.  This by Wireshare shows that the radio begins to send UDP packets to 32769.  However I never open that port up and listen since I don't need the UDP data for this application.

In a couple tests this fixed the dropped packets issue.  I'm planning to turn this into a release today for those using it.

The issue is a strange one because when Danny first reported it I started to snoop around and never could see dropped packets on my computer.  Didn't matter the order or what I did.  I might see 10 or so but not continuous and never did my packet latency get bad.

Anyway my question to Eric was simply that if I'm subscribing to slices only why do I even get UDP data?  It might just be a misunderstanding on my part but I'm not trying to get audio or pan/waterfall.  I just want to know what the slice is doing.

Eric-KE5DTO

The short answer is that you probably shouldn't be getting UDP packets from just subscribing to the Slice data.  Definitely should not be receiving UDP packets until you specify a UDP port.

The data you are receiving is meter packets related to the Slices.  This should probably be tied to a "sub meter all" or "sub meter slc all" or something like this though.  I entered this as #2888.

Thanks for helping us sort through this.

K5CG

Please check #2849, if it is related or a duplicate. Steve opened it from earlier info.

Eric-KE5DTO

Thanks for the heads up.  I related them and closed #2849 as I believe we have nailed the root cause and a work around for now.

John G3WGV

Hi Eric,
Sorry to dredge this one back up again but did #2888 get resolved? I am getting the same thing running WinSSDR plus my logging client, which is connected to the TCP stream on 4992. The logging client doesn't use streaming UDP data, so I don't set the port or listen for it. The only thing I'm subscribing to on the TCP port is "slice all". I'm seeing 56% dropped packets on the network diagnostic monitor. Using v1.8.4.84.

I'm guessing the dropped packets relates to UDP so I'm wondering if the radio is streaming stuff I haven't asked for? It's as if meter or FFT data are being streamed to my logging client.

Edit: I changed my logging program to set a different streaming UDP port and that completely fixed the problem. So I am guessing that the radio is streaming a pile of stuff even though I've only subscribed to slices.

John.

Eric-KE5DTO

John,

No problem.  I show that #2888 is still open, but it is scheduled to be worked on.

John G3WGV

Thanks Eric. I'm starting to get the hang of this API now