Feedback Feedback / Technische Fragen zu Xenforo

Feedback-Threads
Nee es funktioniert eben nicht, auch ^^ diese habe ich nicht bekommen,
wenn ich nicht zufällig hier geschaut hätte, hätte ich deine Antwort nicht ein mal mit bekommen .
 
Generell funktioniert das Benachrichtigungssystem.
Warum es in deinem Fall nicht funktioniert @amerran könnten wir jetzt Raten, bis der Arzt kommt bis du mal ein paar Infos rausrückst, wie bspw. welcher Browser und welche addons du nutzt.

Erster allgemeiner Tipp, welcher schon mal zum Ausschließen dient:
Deaktiviere alle Browser addons, wie ad-blocker oder no-script Sachen...
Was ist daran nicht zu verstehen?
 
Gibt es eigentlich Pläne künftig Bilder im .jxr Format hochladen zu können? Finde es schade dass das nicht geht, dadurch geht bei HDR Screenshots die ganze Qualität verloren wenn man im .jpg Format hochladen muss.
 
Sieht eher nicht danach aus, hatte da auch mal angefragt:
 
Gibt es eigentlich Pläne künftig Bilder im .jxr Format hochladen zu können? Finde es schade dass das nicht geht, dadurch geht bei HDR Screenshots die ganze Qualität verloren wenn man im .jpg Format hochladen muss.

Nope. JPEG XR wird zur Zeit von exakt gar keinem aktuellen Browser nativ unterstützt - der Internet Explorer 11 zählt da ausdrücklich nicht zu den aktuellen Browsern.
 
Kurzes Update zum Thema CloudFlare vs. Deutsche Telekom - wir haben gestern um ca. 15:00 Uhr HTTP/3 mit QUIC für pcgameshardware.de wieder aktiviert. Gefühlt lief das gestern abend und heute früh auch bzw. gerade über eine D1-Verbindung merklich flüssiger - möglicherweise ist das allerdings confirmation bias, da ich so etwas erwarte, da QUIC gerade den Handshake deutlich beschleunigt.

Ich möchte Euch bitten, dass Ihr Euch meldet, falls Ihr vermehrt wieder längere Hänger beim Verbindungsaufbau feststellen solltet - wenn die Route sauber funktioniert, ist QUIC nämlich schneller; wenn sie jedoch Ärger macht, ist QUIC dagegen leider empfindlicher - wir müssen also abwägen, wie wir hier weiter verfahren und immer mal wieder testen, was geht und was nicht.

Das grundsätzliche Problem, dass die beiden Parteien sich nach wie vor bzgl. direct routing zwischen CloudFlare- und DTAG-Netz nicht einigen konnten, besteht weiterhin. D.h. die Routen sind z.T. deutlich länger als sie sein müssten, so dass gerade in den Abendstunden Pakete von einem CF-Edge-Server in Frankfurt zu einem Client in Frankfurt mit T-Online- oder T-Mobile-Vertrag einen Weg über die US-Ostküste nehmen.

Dieses Routing-Problem besteht unabhängig vom verwendeten Protokoll. Da QUIC allerdings über UDP läuft, während HTTP/2 noch TCP verwendet, ist HTTP/3 mit QUIC deutlich empfindlicher gegenüber schlechteren Routen, da UDP im Gegensatz zu TCP über keine eingebauten Mechanismen gegen Packet Loss (Congestion Control, Retransmission) auf Protokollebene verfügt - da muss sich dann der Browser drum kümmern und der tut sich da mitunter schwerer, wenn das ganze erst auf Applikationsebene gehandelt werden kann.

Ich durfte mich vorgestern auf der it-sa in Nürnberg etwas länger mit einem Interconnect-Menschen von CloudFlare unterhalten: Der Streit zwischen CloudFlare und der DTAG ist nach deren Darstellung rein politisch, nicht technisch. Soviel können ein paar Border Router in Anschaffung und Betrieb sicher nicht kosten, dass man sich da jahrelang nicht einigen kann. Das Problem ist eher, dass die Telekom auf dem Standpunkt steht, dass die Erlöse, die sie über Verträge mit Mobilfunk-, DSL und Standleitungskunden einnimmt, zwar ganz nice sind, dass es aber eben für den Umsatz noch massiv viel nicer wäre, wenn zusätzlich zu Euch auch Content-Provider wie beispielsweise Netflix, Amazon oder eben auch CloudFlare monatlich Geld an die Telekom überweisen würden. Die Argumentation ist, dass Upstream und Downstream der Netze ja äußerst asymmetrisch sind, also sei das kein Peering auf Augenhöhe, bei dem beide Parteien in etwa gleichviel Traffic in beide Richtungen austauschen. Die Telekom steht daher auf dem Standpunkt, dass sich die Netzneutralität in ihrem Fall gehackt legen darf, nur wer zahlt soll vollen Zugang zu ihren Kunden bekommen.

