Logging/Viewing Wi-Fi instability?

Submitted by MukiEX on #1

I've got a copy of VirtualHere on an RPi4 connected to a Windows and MiSTer Linux client. Works well for the most part, but over wi-fi I get the occasional (every X0 seconds) pause where no input is detected or the last input is held for a few seconds. That part isn't surprising; it's wi-fi after all.

What's surprising is that I don't actually see anything in the server or client logs that imply any kind of lost connection when this occurs, and a ping check between server and client don't change in any way when those pauses/hangs happen. Is there any way to better ascertain what's going on when this happens?

On a side note: It'd be neat if there was a "showcase" forum of what kind of setups people have with VirtualHere. It's a pretty neat product.

Submitted by Michael on Thu, 2021/09/16 - 06:52

#2

Yes in the virtualhere client right click on the Server and select Properties->Latency. That will show the ping times between the server and client. The connection is not dropped. VirtualHere doesnt drop/reconnect transparently, if the connection drops it will disconnect the usb device from the client.

See here https://www.virtualhere.com/node/306 for interesting articles about virtualhere :)

Submitted by MukiEX on Thu, 2021/09/16 - 13:37

#3

Dang, it hangs (no input or holds the last input for several seconds) even on ethernet, hooked up to the same switch. Even with CompressionLimit set to 81920000 in the server's config.ini so it kinda just ignores compressing any packets.

Maybe the Cortex-A9 on the MiSTer's DE-10 Nano can't keep up?

Submitted by Michael on Thu, 2021/09/16 - 15:29

#4

The 800Mhz dual fpga core should be ok. Sounds like some kernel issue.. what does uname -a return?

Submitted by MukiEX on Thu, 2021/09/16 - 15:54

#5

In hoping I'd find the fault in the server hardware (like a bad button or something), I tried playing natively. Loaded up a copy of *Magical Drop III onto my RetroPie, and aside from horendous lag, no buttons were missed. Then I tried VirtualHere on my Windows 10 PC (i7 2700k, also wired into ethernet). Even with the Pi over Wi-Fi, I didn't get any drops, let alone those multi-second pauses.

At this point I'm guessing that vhclientarmhf either can't keep up CPU-wise or there's some other MiSTer-specific issue causing the pauses. It's unfortunate. =(

*which I own on Nintendo Switch, Xbox/PC, "My Arcade Data East Classics Mini", and original MVS cartridge

Submitted by MukiEX on Thu, 2021/09/16 - 15:55

#6

> The 800Mhz dual fpga core should be ok. Sounds like some kernel issue.. what does uname -a return?

Linux MiSTer 5.14.0-MiSTer #1 SMP Mon Sep 6 19:58:01 CST 2021 armv7l GNU/Linux

As a heads up, I'm pretty up-to-date on the vh client:

/media/fat/Scripts# ./vhclientarmhf -h
VirtualHere Client 5.2.1, Use USB devices over a network

Submitted by Michael on Thu, 2021/09/16 - 18:27

#7

What does top show when thevirtualhere client is actively using a USB device?

Submitted by MukiEX on Fri, 2021/09/17 - 14:35

#8

Screencapped and also took the last 60 seconds of the video. Screenshot is on the top and video is on the bottom.
In both cases, MiSTer client is on the left and the RetroPie server is on the right:
https://imgur.com/a/aIcGhMF

The pauses in-game happened a few times, including a few seconds before I took the screenshot in the video.

Looks like the CPU usage never really hit anything crazy. It's the most perplexing thing.

Submitted by MukiEX on Fri, 2021/09/17 - 14:38

#9

Added a longer youtube clip featuring my setup where I added the 4 USB devices (1 Brook Zero-Pi, 1 Brook Retro, 2 GRS USB Spinners (basically mice). Though without a video showing inputs no longer doing anything it's probably not super useful.

Submitted by Michael on Fri, 2021/09/17 - 16:09

#11

top looks fine, except what is /media/fat/MiSTer. Is that the game emulator? It is pegged 100% on one CPU, that doesn't seem right.

Maybe thats starving the cpu or bus for other processes. You could try nice to lower the priority of that process

Submitted by MukiEX on Fri, 2021/09/17 - 16:36

#12

Full command line is:
/media/fat/MiSTer /media/fat/_Console/NeoGeo_20210908.rbf

It's basically the main MiSTer executable that loads the FPGA content. I think I did try re-nice-ing the mister executable to over 0 and re-nice-ing the vhclientarmhf executable to under 0. (individually and both at the same time) No luck.

Submitted by Michael on Fri, 2021/09/17 - 20:03

#13

That's weird its using 100% of one CPU when its just managing an FPGA bit-stream, I would have thought the FPGA would be doing all the work, and the CPU would be left free for running normal processes. ( Im pretty sure that particular chip has a hard CPU)

I don't have anymore ideas, my best guess is that the mister process is taking all the bus bandwidth or leading to CPU contention with other processes.

Submitted by MukiEX on Mon, 2021/09/20 - 14:24

#14

I might have cracked the code on this one, and as you probably deal with often, this is probably user error.

So, after realizing that going from MiSTer to RetroPie isn't gonna work, I drilled an additional hole into the project running this and installed a USB-B Neutrik connector, hooked up directly to the USB hub that's feeding all of these controllers.

Well, after testing on PC and trying MiSTer, I noticed two things:
1. MiSTer would sometimes not work if this cable was plugged into its own (unpowered) USB hub.
2. MiSTer, even if working, would get really similar outages to what I was seeing when networked.

A powered hub fixed it on a direct connection, so the thought came to me that the Pi itself (or the USB hub these controllers are plugged into) might be having small power outages. The two controllers have a single LED connected to their Player1 LED circuit, and the power draw might be too high.

So to test it I connected the Pi to its own battery (this whole thing's on a table and I don't have a powered USB hub on-hand at the moment), connected the neutralink port to a powered hub (I happen to own a USB battery that can be both a recharging unit and a USB hub) and plugged that into the Pi, and finally re-ran my VIRTUALHERE_LINK.sh script on the MiSTer unit.

Well, after trying 10 some odd stages of Magical Drop III, I'm pretty sure I didn't experience a single input drop (usually I'd get 1 or 2 per stage) on the run. So it could just be that the power draw of 4 USB devices and 2 LEDs were too much for either the PI's single USB 2.0 port or the USB hub it's plugged into (admittedly a pretty cheap hub). I'll probably do s'more testing, and maybe try with a Y cable plugged into two of the Pi's USB 3.0 ports (they're externally visible), but I might have a working solution.

Additionally: I did see some outtages with this setup while the Pi was on (its own garbage, tiny-antenna) Wi-Fi, which is probably what made things tricky to nail down. The "not enough power" issue behaves nearly identically to the "wi-fi is kinda crummy for stability" issue.

In any event, I might have a nice, fixed, working system.
This is what it looks like, BTW: https://imgur.com/a/cG339Ol

Submitted by Michael on Mon, 2021/09/20 - 15:36

#15

Thanks for the detailed info!

Have a look in the syslog on the pi and see if it says "undervoltage" anywhere in the log