You are not logged in.
The only udev rule I could find in /etc/udev/rules.d/ was one for my keyboard (so that its lighting stops blinking all the time due to a lack of driver support). Here is the content, I do not see it interfering with anything network related:
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c336", MODE="666" RUN+="/usr/bin/g213-led -p /etc/g810-led/profile"
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c330", MODE="666" RUN+="/usr/bin/g410-led -p /etc/g810-led/profile"
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c33a", MODE="666" RUN+="/usr/bin/g413-led -p /etc/g810-led/profile"
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c333", MODE="666" RUN+="/usr/bin/g610-led -p /etc/g810-led/profile"
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c338", MODE="666" RUN+="/usr/bin/g610-led -p /etc/g810-led/profile"
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c331", MODE="666" RUN+="/usr/bin/g810-led -p /etc/g810-led/profile"
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c337", MODE="666" RUN+="/usr/bin/g810-led -p /etc/g810-led/profile"
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c32b", MODE="666" RUN+="/usr/bin/g910-led -p /etc/g810-led/profile"
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c335", MODE="666" RUN+="/usr/bin/g910-led -p /etc/g810-led/profile"
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c339", MODE="666" RUN+="/usr/bin/gpro-led -p /etc/g810-led/profile"
Offline
EDIT: I guess it's better to let wireshark judge this.
Here is the wireshark output https://imgur.com/a/H9ZLc. I censored it a bit, maybe it is overly cautious but you never know.
When I start twitch i get a shitload of these red lines and a lot more of the black ones, without streaming just the black ones occur occasionally.
The red lines are all to the same IP, so I figure it is the twitch server.
Edit1: Okay the red lines are now gone, the ip is back though when continuing streaming, probably wireshark just categorised as somehow new and made them red I do not know, the black ones remain though and more frequently during twitch. And yes, I do not know much about wireshark.
Edit2: Ehh... okay the next update, apparently me plugging directly into the router did make a difference, at least now I do not have any lag anymore despite auto-negotiation being still off. Thus, the 7 year old network switch might after all have been a problem of some sort. So these black packges (look like some TCP fail) are no problem after all?
Last edited by deafeningsylence (2018-03-05 21:18:16)
Offline
TCP based streaming: what a delight. The red lines you are seeing were indeed TCP resets.
ACKs are nothing to worry about, but those "RST" means like asking a person "can you repeat it" only after earing the first sound of a whole monologue.
Offline
TCP based streaming: what a delight. The red lines you are seeing were indeed TCP resets.
ACKs are nothing to worry about, but those "RST" means like asking a person "can you repeat it" only after earing the first sound of a whole monologue.
That explanation helps, thus, the RSTs stopped happening for now though, with no apparent reason and they did appear when I already removed the old switch, so he cannot be involved. Also ever since they disappeared the lag disappeared.
A side question, I suppose TCP streaming sucks and UDP is the way to go? Can I do anything about that or is that just Twitch being Twitch...
Offline
ever since they disappeared the lag disappeared
Makes sense, since the link is not suffering from heavy congestion anymore. You should analyze a new fresh session (will be hard) looking for the differences beetwen both full and half duplex, with and without the switch, to understand what's really happening.
Or just find a way that makes your nic work as it should, it's up to you.
I suppose TCP streaming sucks and UDP is the way to go? Can I do anything about that
Depends on the point of view: TCP is reliable but provides overhead, the opposite goes for UDP. And you can't do nothing about it unless you want to switch to another stream service.
Offline
Makes sense, since the link is not suffering from heavy congestion anymore. You should analyze a new fresh session (will be hard) looking for the differences beetwen both full and half duplex, with and without the switch, to understand what's really happening.
Or just find a way that makes your nic work as it should, it's up to you.
Oh boy, well I suppose I learn how to wireshark then, for now I am too tired though, I will give this a shot tomorrow. Thanks for lending me your expertise lo1, much appreciated!
I am so confused by now, first the auto-negotiation felt like making a massive difference and now it streams on 1080p60 without any issue but auto-neg. off. The switch is the one major thing that changed in terms of hardware in the whole configuration, I will examine its role more closely.
And when auto-negotiation should be on per default and is on the arch iso from which I installed this system I also need to find out what disables it.
Offline
I am so confused by now, first the auto-negotiation felt like making a massive difference and now it streams on 1080p60 without any issue but auto-neg. off. The switch is the one major thing that changed in terms of hardware in the whole configuration, I will examine its role more closely.
I guess the connection router <-> switch could be full duplex, while the connection switch <-> computer is half duplex and the switch might have some problems with this configuration. If you connect directly, the router cannot auto-negotiate full duplex and uses half duplex just like your computer and you get no problems.
And when auto-negotiation should be on per default and is on the arch iso from which I installed this system I also need to find out what disables it.
Some configuration in /usr/lib/systemd/network, /run/systemd/network, or /etc/systemd/network? There should be some files in the /usr/lib/ location, but none of them should contain Duplex or AutoNegotiate options.
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
I guess the connection router <-> switch could be full duplex, while the connection switch <-> computer is half duplex and the switch might have some problems with this configuration. If you connect directly, the router cannot auto-negotiate full duplex and uses half duplex just like your computer and you get no problems.
That does make sense, I will consider it when I have a closer look at the wireshark traffic of the different configurations.
Some configuration in /usr/lib/systemd/network, /run/systemd/network, or /etc/systemd/network? There should be some files in the /usr/lib/ location, but none of them should contain Duplex or AutoNegotiate options.
There was no file that contained anything regarding auto-neogtiation in the directories you suggested. I did not check the ones in /usr/lib though since they are soo many.
Offline
There was no file that contained anything regarding auto-neogtiation in the directories you suggested. I did not check the ones in /usr/lib though since they are soo many.
I meant /usr/lib/systemd/network, so no worries.
By the way, I think you should be able to use it to enable auto-negotiation instead of your custom script.
printf "%s\n" "[Link]" "AutoNegotiation=yes" >/etc/systemd/network/10-autonegotiate.link
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
Man GUIs are truly a love hate relationship, after searching the forum a bit for specifically 'auto-negotiation', I found a thread with a similar issue where in the end a setting in Network Manager caused the issue, here is a picture:
I will restart now and see if this persists and if in the end networkmanager was the issue.
Edit: Yup, now auto negotiate persists, thus now putting back the switch should also work because all connections are full duplex then, I will check that tomorrow.
Edit2: I cannot believe networkmanager screwed me over, the likely scenario is that I played around with some settings during my recent VPN/DNS tinkering and accidentally ticked away auto-negotiation and then applied the settings with some others that I actually intended.
Last edited by deafeningsylence (2018-03-05 22:53:04)
Offline