die Latenzen zwischen Wien und Nürnberg (rund 450-500 km) sind nicht höher als zwischen Linz und Wien (nur rund 150-175 km)
aber so wie das aussieht kommst Du unter 7 ms nicht aus der haustür. das ist halt der fluch von DOCSIS.
Beiträge von hoedlmoser
-
-
Selbstverständlich wird der Test nicht in jedem der 5min-Intervalle ausgeführt.
Du schlawiner.
-
routet dein provider IPv4 von Linz nach Nürnberg nicht über Wien?
ja tut er
wo soll dann die überraschung bzgl IPv6 sein? Dein provider routet IPv4 über Wien, ebenso machst Du es mit IPv6 über Deinen eigene 6in4-proxy. die pingzeiten sind ja auch gleich, was in dieser konstellation zu erwarten ist.
-
bei ping6 gibts Überraschungen
routet dein provider IPv4 von Linz nach Nürnberg nicht über Wien?
-
Du willst 'tcp throughput calculator' googeln?!
im endeffekt von RTT, MSS und TCP Window Size, ...
-
und ich dachte schon ein G9.5 auf dem Du alleine bist.
-
net schlecht. was ist denn das für einer?
-
Ich denke mal, bei einem upgrade bleibt der Serverstandort erhalten.
das stand ja auch so in den FAQs zum RS G9.5. aber ich war überrascht, daß ich von einem G9 VIE auf einen standortlosen G9.5 upgraden kann. und selbst jetzt nach diesem upgrade kann ich auf VIE- und standortlosen-tarif upgraden.
das würde aber in weiterer folge bedeuten, daß man sich einfach einen RS am gewünschten standort in einer kleineren ausführung bestellt und dann auf die nächsthöhere ausstattung im standortlosen tarif upgraden kann. hm?
am "um" erkennt man den Österreicher
das ist nicht das einzige erkennungsmerkmal von Österreichern.
-
korrekt, um 61 €cent (AT MwSt
) gabs upgrade von zwei auf vier kerne und der server verblieb in VIE. -
huch^2, ich konnte gerade meinen 'RS 1000 G9 a1 VIE 12M' auf den standortlosen 'RS 1000 G9.5 a1 12M' upgraden.
-
Gemessen mit den Parameter von m_ueberall
huch, da hat sich allgemein etwas getan an der performance. ich bin sehr positiv überrascht. mehr performance ohne einen G-.5-upgrade.
VPS 200 G8
vorher: read: IOPS=3214, BW=12.6MiB/s (13.2MB/s), write: IOPS=1074, BW=4298KiB/s (4401kB/s)
nachher: read: IOPS=13.0k, BW=50.9MiB/s (53.4MB/s), write: IOPS=4357, BW=17.0MiB/s (17.8MB/s)
RS 1000 G9 a1 VIE 12M
vorher: read: IOPS=20.4k, BW=79.6MiB/s (83.5MB/s), write: IOPS=6812, BW=26.6MiB/s (27.9MB/s)
nachher: read: IOPS=52.7k, BW=206MiB/s (216MB/s), write: IOPS=17.6k, BW=68.9MiB/s (72.2MB/s)
das ist mehr als ein faktor zwei! entweder hat netcup hier massiv hardware nachgeschmissen und die RS jetzt neuverteilt (brauchen sie dazu diesen neue-KVM-version-restart?) oder limits geändert oder wirklich noch einen parameter gefunden oder ...
ich denke der m_ueberall sollte in sein 'VServer IOPS Comparison Sheet' ein datum der messung einfügen.
-
Mein RS 2000 WSV22 bringt hier aber nur ca 40 MB/s read und ca 15 MB/s write.
deckt sich mit meinen messungen in Nürnberg.
also ich bleib in Wien.
-
das beantwortet die eigentlich Frage aber nicht;
darum sagte ich ja der Aluhut ist auf Deiner Seite
ich blockier kein ICMP.
-
erklär mir, wie so ein Paket zu mir kommen kann, ohne,
dass es das Ergebnis eines zuvor versendeten Paketes ist?
die manpage von iptables und dem status related ist da eindeutig:
ZitatRELATED The packet is starting a new connection, but is associated with
an existing connection, such as an FTP data transfer or an ICMP
error.
-
deswegen ...
aluhut. dann viel spaß mit zb Fragmentation Needed (IPv4) / Packet Too Big (IPv6).
aber wer sein heil in einer accept policy findet, dem ist eh nicht mehr zu helfen.
-
wenn ich hier an Stelle ACCEPT aber DROP nehme, dann bricht die Leitung ein
entgegen der von mir oben verlinkten und zitierten antwort von serverfault muß ich mich korrigieren, DROP verwirft das packerl gänzlich, da antwortet der server mit genau nix!
warum bei Dir im gegenständlichen fall die leitung einbricht wenn der server die packerle verwirft erklärt sich mir nicht, kann aber wahrscheinlich nur in zusammenhang mit Deinem router gesehen werden.
hier seien meine ergebnisse bzgl iptables mit drop und reject zusammengefasst:
client versucht sich am server auf port 23 via TCP zu verbinden, dort lauscht aber kein daemon
- in einem jungfräulichen zustand (policy accept und keine rules) meldet der client ein 'Connection refused', im tcpdump sieht man einen reset und nmap meldet den port als closed.
- mit der policy drop braucht der client 2 minuten und 10 sekunden um ein 'Connection timed out' zu melden, im tcpdump sieht man nur wiederholte syns des client, nmap sieht den port nach knapp 2 sekunden scan als filtered.
- mit einer expliziten reject rule meldet der client ein 'Connection refused', im tcpdump sieht man einen 'ICMP tcp port unreachable' und nmap meldet den port als filtered.
- mit einer tcp reset reject rule meldet der client ein 'Connection refused', im tcpdump sieht man einen reset und nmap meldet den port als closed.
ein interessanter artikel bzgl DROP vs REJECT sei auch noch erwähnt http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject er kommt zu dem konklusio, daß man DROP aus clientsicht wegen timeouts vermeiden möchte.
offensichtlich das einzig Richtige ...
offensichtlich keine ahnung. oder hast Du am ende Deines regelwerks noch eine catch-all reject rule?
wenn ich die paar Ports welche ich von bestimmten Quellen offen brauch,
mit einer 2ten Regel
[...]
terminiere
Du weißt aber schon, daß der erste match greift?! da kannst Du danach rejecten was Du willst.
All 1024 scanned ports on #DNS (#IP) are closed
aus meinen empirischen tests von oben leite ich mal ab, daß nmap dann einen port als closed meldet, wenn mit einem RST geantwortet worden ist. das heißt aber in weiterer folge, daß Du die packerle nicht dropst. sondern entweder in iptables mit einem 'REJECT --reject-with tcp-reset' oder Dein betrübssystem einen TCP RST raus haut.
einzig gewußt hätt ich, wie ich das 'Host is up' auf 'Host is down' hier bring; ICMP wird gedropp'd
wozu dropped man ICMP? ist das schon wieder so ein 'security by obscurity' ding?
und wenn Du das wirklich auf down haben willst, dann könnte man das in der man page von nmap nachlesen, ich hab das mal für Dich getan.
ZitatIf no host discovery options are given, Nmap sends an ICMP echo request, a TCP SYN packet to port 443, a TCP ACK packet to port 80, and an ICMP timestamp request.
-
warum bricht meine Leitung ein, wenn ich alles mit DROP terminiere, und nichts antworte?
man findet auch einiges zum Thema DROP vs. REJECT
ich hab es bis jetzt mit der Default-Regel DROP
die Default Policy von DROP auf ACCEPT geändert
was jetzt? drop, reject oder accept?
wir reden hier schon von der default-policy, ja? könnt noch immer sein, daß Du als letzte rule eine catch-all drinnen hast die dann anders als die default-policy "abweist".
und die default-policy ingres auf accept zu stellen ist imho keine gute idee!
unabhängig davon was Du eingestellt hast, es steht alles in der von mir verlinkten antwort.
CodeWhen using DROP rules: - UDP packets will be dropped and the behavior will be the same as connecting to an unfirewalled port with no service. - TCP packets will return an ACK/RST which is the same response that an open port with no service on it will respond with. Some routers will respond with and ACK/RST on behalf of servers which are down. When using REJECT rules an ICMP packet is sent indicating the port is unavailable. -
man findet auch einiges zum Thema DROP vs. REJECT
die Frage die ich mir stelle - wahrscheinlich macht es einen Unterschied ob UDP od. TCP - wie
'schont' das die Resourcen ...
ich hab das mal für Dich gegoogelt: https://serverfault.com/a/157418
fetten Anbindung mit 200 MBit/20 MBit
das nennst Du fett? wenn da ein portscan mit 200 MBit/s auf Dich hereinprasselt und Du alles brav mit TCP/RST beantwortest hab ich in null komma nix Deinen uplink zugemacht.
-
Das verlagert die Arbeit darauf, dieses Kochrezept zu schreiben.
die werden hier in ansible geschrieben, damit ziehe ich den host und die container hoch.
-
es gibt nicht so viele fertige Container, die man einfach spawnen kann
genau das will ich gar nicht. ich will hier nicht einen zb zoo von mysql servern, nur weil jeder container glaubt er müsse seinen eigenen mithaben.
ZT selbst läuft dafür in einem Host Network Container. [...] Ich route bislang gar nix.
macht dann dieser Network Container NAT? oder wie weiß ein anderer container wo er die rückantworten hin schicken soll? oder ist da der host eh default gateway und kanns dann zum ZT container richtig routen?
