Und wir haben keine Zeit mehr, wir müssen arbeiten beim Arbeitsamt.
Beiträge von tab
-
-
Dedizierte Kerne sind nur bei den RS garantiert. Bei den VPS musst du eben mit einem größeren Steal leben, weil die "echten" Cores, auf denen die vCores laufen, mit anderen Kunden geshared sind. Die Frage ist eben, ob das für deine Anwendung relevant ist. Beachte: Sowohl VPS als auch RS sind "Root-Server", weil Du einen root Zugang hast. Es ist bei netcup ziemlich verwirrend, dass es RS und VPS gibt, die aber beide Root-Server sind. Der Unterschied liegt in den dedizierten Ressourcen (vCores), die Rechenleistung eines vCores ist bei einem RS höher als bei einem VPS. Zumindest wenn sie auf der gleichen Hardware laufen. Ein vCore eines uralten RS auf Basis eines 8086
(mit welchem Prozessor hat man eigentlich bei netcup angefangen) mag trotzdem weniger Leistung haben als der vCore eines aktuellen VPS. -
Und hier solltest Du eigenlich 100% erreichen: https://internet.nl/mail/mail.elektromontagen-foerster.de
...und wenn Du den Empfehlungen von Mailcow folgst ist das relativ einfach zu erreichen
Das "mail." kann m.E. weg bei dem Test, er will ja keine Mails von irgendwer@mail.elektrodingens.de verschicken. Dann sind es immerhin schon 95% und bei den restlichen 5% ist nichts dabei, was einen erfolgreichen Mailversand verhindern würde. Da kursieren ganz andere Mails bzw Mailserver im Internet. Was nicht heißen soll, dass man das nicht noch sicherer machen sollte. Existiert denn das Problem mittlerweile überhaupt noch?
-
-
Das passt eigentlich schon alles, vielleicht hilft es noch eine Weile zu warten, vielleicht speichern die das letzte Ergebnis für eine gewisse Zeit. Sind noch andere Empfängerdomains betroffen? Wenn nicht, würde ich den Postmaster von lausitz.net nach dem Grund für die Blockierung fragen. Erscheint so ja nicht besonders professionell.
-
Ja, eine solches Online-Tool kann eine große Hilfe sein. Zuallererst kann es vielleicht klären, ob die Mail wirklich nicht verschickt wird oder ob sie "nur" durch irgendwelche falschen Einstellungen abgewiesen wird. Bei welchem Anbieter liegt denn die Empfängeradresse, die du versucht hast? Benutzt du die von netcup automatisch gesetzten DNS-Einstellungen oder hast du was geändert. Es gibt viele Möglichkeiten. Das Tool wird vermutlich jede verschickte Mail annehmen, auch wenn es sie normalerweise abweisen müsste. Das vermute ich einfach mal, weil es eben für so ein Tool Sinn macht.
Edit: Gerade nochmal gelesen, dass du nicht mal an dich selbst schicken kannst (Empfänger=Absender) Da müssen m.E. schon entweder in deinen DNS-Einträgen relativ große Fehler drin sein oder der Mailserver funktioniert gerade nicht richtig.
-
Also ist die Netzwerkverbindung Wien/Nürnberg eher nicht der Flaschenhals. Die restliche Strecke nach Frankfurt zu Google ist eh bei beiden Servern die selbe laut traceroute. Also wohl eher ein lokales Wiener Problem. Falls dem so ist und der Server sich nicht selbst durch irgendeine suboptimale Konfiguration ausbremst, wäre es wohl ein Fall für den Support. Eventuell mal im Rettungssystem testen, wird der Support wahrscheinlich eh haben wollen
. -
[...]
Die Geschwindigkeit ist mit dem Nürnberg Server zu jeder Uhrzeit doppelt so schnell im Upload zu Google.
Im Download habe ich allerdings mit dem Wien Server auch deutlich niedrigere Geschwindigkeiten, vor allem zum Cloudfront CDN, hier muss ich teilweise so viele parallele Verbindungen aufbauen, das ich I/O performance Probleme bekomme.Das heißt also, das Problem ist allgemein und nicht auf den Server von Google in Frankfurt beschränkt?!? Wie sieht es denn aus, wenn du ein Tool wie YABS auf beiden Servern (Wien/Frankfurt) laufen lässt? Ist Wien dann immer langsamer oder gibt es auch Server, zu denen Wien schneller ist. Klar, alles was in die USA geht wird wohl über Frankfurt laufen und somit wahrscheinlich langsamer sein. Aber so gen Osten könnte es eigentlich anders aussehen. Außer natürlich, das Problem liegt auf deinem Wiener Server oder KVM-Host oder dessen Netzwerkanbindung. Die Messungen von aRaphael scheinen ja eine "normale" Bandbreite zu ergeben. Was immer normal auch bedeuten mag und was genau da in dem iPerf Check getestet wird. Ich gehe mal davon aus, dass die halbe Bandbreite nicht das ist, was er unter erwartbarem Bereich versteht.

