[Not an issue] [rpi02w] Maybe OC (?)

[CnC-ode]

Hey nisargjhaveri and contributing members!

I would like to congratulate you all for the work!

My daily use: Spotify + Maps. Music plays with great quality and without chops, and navigation framerate is fairly smooth.

The only (minor) issue I found is the experience on the UI being a little bit more laggy as opposed to using the cable connection, but if I pause the music, lag just disappears...

This leads me to believe that:

• When playing high bitrate sound + maps, wi-fi connection (being 2.4ghz) doesn't have enough throughput to handle UI smoothly, or
• The zero2w just doesn't have enough processing power to handle all this together, or...
• Both xD

I will play around a bit with the OC on the pi to see if I can manage to make it handle this better... But I'm not sure about one thing: as I understand, your code acts like a proxy, routing wi-fi packets to usb. If that is the case, it only consumes CPU + RAM + wi-fi, or does the code uses GPU too? From the following OC parameters, which ones do you think will have an impact on performance:

• arm_freq (cpu)
• core_freq (gpu)
• sdram_freq (ram)

Cheers!

[cjhnz]

I found when test version 0.2 on he rpi02w it was getting fairly warm. I couldn't get that version working properly but I could ssh from the wifi into the device and I was pinging the device and found it was dropping packets. When putting it up by a airvent in the car it seem to become more stable. I wonder if its actually running too hot and then throttling.

[CnC-ode]

@cjhnz I'm sorry mate, but i'm gonna have to disagree with you... I'm running v0.3.0 now, but even when I was on v0.2.0, the pi02w worked like a charm!

I did some monitoring today during my 15m lunch trip: lost 1 ping request and max temperature was ~50ºC:

ping.txt

C:\>ping 10.0.0.1
Pinging 10.0.0.1 with 32 bytes of data:
Reply from 10.0.0.1: bytes=32 time=7ms TTL=64
Reply from 10.0.0.1: bytes=32 time=5ms TTL=64
Reply from 10.0.0.1: bytes=32 time=1ms TTL=64
[...]
Ping statistics for 10.0.0.1:
    Packets: Sent = 1060, Received = 1048, Lost = 12 (1% loss), --> (11/12 packets were lost after I turned off the car)
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 109ms, Average = 6ms

temp.txt

# while true; do cat /sys/devices/virtual/thermal/thermal_zone0/temp; sleep 5; done
48312
47236
[...]
50464
49926

As always, I was running Spotify + Maps. The pi its not overclocked (yet... xD), has no heatsink and is inside the original case with the full closed lid, so I can't guess what could've gone wrong in your case :/

As I said, the only thing I notice that is diferent from the usb connected experience is a slightly more laggish UI experience, but only when Spotify is playing. However, this isn't a deal breaker, because it is a bearable minimal lag.

[nisargjhaveri]

Hi, thanks for the analysis. My hunch would be that the Wifi, and not the CPU might be the bottleneck on RPi Zero 2W. There might also be some potential optimisation in out forwarding code itself. But not really sure. You can try to check how is the CPU utilization?

[CnC-ode]

Hello again,

No need to thank me... It's the least I can do for leeching your code xD

I did another logging session on my way home today where I captured top and ifconfig each 5 seconds and... now I'm really confused:

top.log

CPU load averaged 4%

ifconfig.log

RX averaged 488906 bytes/s
TX averaged 10665 bytes/s

This means nothing is bottlenecking on the pi side: 500 | 10 Kb/s and 4% cpu is really nothing... Can't really figure out what can be causing the input lag when Spotify is playing...

[kevinleung987]

+1 I'm also on a Raspberry Pi Zero 2W

The old 0.2 release was unusable for me but the 0.3 release with the disabled-HDMI fix works great, aside from stutters in the audio. I also suffer from the same UI lag when music is playing.

The audio stutters seem to only appear for me when Spotify is playing and I get a navigation audio prompt.

[CnC-ode]

From my hardware monitoring sessions, I've excluded the possibility of network or processing bottlenecks...

My guess is that it has something to do with the bidirectional forwarding of the packets: when Spotify is playing there's a lot of traffic going TCP->USB... My car has physical controls for the UI. For example, when I try to scroll my playlists, on inputting "down" on the controls, I guess a packet has to go from USB->TCP. This type of input commands have a tiny visible lag, but only when music is playing,..

@nisargjhaveri do you think this is what could be happening?

As for the audio stutters, I don't have that symptom... When a navigation alert prompts, music volume gets lower as it should, but no stutter...

Again, this is not a deal-breaking issue for me, but it would be nice if I could get it to work better.

[nisargjhaveri]

I'm out of ideas. I believe Wifi interference can sometimes cause some issues, in which case you can try changing Wifi chanels if it helps.

[CnC-ode]

yeah... I don't believe wifi has something to do with it... I believe this is a matter of packet handling/priority, because it only happens when music is playing, which means that a constant stream of packets is being handled. When a UI control packet is received, it just isn't timely handled, thus the micro-lag...