CloudFlare auf der anderen Seite steht auf dem Standpunkt, dass sie hier keine Kompromisse eingehen können, denn wenn die Telekom ihren Willen bekommt, dann werden das auch andere große Provider - und das gegenwärtige unmetered traffic Modell wäre so nicht länger tragbar. Das hätte auch Auswirkungen auf CloudFlare-Kunden wie uns, da die Kosten sicher weitergegeben werden müssten - wir können es uns allerdings schlicht nicht leisten, Apothekenpreise für Web Application Firewall, CDN und andere Dienste zu zahlen, die wir über CloudFlare beziehen. Und wer sich evtl. noch an die großen DDOS-Wellen von ca. 2012 erinnert, die über den Zeitraum von ein paar Monaten regelmäßig unsere Seiten genuked haben, der wird verstehen, warum wir über die letzten Jahre an sich sehr happy mit CloudFlare gewesen sind - denn solche Angriffe laufen nach wie vor, in der Regel sogar mit noch sehr viel mehr Bandbreite als noch vor über zehn Jahren, das sind Kaliber, die mitunter bereits die Uplinks unseres Rechenzentrums überfordern würden, wenn sie denn nicht bereits durch CloudFlare abgefangen würden.

Laut CloudFlare-Vertreter wurde allerdings in den letzten Monaten insgesamt einiges gerade im europäischen Netz ausgebaut, so dass sich die Routing-Situation selbst bei ein paar Hops mehr deutlich besser darstellen sollte als noch vor einem Jahr. Daher wollen wir jetzt erst einmal wieder testen, ob wir das Setting wieder aktivieren können.

Viele Grüße

Markus
 
*meld*

Aktuell, so in den letzten 10 Minuten, hab ich gern mal ein paar "Denkpausen" beim Seitenaufbau im Forum und auf der main.

Falls ich dir irgendwelche infos zukommen lassen soll, sag bescheid.
T-Online- oder T-Mobile- bzw. D1-Netz-Kunde? Ich werde jedenfalls erst einmal übers Wochenende insgesamt Eure Rückmeldungen abwarten und dann nächste Woche bewerten, ob ich das Protokoll-Upgrade wieder zurückrollen muss. Wenn es bei T-Online/T-Mobile/D1 (d.h. auch Congstar etc.) häufiger zu Hängern kommt, dann ist es den möglichen Performancegewinn beim Verbindungsaufbau wohl nicht wert.

Problem beim Testen ist halt leider auch, dass da nicht alle DTAG-User gleichermaßen betroffen sein müssen. Tracerouten helfen hier leider auch nicht weiter, die benutzen i.d.R. ICMP oder zumindest TCP, außerdem sind es immer nur Momentaufnahmen. Uns bleibt wirklich nicht mehr übrig, als Euer Feedback abzuwarten. Im Zweifel müssen wir das halt alle Jahre wieder versuchen.
 
MagentaZuhause L mit 100mbit, also ja Telekom =)
(Ich war ja "damals" auch relativ stark betroffen von den Problemen mit dem routing)

Waren bisher nur sehr sporadische Hänger, die hab ich aber auch vor eurer Änderung ab und zu mal gehabt.
Noch kann ich nicht wirklich sagen, ob es sich verschlimmert hat ^^
Mal die Abendstunden und das WE abwarten.
 
Ich möchte Euch bitten, dass Ihr Euch meldet, falls Ihr vermehrt wieder längere Hänger beim Verbindungsaufbau feststellen solltet
Bin zwar hier in AT zu Hause, Nutze fonira.at vdsl aber hatte sowohl gestern als auch heute 2-3 kleinere Ladepausen bzw fehlende "Schwuppsizität" im Forum. Nix schlimmes, aber hatte ich vor der Umstellung halt nicht.
 
So - ich habe jetzt am Wochenende gerade von unterwegs im D1 Netz immer mal wieder getestet und mit pcgames.de verglichen, wo ich das Setting noch deaktiviert gelassen hatte. Möglicherweise gibt's ja doch spürbarere Effekte, wenn man zwischen Funkzellen wechselt oder vom Mobil-Netz ins WLAN bzw. zurück, aber insgesamt konnte ich nun eher nicht feststellen, dass sich das tatsächlich spürbar ausgewirkt hätte.

Dazu kommt, dass QUIC auf den Clients mehr CPU-Cycles frisst, für schwächere Mobilgeräte könnte das daher auch unter Idealbedingungen sogar etwas schlechter performen als HTTP/2. Gepaart mit dem Risiko des erhöhten Impacts von Übergabe-Congestion bzw. schlechtem Traffic-Shaping zwischen CloudFlare und der DTAG durch den Wechsel von TCP zu UDP stellt sich für mich der Vorteil von HTTP/3+QUIC im Vergleich zu HTTP/2 zumindest derzeit unzureichend dar.

