search

sakaki- / gentoo-on-rpi-64bit

Bootable 64-bit Gentoo image for the Raspberry Pi4B, 3B & 3B+, with Linux 5.4, OpenRC, Xfce4, VC4/V3D, camera and h/w codec support, weekly-autobuild binhost
GNU General Public License v3.0
921 stars 126 forks source link

Fresh install problems #154

Closed jonesmz closed 4 years ago

jonesmz commented 4 years ago

I'm merging these (probably?) distinct issues into a single issue because I don't think the issue list for the project here on github needs to be cluttered, and honestly i have no idea if any of them are even items that can be addressed by this project, but maybe someone can shed some light on my problems.

Steps to install: curl https://github.com/sakaki-/gentoo-on-rpi-64bit/releases/download/v1.5.4/genpi64.img.xz | xz --decompress | mbuffer -H -d -m 1G -o /dev/sdb

Where /dev/sdb is a class 10 micro sd card attached via a USB->microsd card adapter (specifically this card, https://www.amazon.com/gp/product/B079H6PDCK/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1)

After the install process finished writing the ~10 GB of data to the card, I booted the raspberry pi up and made no other settings changes beyond configuring wifi using the Network Manager gui.

This means that I did not change the raspberry pi configuration for 4k screens, or from 30hz to 60hz in "fresh install" situation. I'll be trying out the 60hz output to see if that helps with the input lag at all.

Hardware:

Raspberry Pi 4B+. I've also attached an always-on cooling fan to ensure no heat problems. (https://www.amazon.com/gp/product/B07W3ZMVP1/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1)

I've got a mini-HDMI -> HDMI cable connected to my TV on HDMI Port 4. The TV is a Vizio E55-E2 (https://www.vizio.com/e55e2.html). It's not plugged into the port that supports the whole ARC protocol that some TV HDMI ports support, but it is instead the HDR port, according to the labeling on the port. Honestly I have no idea how this part of the HDMI spec works, but I'm simply mentioning it for completeness sake.

For human input i'm using a Logitech MK520 Wireless Keyboard and Mouse Combo, which uses a single USB dongle to connect both a keyboard and mouse. The keyboard dongle is plugged into the USB3 port normally.

I also have a Logitech HD Pro Webcam C920, Widescreen camera attached, and have tried it in both USB2 and USB3 ports. As with the keyboard dongle, I use this camera on my Gentoo laptop all the time with absolutely no problems.

Problem 1:

Very noticeable input lag. Keystrokes and mouse movements are very sluggish. It's very hard to quantify, but I'd estimate somewhere around 50-100 milliseconds of lag maybe? Note that this particular wireless keyboard dongle came straight out of my Gentoo laptop that has no input lag at all.

I checked with both USB3 and also USB2, same difference in responsiveness.

Problem 2:

The Chromium web browser seems to get itself stuck between establishing a connection to a web server, and actually displaying the page. E.g. launching Chromium and typing "gmail.co" (note the missing m) into the nav bar made the nav bar stop responding to me, but other parts of Chromium still partially responded. Using ctrl+t to open a new tab made the title bar of the process change to "New Tab", but the new tab never showed up.

A second launch of Chromium (had to kill -9 it, unfortunately) allowed me to finish typing "gmail.com", but the page never loaded. The status bar at the bottom only said "connecting..." for 5 minutes.

By comparison, Firefox loaded gmail within a couple of seconds.

Problem 3:

Firefox, when full screened, well, didn't. It moved itself to the upper left part of the screen, and then partially rendered browser interface widgets in various parts of the screen, but the actual content of the page stayed in the top left with the same dimensions as it had before.

Double clicking the title bar to de-maximize the browser resulted in perfectly normal behavior from the browser.

Could this be a problem with the xfce window manager?

Problem 4: Over a second of input lag on my Logitech webcam. This is when using the raspberry pi live camera app, not the browser.

To be honest, I was slightly surprised that Firefox was able to launch a google hangouts video conference at all, but I don't understand why there was such a large amount of lag when going direct from the camera to the live camera view application.

I imagine that the two web browser problems are most likely completely out of this project's area of responsibility, but I suppose it's possible there's a straight forward way to address them.

Am I missing a configuration setting to get the input lag for either the keyboard, or the webcam down?

sakaki- commented 4 years ago

Hello @jonesmz,

The lag issue you report is a bit strange. I have used both dedicated wireless and Bluetooth keyboards & mice with my various RPi4s and never experienced any significant lag. Have you looked using top or htop to check nothing is hogging your system unexpectedly? Plugging the dongle into the USB2 port to check it isn't some odd USB3 quirk that is required? Using a wired keyboard?

As to hangouts meet, I use this myself on vanilla copies of this image with both Firefox and Chromium, with a camera lag of much less than a second. Make sure in settings for meet, you specify (under the Video tab) send resolution to be "Standard definition (360p)" and receive resolution to be "Standard definition (360p), one video at a time", this helps a lot.

What screen resolution are you using btw? Have you got display compositing turned on? Overclocking?

jonesmz commented 4 years ago

Have you looked using top or htop to check nothing is hogging your system unexpectedly?

Yes, I looked at htop, and didn't see anything unexpected. No CPU usage to speak of, no programs running that I don't know the purpose of.

Plugging the dongle into the USB2 port to check it isn't some odd USB3 quirk that is required?

I tried both USB2 and USB3 for the wireless dongle. The dongle itself predates the USB3 standard, as far as I remember, but regardless it's USB2 only anyway.

Using a wired keyboard?

Using a wired keyboard and mouse doesn't seem to change the input lag in a noticeable way. Unfortunately, when dealing with such small numbers, it's very difficult for me to be scientific about how much lag there is.

As to hangouts meet, I use this myself on vanilla copies of this image with both Firefox and Chromium, with a camera lag of much less than a second. Make sure in settings for meet, you specify (under the Video tab) send resolution to be "Standard definition (360p)" and receive resolution to be "Standard definition (360p), one video at a time", this helps a lot.

While my goal was to use Hangouts to do video conferencing, I did confirm that the camera lag is present without a browser running, using only the RPi Camera Live View program. The same lag persists on both.

What screen resolution are you using btw?

The TV that it's connected to is a 4k screen.

I also tried on my normal desktop's 1080P screen that I use daily. The raspi still has noticeable input lag on that screen as well.

Have you got display compositing turned on?

This is a fresh, completely unconfigured, install. So whatever the default for composting is what's being used.

Overclocking?

I did not modify the overclocking settings from the defaults.

sakaki- commented 4 years ago

So, the (very simple) RPi Live View program does have quite long lag built in due to buffering - it is really designed to check that the optional RPi camera module works (the ribbon-cable connected one), and that output is being sent in h264 format as requested. The relevant lines are here. An external USB webcam may work with it also, depending on model (as seems to be the case with yours). The datapaths used by e.g. firefox, chromium will be different.

To try a lower latency output test, run e.g.:

demouser@pi64 ~ $ ffmpeg -f video4linux2 -video_size 320x240 -i /dev/video0 \
  -vcodec copy -f matroska - | \
  ffplay - -nostats -loglevel 0 -fflags nobuffer

As to keyboard lag, I've never seen anything like that (or had it reported to me) unless the system is heavily loaded e.g. compiling (and there are >1000 instances of this OS in use now, and I use it myself daily). So I'm curious to get to the bottom of what is causing it in your case.

Can I just first double check that htop doesn't indicate you are swapping? Also is there anything else on the USB bus that could be causing continuous interruption? Do you see anything in dmesg?

You may need to increase the amount of GPU memory allocated for a 4k display; see e.g. this post (actually the whole thread is interesting). To do so, use e.g. sudo nano -w /boot/config.txt and change the line saying gpu_mem=128 to gpu_mem=384. Save, and reboot. Does that help?

Then, next thing I would try would be to (temporarily) reduce the resolution on your main display (although I doubt that is the cause, as previously noted): to do so, use Applications→Settings→ARandR, right click on the HDMI-1 display shown and select a resolution from the drop-down, then click the green checkbox to have it taken up (the setting is not persistent across reboots). Then try turning off window manager compositing: to do use Applications→Settings→Window Manager Tweaks, Compositor tab (uncheck Enable display compositing).

To be honest though, I wouldn't expect either of these to be at issue unless you were doing a lot of video-intensive things (YouTube playback etc.)

How much RAM do you have on your RPi4 out of interest (4, 2 or 1GiB)?

One other thing - you may have a sub-optimal microSD card; this can make a big difference. I usually go for A1 rated SanDisk cards; if you have some spare cards of other brands available, please try double checking with one of those (this matters particularly if you ever hit swap).

Also, do you experience the same lags with Raspbian in the identical setup (some displays do have a relatively long lag, of up to 150ms in some cases, but a like-for-like on 4k would eliminate this possibility)? And, if you have the chance to try it, do you get the same lag on your setup with the 'lite' (CLI-only) version of this image?

jonesmz commented 4 years ago

This is all great feedback.

I'll start investigating your suggestions right away. Please give me up to a few days to get back to you on everything.

Some quick replies though:

So, the (very simple) RPi Live View program does have quite long lag built in due to buffering

Aha! Ok, i'll try the ffmpeg version. Maybe that'll drastically improve things.

Can I just first double check that htop doesn't indicate you are swapping?

I suspected the same problem, and checked at the time. I was not swapping.

How much RAM do you have on your RPi4 out of interest (4, 2 or 1GiB)?

It's the 4GB version.

One other thing - you may have a sub-optimal microSD card; this can make a big difference.

It's this model: https://www.amazon.com/gp/product/B079H6PDCK

I just ordered 2 of these to try comparisons with Rasperian: https://www.amazon.com/gp/product/B06XYHN68L it'll be up to a week from now before they get here though.

jonesmz commented 4 years ago

The new SD card has resolved all of the problems that I reported, as far as I can tell.

I am beyond confused, since the one I was using before is supposed to be a high quality card. But lesson learned, apparently.

Thanks for talking with me about the problems. I'll open new issues if I run into anything else.

Btw: I imagine that you saw my comment on this other issue, but was curious if you've had time to give it any thought? https://github.com/sakaki-/gentoo-on-rpi-64bit/issues/110