Resizing SmartSDR window pane causes packet loss

Phil - AA4MY

This is more of a nit than a problem, but I wanted to share it in case it hadn't been seen before.

When resizing the SmartSDR window, the window pane redraw latency can cause packet loss.  I've missed an FT8 message or two while inadvertently moving windows around.

To reproduce:
1. Open SmartSDR 3.1.8 and your favorite DAX connected application (I use WSJT-X).
2. Open the SmartSDR network statistics window and place it aside.
3. Begin transmitting.
4. Bring SmartSDR to the foreground, click on the bottom right of the application window to resize and drag the window to resize the application horizontally and vertically (i.e. just move the mouse around a few times)

My workstation:
i7-7700k with 16GB of RAM and no other applications running and a GeForce GTX 1080. Windows 10 (10.0.18362.418) with GeForce Driver (26.21.14.3086 - 5/22/2019).  SmartSDR 3.1.8.  Flex 6700.

Mark_WS7M

Each time you resize your pan window you are sending a request down to the radio for a different frame size.  I would expect doing that rapidly enough might cause some slowness.

Also what is your frame rate?  In SSDR how fast are you requesting frames?  I find a lot of people run the FPS slider all the way up and the rate on the waterfall all the way up as well.

This is requesting a pretty big chunk of data pretty rapidly and then moving the window around and resizing it is just extra load.

Your system seems pretty good but you didn't talk about your network.  Are you hardwired from SSDR to the radio?

Not trying to poke holes in your test, but as a software engineer for a company that develops flow cytometers we have to deal with massive high speed data.  Our instrument basically fills a gigabit ethernet pipe when running at full speed and resolution.

It is very difficult to deal with that massive data and not lose a packet or two in the process.

Michael N3LI

How are you measuring packet loss, Phil?

Phil - AA4MY

Directly from the SmartSDR network statistics window.

The packets are dropped at L7, and not at L2/L3.  "netstat -e" shows no dropped frames during a resize event.  This should be trivially reproducible.

Phil - AA4MY

This is an L7 drop event.  The host and Flex are directly connected to an adjacent consumer Netgear managed gigabit switch, and no dropped L2 frames are displayed on the switch or the host (see my "netstat -e" commentary below).

I'm using the default frame rate (25fps).