Ich habe das Setting daher auch für pcgameshardware.de nun wieder deaktiviert.
 
So - ich habe jetzt am Wochenende gerade von unterwegs im D1 Netz immer mal wieder getestet und mit pcgames.de verglichen, wo ich das Setting noch deaktiviert gelassen hatte. Möglicherweise gibt's ja doch spürbarere Effekte, wenn man zwischen Funkzellen wechselt oder vom Mobil-Netz ins WLAN bzw. zurück, aber insgesamt konnte ich nun eher nicht feststellen, dass sich das tatsächlich spürbar ausgewirkt hätte.

Dazu kommt, dass QUIC auf den Clients mehr CPU-Cycles frisst, für schwächere Mobilgeräte könnte das daher auch unter Idealbedingungen sogar etwas schlechter performen als HTTP/2. Gepaart mit dem Risiko des erhöhten Impacts von Übergabe-Congestion bzw. schlechtem Traffic-Shaping zwischen CloudFlare und der DTAG durch den Wechsel von TCP zu UDP stellt sich für mich der Vorteil von HTTP/3+QUIC im Vergleich zu HTTP/2 zumindest derzeit unzureichend dar.

Ich habe das Setting daher auch für pcgameshardware.de nun wieder deaktiviert.
Schön, dass ihr das mit den Ladepausen nun auf dem Schirm habt, das geht ja schon eine ganze Weile so und die Meldungen von vor ein paar Monaten wurden nicht so ernst genommen. Ich hatte gestern auch wieder fast 10 Sekunden Ladezeit auf der Main. Scheint ein PC-Games HW exklusives Problem zu sein, das ist mir so auf noch keiner anderen Seite aufgefallen.

MfG
 
Schön, dass ihr das mit den Ladepausen nun auf dem Schirm habt, das geht ja schon eine ganze Weile so und die Meldungen von vor ein paar Monaten wurden nicht so ernst genommen. Ich hatte gestern auch wieder fast 10 Sekunden Ladezeit auf der Main. Scheint ein PC-Games HW exklusives Problem zu sein, das ist mir so auf noch keiner anderen Seite aufgefallen.

MfG
Wir haben das Problem schon lange auf dem Schirm und nehmen das auch durchaus ernst. An der Haltung der Telekom können wir allerdings nichts ändern, genausowenig können wir auf CloudFlare verzichten. Das Problem betrifft auch keineswegs ausschließlich PCGH, laut aktuellen Zahlen von W3Techs wird CloudFlare von über 80% aller Webseiten eingesetzt, die ein bekanntes CDN verwenden (Quelle: https://w3techs.com/technologies/details/cn-cloudflare). U.a. LinkedIn oder Discord nutzen ebenfalls CloudFlare.

Die Telekom versucht sehr hartnäckig, ihre vermeintliche Marktmacht zu nutzen, um zusätzlichen Umsatz von CloudFlare zu erpressen, daher wird der Netzausbau im direkten Peering zu CloudFlare aus politischen Gründen vernachlässigt. Solange sich die Telekom nicht bewegt, wird es in Spitzenzeiten leider weiterhin zu längeren Routen und damit zu inkonsistenten Aufrufzeiten kommen, auch wenn CloudFlare die alternativen Routen durch Peering-Optimierung immer weiter verbessert. Wir sind als KMU jedenfalls nicht in der Position, die Telekom oder auch CloudFlare zum Einlenken zu bewegen.
 
Wir haben das Problem schon lange auf dem Schirm und nehmen das auch durchaus ernst. An der Haltung der Telekom können wir allerdings nichts ändern, genausowenig können wir auf CloudFlare verzichten. Das Problem betrifft auch keineswegs ausschließlich PCGH, laut aktuellen Zahlen von W3Techs wird CloudFlare von über 80% aller Webseiten eingesetzt, die ein bekanntes CDN verwenden (Quelle: https://w3techs.com/technologies/details/cn-cloudflare). U.a. LinkedIn oder Discord nutzen ebenfalls CloudFlare.

Die Telekom versucht sehr hartnäckig, ihre vermeintliche Marktmacht zu nutzen, um zusätzlichen Umsatz von CloudFlare zu erpressen, daher wird der Netzausbau im direkten Peering zu CloudFlare aus politischen Gründen vernachlässigt. Solange sich die Telekom nicht bewegt, wird es in Spitzenzeiten leider weiterhin zu längeren Routen und damit zu inkonsistenten Aufrufzeiten kommen, auch wenn CloudFlare die alternativen Routen durch Peering-Optimierung immer weiter verbessert. Wir sind als KMU jedenfalls nicht in der Position, die Telekom oder auch CloudFlare zum Einlenken zu bewegen.
Ich war gestern in Polen, da hat der Seitenaufbau ca. 15 Sekunden gedauert. :ugly:

MfG
 
Zurück