-
Die meisten Resolver werden den Algorithmus wohl implementieren, aber manche vielleicht nicht. Sie "müssen" es ja laut RFC auch nicht, es ist nur empfohlen. Also muss einem bei Verwendung dieses Algorithmus bewusst sein, dass eventuell nicht alle Resolver damit klarkommen und in der Konsequenz die Zone als unsicher betrachten. Das ist meist nicht allzu schlimm, aber man muss sich darüber zumindest Gedanken machen und sich überlegen, ob das für den konkreten Anwendungsfall ein Problem sein könnte oder nicht.
-
Ist das ein allgemeines Bandbreitenproblem des Wiener Servers zu allen Servern (auch in der Nähe von Wien oder eben nur nach Frankfurt zu Google?) Wie sieht denn das Routing von deinem Wiener Server nach Frankfurt aus? Ich habe keine Server in Wien, kann das Problem also nicht nachstellen. Vielleicht irgendwo ein Engpass dazwischen.
-
Bandbreite und Latenz sind eben völlig unterschiedliche Dinge.
-
Ich nehme mein "Erleuchteter" und tausche es gegen "professioneller Pflasterkleber"
Na, das sieht ja nach einer bestandenen Prüfung aus. Gratuliere!
-
Da ich soeben einen VPS 1000 ARM G11 SE NUE BSS24 bestellt habe und der innerhalb kurzer Zeit (3 Minuten) bereitgestellt wurde, zumindest laut CCP mit Standort Nürnberg, gehe ich mal davon aus, dass hier nochmals nachgelegt wurde.
-
Ja, genau so sieht es auch z.B. bei deSEC und meinen de-Domains aus, also die Flags und der Algorithmus.
-
Wenn ich das richtig verstehe, dann geht es im Wesentlichen um einen sauberen Umzug einer Nextcloud von Server A auf Server B.
-
Habe dann auch prompt einen VPS 1000 G11 bestellt und 3 Minuten später war er bereitgestellt. Sehr schön. Habe dann erst mal YABS drübergejagt und ihn danach sicherheitshalber heruntergefahren. Dann habe ich mal angefangen, die Ergebnisse mit meinem VPS 2000 ARM G11 zu vergleichen. Single Core scheint der ARM tatsächlich etwas weniger zu bringen, ist aber eher marginal. Aber die IO-Werte sind sehr deutlich schlechter als jetzt bei meinem neuen VPS. Oder sagen wir es mal so, sie sind anders. Bei kleinen Blockgrößen (4K) sind sie sogar deutlich besser, aber bei großen Blockgrößen um ca Faktor 7 schlechter. Die Werte beim VPS von heute bei 1M Blockgröße sind in etwa so wie bei einem RS G9.5 (Read 3.65 GB/s, Write 3.90 GB/s) . Naja, morgen, nachdem die Technik das gelesen hat, vielleicht nicht mehr
.Gerade vergleiche ich mit meinem VPS ARM 2000, IO ist schon durch, bei 1M Read: 382 MB/s Write: 426MB/s. Oh lala! Da sind schon Welten dazwischen, die Frage ist nur warum? Ich hätte jetzt eher erwartet, dass alle VPS mehr oder weniger gleich sind bei den IO-Werten - zumindest die G11 - und die RS vielleicht etwas besser. Aber da habe ich mich dann wohl getäuscht. Das ist ja schon ein großer Unterschied
Lange Rede, kurzer Sinn: Mit diesen Testergebnissen des neuen VPS bin ich erst einmal sehr zufrieden, hatte ich so nicht erwartet. Muss man mal schauen, wie sehr sie sich im Lauf der Zeit verschlechtern.
-
Immerhin. Das letzte Mal habe ich den Newsletter eine halbe Stunde nach Ende der Aktion erhalten.

So, da der Newsletter so spät kam muss ich mich jetzt ranhalten
. -
Wow, hat die Aktion schon angefangen? Gerade wurde mir der Newsletter zugestellt.
-
Einmalig natürlich! Dafür steht er dann aber auch nur einmalig zur Verfügung.
-
Dass beide für eine Nextcloud reichen bezweifle ich sicher nicht. Mich würde hauptsächlich interessieren, was die Cores so leisten. Sind die beim "normalen" VPS wesentlich schneller als die bei der ARM-Variante? Gerade wenn sie wenig zu tun haben sollten das wenige dann zumindest schnell erledigt werden. Ob dann 3 oder 5 vCores idle sind ist nicht so entscheidend
. I/O dürfte bei beiden ähnlich gedeckelt sein!?