Intermittent skittles and location not updating in real time

[Fluxcapacitor]

Trying SEQ again after a multi year break. I get skittles intermittently when I zone, and my location and heading do not update in real time. If I sit still for 10-15 seconds my location updates on the map.

Any thoughts? Maybe something with the pcap?

Im running the latest svn from trunk, but I have had the issue for the last several builds since returning in February.
My sytem is Ryzen 1800x 32GB RAM on FC30 EQ is running on Wine on the same box.

Thanks!

[cn187]

If the network you're on is chatty or congested then the kernel might be dropping packets before pcap/seq can consume them. Are you seeing any network related messages in the SEQ console? Dropped packets? Failed decoding? ARQ give up?

If it's congestion related, you can try enabling session tracking and/or real time thread. You can also reduce what pcap has to sort through by specifying your IP or MAC address. (all of this is under the network menu)

If none of that helps then troubleshooting will get a bit more complicated.

Possibly related question - are you running Wayland on your FC30 install, or did you install an X server? As I understand it, Qt (and thus SEQ) isn't supposed to work on Wayland prior to Qt5 (and based on my limited testing, doesn't). I'm curious if you've had better luck with it than I did.

[Fluxcapacitor]

[steve@steve ~]$ echo $XDG_SESSION_TYPE
x11

It seems like it's got a framerate of 0.05 frames per second. ie. one frame every 20 seconds or so.
I closed everything on my PC but EQ and SEQ. Same issue.
No network related messages in the console.
dmesg is clean

[Fluxcapacitor]

I ran a wireshark capture with the same pcap settings udp[0:2] > 1024 and udp[2:2] > 1024 and ether proto 0x0800 and host 192.168.0.2
I get a pretty smooth cadence of packets with no errors.
1515 packets in 203.2 seconds sitting still in guild lobby.

I do eventually get skittles after zoning, it just takes some time. It's like the whole thing is in slow motion.

[cn187]

At least a couple of other people have reported issues with super slow updates. They were using the beta (there are discussions in the beta thread on it), but since it's happening to you with the trunk version, I guess that means it's not beta related.

Unfortunately, I haven't been able to reproduce it, so I don't have a fix. I know one person got the problem to go away with a fresh OS install. I don't know if that's helped in the other case(s) or not. But I do know "try reinstalling" or "try a different distro" isn't generally very welcome advice, so I won't offer that.

Considering how good your system specs are, and that wireshark is fine, (and that I have a working set up similar to yours, but on a much older, lower-spec machine), I have my doubts that it's actually load related. Probably some bug in some specific library version.

I'll set up an FC30 VM and see if I can reproduce the issue there. Though things are pretty busy right now IRL, so I'm not sure how soon I can get to it. It may be a week or two - I don't even have time to play EQ right now :-(

In the mean time, if you're feeling up to it - some profiling data (see https://users.cs.duke.edu/~ola/courses/programming/gprof.html) might prove useful for troubleshooting. If you decide to do it, you can email it to me at cn187 at users.sourceforge.net

[cn187]

Actually, I just saw something that said gprof doesn't really work well for multi-threaded apps. So maybe something like https://oprofile.sourceforge.io/news/ would be a better choice.

[Fluxcapacitor]

I'll try to get some profiling data.

Here is some additional context.

ShowEQ 5.13.10.95, Built from 'main.cpp' on Mar 21 2020 at 22:01:39
CVS: @(#) $Id: main.cpp 760 2012-03-10 05:17:33Z ngdeao $ $Name$
Using GCC version: 5.4.0
Using glibc version: 2.29
Using Qt version: 3.3.8b
Running on Linux release 5.5.10-100.fc30.x86_64 for processor x86_64

I tried the beta and had the same issue.

Thank you for your assistance!

[Fluxcapacitor]

I built it on a FC27 VM I had kicking around and it works fine. It must be something with the build environment.

[Fluxcapacitor]

The gcc version stands out. The FC27 build used 7.3.1 Must be a crusty old symlink somewhere

[Fluxcapacitor]

Fixed the gcc version. still slow.

[Fluxcapacitor]

oprofile data sent

[fransick]

I had crazy slow refresh rates on Fedora compiled box. Tried a bunch of things to fix including different flavors of FC and ended up just installing Centos. Same hardware totally different experience.

[Fluxcapacitor]

I'm using Nvidia blob video driver if that makes a difference.

[cn187]

Any chance you were able to grab that ldd output I emailed you about?

[cn187]

Thanks for the ldd info. There were some minor differences, but nothing that jumped out at me as a likely issue. I did however, get a chance to spin up an FC30 VM, and I can definitely reproduce the issue. So now it's just a matter of digging in and finding the root cause.

[Fluxcapacitor]

Glad you're able to reproduce it. That certainly speeds up the troubleshooting process.
Thank you for looking into it. Please let me know if there is anything else I can do to help.

[cn187]

This appears to be due to a change in the new version of libpcap. When you get a chance, please try the attached patch on your FC30 system and let me know if it fixes it for you.

[Fluxcapacitor]

I did a few quick zones to/from guild lobby and everything appears to be in order. I'll put some hours on it and let you know if I see anything. Thank you for the fix!

[Flatline]

I'm glad you brought this topic up. This has been a problem in my trying to get showeq to run on an uptodate linux install. It's very weird, as you described. It loads ok, but the data is intermittent, with no real way to force an update, it just sometimes does it. I tried putting in older versions of libpcap and that didn't help.

But cn187's patch to that part of showeq works. I now have it running no problem on Ubuntu 19.10. I can post some instructions on how I got it to go if anyone's interested.

So thanks you guys, this has been bugging me for months! Not that there's anything wrong with Centos, but it's nice not to have to reboot just for the one program, hehe.

*edit* maybe this should just be merged into the main release? Doesn't seem like it would hurt anything.

[cn187]

maybe this should just be merged into the main release? Doesn't seem like it would hurt anything.

Ideally that's the goal. But I'm not super familiar with pcap, or with SEQ's network code, so I wanted to give it a little bit to make sure that it not only fixes the problem, but also doesn't break anything. I'm glad it's working for you. I expect I'll commit it to the repo soon.

[Newby]

I'm running debian, which currently provides pcap 1.8.1. I wasn't having issues, but I've applied the patch to see if it breaks. I'll run it for a few days and report back.

I don't expect any problems, but if there are, it shouldn't be hard to set up configure to ifdef the change based on what version of pcap is installed.

[cn187]

Thanks, Newby. It's much appreciated.

[slippery_slope]

@cn187, I was just about to reply that yeah it's a new version of libpcap issue. I'm running Arch so I get all of the fun issues in advance =). I also changed the code in my version to use the new binding libraries because those older functions are theoretically deprecated.

[cn187]

I also changed the code in my version to use the new binding libraries because those older functions are theoretically deprecated.

Please consider submitting a patch with your changes.