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.
]]>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
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.
]]>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.
]]>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.
]]>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.
]]>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...
]]>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.
]]>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?
]]>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"
Do you have configured a .link file in systemd (man systemd.link)? There are configuration options for Duplex and AutoNegotiation. Or maybe you have some other strange udev rule?
Is the setting different if you boot from an archlinux iso?
Hey progandy, thanks for pitching in, I tried and with the arch-iso (chroot into my partition) auto-negotiation is on! Thus, I must have some weird rule that disables it, although I am very sure that I never directly and consciously tinkered with udev.
You can do your own research about it, but it basically means one thing: the transmitting device doesn't have a care in the world about your lost packages, because UDP doesn't require "acknowledgements".
So while setting your nic to full duplex is providing overall benefit to your network performance, I must admit I'm still wondering exactly how duplex mismatch could interfere with streaming and thus UDP dataflow.
Mh, strange then, I lack the in-depth knowledge at this moment so I just took what I got from the duplex mismatch wiki article and the few cisco instruction lines I read and came to the conclusion that the duplex mismatch is crippling my internet speed, since it is also so explicitly stated that this mismatch leads to a functioning but very slow connection which is exactly what happens for me and is resolved when I disable it. However, maybe you guys are right and there is something else here and the increased speed through auto-negotiation just increases the speed enough to make it unnoticeable.
The fact that the arch-iso does not show this behaviour though tells me that there must be something wrong with my system. Any suggestions where I could search for any custom rules that effect auto-negotiation?
PS: I checked being directly plugged into my router and this does not change anything (with reboot etc.), thus it is not my old network switch.
]]>You can do your own research about it, but it basically means one thing: the transmitting device doesn't have a care in the world about your lost packages, because UDP doesn't require "acknowledgements".
So while setting your nic to full duplex is providing overall benefit to your network performance, I must admit I'm still wondering exactly how duplex mismatch could interfere with streaming and thus UDP dataflow.
Note that I already stated this when I suggested to switch to autonegotiation on:
I'm not even sure if this will tangibly benefit your network performance.
I was thinking about MTU path discovery and the possibility that, to avoid collisions due to half duplex, a rather consisent IP fragmentation is taking place. But that would be just my theories, and would better fit into Off-Topic since this has probably nothing to do with how Arch/*nix work.
EDIT: I guess it's better to let wireshark judge this.
]]>Is the setting different if you boot from an archlinux iso?
]]>Tbh, I don't buy this. Even in worst case a half duplex 100 ethernet should not cause drastic limitations on the downstream and the speedtest results don't reflect that either.
The only thing I could remotely imagine is that twitch heavily relies on upstream (beyond a few ACK packages) and your "router" does virtually nothing but just passing packages (is it a router or a modem?)That said: just tried twitch.tv and it's basically unusable (on a faster connection w/ full duplex) and it causes no notable upstream at all. Also the quality varies with the channel and sometimes I can play at ~1MiB and sometimes not at ~256KiB.
Do you have trouble eg. using youtube w/o enforcing autoneg (and in doubt using youtube-video to sidestep possible browser issues)
Hey seth, thanks for the reply, I do have slower prebuffering on YouTube when I set the quality to higher resolutions but I can indeed watch a 720p video without the video stopping to buffer, which is not the case on Twitch. Also the on YT I get up to 2MiB as well when loading a video (of course with spikes back to 300KiB, same as you) but for Twitch it never goes that high at all and whenever it is set to anything above 360p it stops to buffer every few seconds.
I excluded browser issues by running twitch via streamlink in different players (vlc, mpd) and the lags remain. Similarly, YT runs fine in youtube-video but prebuffers faster without (at least from what I see in the prebuffering bar/indicators).
The reason I think the auto-negotiation being off is at least part of the cause, is because when I renable it and the mode reverts to full, no lags at all for Twitch and YT loads faster, also I experience no hickups in browsing anymore, which sometimes occured.
From what I read about auto-negotiation it should never be off in client systems and it only makes sense for servers to configure it manually. Also, as far as I understood it the reason is not the duplex mode itself but the duplex mismatch leading to slowed network traffic, that is my pc NIC runs in half duplex and my router in full leading to lost packages, error correction attempts that also fail and further "clog the line", slowing the connection.
"the end result is a connection that is working but performs extremely poorly because of the duplex mismatch"
I think the differences between YouTube and Twitch just depend on the efficiency and quality (kbps not resolution) of the applied encoding.
Now I just need to find out why auto-negotiation is turned off after every reboot. Already wrote Realtek an email about it, I will report back here.
]]>That said: just tried twitch.tv and it's basically unusable (on a faster connection w/ full duplex) and it causes no notable upstream at all. Also the quality varies with the channel and sometimes I can play at ~1MiB and sometimes not at ~256KiB.
Do you have trouble eg. using youtube w/o enforcing autoneg (and in doubt using youtube-video to sidestep possible browser issues)
]]>