Het blijft iemand anders zijn pc hé:
Vorige week om wat te oefenen met traefik e.d. even de VPS S (5,-) bij Contabo gehuurd. Wil ik nu verder klooien kan ik mijn VPS niet bereiken.
https://contabo-status.com geeft aan:
[...]
Begint goed!
Ik mag niet klagen, maar binnen een week na afname is wel snel. Het is maar een test bakje gelukkig.:
[...]
Het blijft iemand anders zijn pc hé
En 5 euri's, tja
Heb ik nog niet meegemaakt bij Hetzner. En die zijn ook behoorlijk goedkoop al zeg ik het zelf.:
[...]
Het blijft iemand anders zijn pc hé
En 5 euri's, tja
De instap vps voor windows werkt gewoon niet, een type hoger werkt maar bij elke klik van je muis moet je 5 seconden wachten voordat je iets ziet gebeurren op je scherm.:
[...]
Wil je er wat over vertellen? Wellicht nuttige informatie om me te behoeden van een misstap
Meermaals met support contact gehad, een keer zelfs verplaatst naar een andere host. Exact dezelfde hardware.Ongevraagde verzoeken per DM beantwoord ik niet, sorry
Dat is wel erg nuttige informatie. Zou je die vriend van je kunnen verleiden om een bench te draaien en die hier te posten? Dan kunnen we 'm vergelijken met bovenstaande posts.:
Een goede vriend heeft een VPS bij Contabo. Voor iets meer dan een tientje geeft dat 6 cores, 16G RAM en 400G "SSD" opslag.
Klinkt leuk en en aardig, maar ding is niet vooruit te branden. Wellicht doordat er een eerste generatie i7 CPU achter zit
Pay peanuts, get monkeys.
[ Voor 5% gewijzigd door roedi06 op 28-12-2022 12:23 . Reden: typo ]
Kan en mag dit zelf uitvoeren
Ik heb mij vergist, VPS heeft iets andere specs, maar alsnog voor iets meer dan een tientje per maand.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
| -------------------------------------------------
nench.sh v2019.07.20 -- https://git.io/nench.sh
benchmark timestamp: 2022-12-28 11:51:58 UTC
-------------------------------------------------
Processor: Intel Core i7 9xx (Nehalem Class Core i7)
CPU cores: 4
Frequency: 2399.996 MHz
RAM: 9.8G
Swap: -
Kernel: Linux 4.15.0-39-generic x86_64
Disks:
vda 700G HDD
CPU: SHA256-hashing 500 MB
3.353 seconds
CPU: bzip2-compressing 500 MB
5.872 seconds
CPU: AES-encrypting 500 MB
3.428 seconds
ioping: seek rate
min/avg/max/mdev = 39.6 us / 64.2 us / 14.0 ms / 93.3 us
ioping: sequential read speed
generated 26.7 k requests in 5.00 s, 6.51 GiB, 5.33 k iops, 1.30 GiB/s
dd: sequential write speed
1st run: 91.55 MiB/s
2nd run: 86.21 MiB/s
3rd run: 92.41 MiB/s
average: 90.06 MiB/s
IPv4 speedtests
your IPv4: 213.136.87.xxxx
Cachefly CDN: 11.90 MiB/s
Leaseweb (NL): 7.61 MiB/s
Softlayer DAL (US): 0.00 MiB/s
Online.net (FR): 11.73 MiB/s
OVH BHS (CA): 10.61 MiB/s
No IPv6 connectivity detected
------------------------------------------------- |
[ Voor 9% gewijzigd door jurroen op 28-12-2022 12:59 ]
Ongevraagde verzoeken per DM beantwoord ik niet, sorry
Wel vreemd dat er dan na de verplaatsing gebruik wordt gemaakt van de i7 CPU's, zo te zien zijn het ook maar 4 cores die kunnen worden gebruikt. Op de site van Contabo zeggen ze dat ze de AMD EPYC 7282 processor gebruiken, dus wel vreemd dat ze jullie daar niet op hebben gezet.:
[...]
Kan en mag dit zelf uitvoeren
code:
------------------------------------------------- nench.sh v2019.07.20 -- https://git.io/nench.sh benchmark timestamp: 2022-12-28 11:51:58 UTC ------------------------------------------------- Processor: Intel Core i7 9xx (Nehalem Class Core i7) CPU cores: 4 Frequency: 2399.996 MHz RAM: 9.8G Swap: - Kernel: Linux 4.15.0-39-generic x86_64 Disks: vda 700G HDD CPU: SHA256-hashing 500 MB 3.353 seconds CPU: bzip2-compressing 500 MB 5.872 seconds CPU: AES-encrypting 500 MB 3.428 seconds ioping: seek rate min/avg/max/mdev = 39.6 us / 64.2 us / 14.0 ms / 93.3 us ioping: sequential read speed generated 26.7 k requests in 5.00 s, 6.51 GiB, 5.33 k iops, 1.30 GiB/s dd: sequential write speed 1st run: 91.55 MiB/s 2nd run: 86.21 MiB/s 3rd run: 92.41 MiB/s average: 90.06 MiB/s IPv4 speedtests your IPv4: 213.136.87.xxxx Cachefly CDN: 11.90 MiB/s Leaseweb (NL): 7.61 MiB/s Softlayer DAL (US): 0.00 MiB/s Online.net (FR): 11.73 MiB/s OVH BHS (CA): 10.61 MiB/s No IPv6 connectivity detected -------------------------------------------------
Deze is ongeveer twee maanden geleden verplaatst naar een nieuwe host in de hoop om de latency wat werkbaarder te krijgen. Maar helaas. En echt opgelost hoeft het niet te worden; deze VPS wordt langzaam uitgefaseerd en heeft nooit iets kritisch gedraaid, Dat laatste zou ik persoonlijk ook nooit doen bij Contabo.
1
2
3
4
5
6
| CPU: SHA256-hashing 500 MB
3.353 seconds
CPU: bzip2-compressing 500 MB
5.872 seconds
CPU: AES-encrypting 500 MB
3.428 seconds |
1
2
3
4
5
6
| CPU: SHA256-hashing 500 MB
3.525 seconds
CPU: bzip2-compressing 500 MB
6.335 seconds
CPU: AES-encrypting 500 MB
2.189 seconds |
1
2
3
4
5
6
| CPU: SHA256-hashing 500 MB
3.271 seconds
CPU: bzip2-compressing 500 MB
5.226 seconds
CPU: AES-encrypting 500 MB
1.219 seconds |
1
2
3
4
5
6
| CPU: SHA256-hashing 500 MB
2,650 seconds
CPU: bzip2-compressing 500 MB
5,137 seconds
CPU: AES-encrypting 500 MB
1,028 seconds |
1
2
3
4
5
6
| CPU: SHA256-hashing 500 MB
2.280 seconds
CPU: bzip2-compressing 500 MB
6.161 seconds
CPU: AES-encrypting 500 MB
0.887 seconds |
dus die vergelijking hierboven is wel interessant voor CPU-power vergelijken, maar niet voor jouw probleem. My bad.
[ Voor 10% gewijzigd door roedi06 op 28-12-2022 13:14 . Reden: strato, herzner toegevoegd ]
kijkende is dit wel een handig tabelletje, gemaakt uit voorgaande posts.| Strato | Herzner | Time4vps | Contabo | Contabo | |
| CPU | AMD EPYC 7452 32-Core Processor | AMD EPYC 7763 64-Core Processor | Intel Xeon Gold 6132 | AMD EPYC 7282 16-Core Processor | Intel Core i7 9xx (Nehalem Class Core i7 |
| SHA256-hashing 500 MB (s) | 2.650 | 2.280 | 3.271 | 3.525 | 3.353 |
| bzip2-compressing 500 MB (s) | 5.137 | 6.161 | 5.226 | 6.335 | 5.872 |
| AES-encrypting 500 MB (s) | 1.028 | 0.887 | 1.219 | 2.189 | 3.528 |
| Totaal (s) | 8.815 | 9.328 | 9.716 | 12.049 | 12.753 |
Erg goed idee als het script wat kan worden uitgebreid, zat zelf ook al in de code te kijken. Wat ideeen die in mij opkwamen om evt. toe te voegen:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| user@usermachine:~/# 7za b
7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=C.UTF-8,Utf16=on,HugeFiles=on,64 bits,8 CPUs 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz (806C1),ASM,AES-NI)
11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz (806C1)
CPU Freq: - - - - - - - - -
RAM size: 3807 MB, # CPU hardware threads: 8
RAM usage: 1765 MB, # Benchmark threads: 8
Compressing | Decompressing
Dict Speed Usage R/U Rating | Speed Usage R/U Rating
KiB/s % MIPS MIPS | KiB/s % MIPS MIPS
22: 24515 700 3408 23848 | 256345 782 2795 21865
23: 25080 725 3524 25554 | 239862 768 2703 20757
24: 23228 743 3363 24975 | 228466 770 2603 20052
25: 21991 750 3348 25109 | 216918 764 2526 19305
---------------------------------- | ------------------------------
Avr: 729 3411 24872 | 771 2657 20495
Tot: 750 3034 22683 |
Volgens mij ben ik meer op de CPU gefocussed, en jij op de latency. Mooie combo volgens mij. Het zijn twee bepalende factoren die je vooraf niet weet op basis van de specs.
Wel begrijpelijk dat je 'm zo lean mogelijk wilt houden.
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/kqWvXC9Z1yfp14Ma4gVGhXD1.jpg?f=user_large)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
| # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
# Yet-Another-Bench-Script #
# v2022-12-29 #
# https://github.com/masonr/yet-another-bench-script #
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
Mon 20 Feb 2023 05:27:10 PM CET
Basic System Information:
---------------------------------
Uptime : 5 days, 19 hours, 12 minutes
Processor : AMD EPYC 7282 16-Core Processor
CPU cores : 4 @ 2800.000 MHz
AES-NI : ✔ Enabled
VM-x/AMD-V : ❌ Disabled
RAM : 7.8 GiB
Swap : 0.0 KiB
Disk : 392.6 GiB
Distro : Debian GNU/Linux 11 (bullseye)
Kernel : 5.10.0-21-amd64
fio Disk Speed Tests (Mixed R/W 50/50):
---------------------------------
Block Size | 4k (IOPS) | 64k (IOPS)
------ | --- ---- | ---- ----
Read | 5.28 MB/s (1.3k) | 64.57 MB/s (1.0k)
Write | 5.30 MB/s (1.3k) | 65.00 MB/s (1.0k)
Total | 10.59 MB/s (2.6k) | 129.57 MB/s (2.0k)
| |
Block Size | 512k (IOPS) | 1m (IOPS)
------ | --- ---- | ---- ----
Read | 127.68 MB/s (249) | 99.30 MB/s (96)
Write | 134.47 MB/s (262) | 105.92 MB/s (103)
Total | 262.15 MB/s (511) | 205.23 MB/s (199)
iperf3 Network Speed Tests (IPv4):
---------------------------------
Provider | Location (Link) | Send Speed | Recv Speed | Ping
----- | ----- | ---- | ---- | ----
Clouvider | London, UK (10G) | 144 Mbits/sec | 142 Mbits/sec | 14.3 ms
Scaleway | Paris, FR (10G) | busy | 128 Mbits/sec | 19.8 ms
NovoServe | North Holland, NL (40G) | 139 Mbits/sec | 170 Mbits/sec | 6.94 ms
Uztelecom | Tashkent, UZ (10G) | 150 Mbits/sec | 128 Mbits/sec | 103 ms
Clouvider | NYC, NY, US (10G) | busy | busy | 83.1 ms
Clouvider | Dallas, TX, US (10G) | 85.8 Mbits/sec | busy | 134 ms
Clouvider | Los Angeles, CA, US (10G) | 42.3 Mbits/sec | 90.5 Mbits/sec | 163 ms
iperf3 Network Speed Tests (IPv6):
---------------------------------
Provider | Location (Link) | Send Speed | Recv Speed | Ping
----- | ----- | ---- | ---- | ----
Clouvider | London, UK (10G) | 146 Mbits/sec | 150 Mbits/sec | 29.6 ms
Scaleway | Paris, FR (10G) | busy | busy | 17.0 ms
NovoServe | North Holland, NL (40G) | 129 Mbits/sec | 165 Mbits/sec | 10.8 ms
Uztelecom | Tashkent, UZ (10G) | 106 Mbits/sec | 93.2 Mbits/sec | 112 ms
Clouvider | NYC, NY, US (10G) | 116 Mbits/sec | 90.9 Mbits/sec | 84.9 ms
Clouvider | Dallas, TX, US (10G) | 104 Mbits/sec | 101 Mbits/sec | 127 ms
Clouvider | Los Angeles, CA, US (10G) | 98.4 Mbits/sec | 71.5 Mbits/sec | 158 ms
Geekbench 5 Benchmark Test:
---------------------------------
Test | Value
|
Single Core | 390
Multi Core | 708
Full Test | https://browser.geekbench.com/v5/cpu/20695806 |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
| # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
# Yet-Another-Bench-Script #
# v2022-12-29 #
# https://github.com/masonr/yet-another-bench-script #
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
Mon 20 Feb 2023 04:28:12 PM UTC
Basic System Information:
---------------------------------
Uptime : 5 days, 2 hours, 48 minutes
Processor : AMD EPYC Processor
CPU cores : 2 @ 2445.406 MHz
AES-NI : ✔ Enabled
VM-x/AMD-V : ❌ Disabled
RAM : 1.9 GiB
Swap : 8.0 GiB
Disk : 57.0 GiB
Distro : Debian GNU/Linux 11 (bullseye)
Kernel : 5.10.0-20-amd64
fio Disk Speed Tests (Mixed R/W 50/50):
---------------------------------
Block Size | 4k (IOPS) | 64k (IOPS)
------ | --- ---- | ---- ----
Read | 38.42 MB/s (9.6k) | 1.05 GB/s (16.5k)
Write | 38.49 MB/s (9.6k) | 1.06 GB/s (16.6k)
Total | 76.91 MB/s (19.2k) | 2.12 GB/s (33.1k)
| |
Block Size | 512k (IOPS) | 1m (IOPS)
------ | --- ---- | ---- ----
Read | 1.01 GB/s (1.9k) | 1.32 GB/s (1.2k)
Write | 1.07 GB/s (2.0k) | 1.41 GB/s (1.3k)
Total | 2.08 GB/s (4.0k) | 2.74 GB/s (2.6k)
iperf3 Network Speed Tests (IPv4):
---------------------------------
Provider | Location (Link) | Send Speed | Recv Speed | Ping
----- | ----- | ---- | ---- | ----
Clouvider | London, UK (10G) | 4.97 Gbits/sec | 7.73 Gbits/sec | 21.7 ms
Scaleway | Paris, FR (10G) | busy | 7.96 Gbits/sec | 13.6 ms
NovoServe | North Holland, NL (40G) | 7.46 Gbits/sec | 10.2 Gbits/sec | 10.1 ms
Uztelecom | Tashkent, UZ (10G) | 1.23 Gbits/sec | 2.09 Gbits/sec | 100 ms
Clouvider | NYC, NY, US (10G) | 1.51 Gbits/sec | 2.22 Gbits/sec | 89.5 ms
Clouvider | Dallas, TX, US (10G) | 1.27 Gbits/sec | 1.53 Gbits/sec | 123 ms
Clouvider | Los Angeles, CA, US (10G) | busy | 690 Mbits/sec | 146 ms
iperf3 Network Speed Tests (IPv6):
---------------------------------
Provider | Location (Link) | Send Speed | Recv Speed | Ping
----- | ----- | ---- | ---- | ----
Clouvider | London, UK (10G) | 4.08 Gbits/sec | 3.25 Gbits/sec | 21.7 ms
Scaleway | Paris, FR (10G) | busy | busy | 13.6 ms
NovoServe | North Holland, NL (40G) | 7.34 Gbits/sec | 10.5 Gbits/sec | 10.0 ms
Uztelecom | Tashkent, UZ (10G) | busy | busy | 96.9 ms
Clouvider | NYC, NY, US (10G) | 1.58 Gbits/sec | 2.11 Gbits/sec | 89.2 ms
Clouvider | Dallas, TX, US (10G) | busy | 1.50 Gbits/sec | 123 ms
Clouvider | Los Angeles, CA, US (10G) | 1.10 Gbits/sec | 624 Mbits/sec | 146 ms
Geekbench 5 Benchmark Test:
---------------------------------
Test | Value
|
Single Core | 881
Multi Core | 1344
Full Test | https://browser.geekbench.com/v5/cpu/20695769 |
Ja ik draai al ruim een jaar een paar websites met de gratis Oracle. Downtime is er bijna nooit en de VPS is erg snel. Ik maak wel elke dag backups mocht ik ooit geblokkeerd worden door Oracle (die verhalen lees ik wel vaak op Reddit). Mocht dat het geval zijn ben ik in tien minuten over op Hetzner.:
Ben nu een maandje aan het spelen met diversen VPS-en o.a hetzner en deze bevalt erg goed, ware het niet dat ze op dit moment een grote storing hebben
(schijnt een ddos aanval te zijn niet echt een storing maar mijn vps en de console is onbereikbaar).
Ik heb dit topic een beetje doorgenomen en zie eigenlijk nergens oracle voorbij komen.
Heb nu een maandje een gratis VPS draaien op oracle en werkt eigenlijk prima.
Heb een ARM 3 cores en 8 GB ram en 200GB opslag.
Je moet wel geluk hebben om er door te komen je kan gratis tot 4 cores 24GB ram en 200GB opslag gaan maar als je het een beetje terugschroeft kom je er sneller door, vandaar mijn gekke config.
Meer mensen hier ervaring met oracle?
Ik lees op de status pagina dat er inderdaad een probleem is met de account console. Of dit een DDoS is zou ik niet weten. Dat wordt niet gezegd.:
Ben nu een maandje aan het spelen met diversen VPS-en o.a hetzner en deze bevalt erg goed, ware het niet dat ze op dit moment een grote storing hebben
(schijnt een ddos aanval te zijn niet echt een storing maar mijn vps en de console is onbereikbaar).
Hier heb ik geen ervaring mee. En eerlijk gezegd kan ik het me amper voorstellen dat een grote naam als Oracle gratis VPS'en weggeeft. Zeker met die specificaties. Dus wat is het addertje?
Ik denk dat het toevallig was dat mijn vps even niet bereikbaar was, was wel bezig met wat docker containers en de server load was ineens erg hoog.
Er zijn wel meer grote namen die beperkte gratis vps weggeven maar meestal niet zulke hoge specs.
)Volgens mij gewoon kwestie van even een cloud shell sessie starten en klaar.
Lees vooral even hier: Idle Compute Instances.:
Iemand hier die gebruik maken van een oracle free tier VPS ?
Ik heb al ongeveer een jaar een free tier draaien ARM 3 cores en 8 Gb RAM en 200GB disk. (rare config maar dat was wat ik erdoor kreeg toen
Krijg nu alleen de onderstaande mail.
[...]
Volgens mij gewoon kwestie van even een cloud shell sessie starten en klaar.
Een tool met de naam stress-ng. Mijn instance heeft 4 arm cores en 24GB geheugen en ik laat stress-ng vrijwel continu 1 core op 100% draaien en een groot deel van het geheugen verbruiken. Doe ik dat niet dan krijg ik waarschuwingen van Oracle dat mijn instance verwijderd zal worden. Sinds ik deze tool gebruik heb ik geen last meer van waarschuwingen.
[ Voor 49% gewijzigd door 3raser op 23-08-2024 09:39 . Reden: Regels met uitleg toegevoegd ]
Linkje? Ik zie hier alleen de CX32 voor max €8,23 en bij ARM de CA21 voor max €7,85. Of mis ik ergens een "betalen per maand" (i.p.v. per uur met een max tarief per maand) optie?
Heb je ook gelijk in. Het is ook niet perse een "ik wil weg". Maar ik wil wel even opnieuw kijken hoe groen het gras bij de buren nu is
. Contabo ben ik verschillende jaren terug voornamelijk heen gegaan omdat het ultra cheap was. Als ik nu naar 4 cores & 8GB voor €6,60 ga dan bieden concurrenten dus hetzelfde (evt meer hier en daar) voor een vergelijkbare prijs. En Contabo zie ik ook wel eens negatief langs komen (plotsklaps server afsluiten / verwijderen bv). Maar ook geen idee hoe dat bij de concurrentie zit. Maar bv Reddit op Contabo is het wel eens "tsja, Contabo, wat verwacht je ook?" en wel altijd positieve reacties over dus bv Hetzner of Netcup..
Sorry, ik zat naar ex. BTW prijzen te kijken.
Als je het Hetzner topic door leest zijn ook niet alle reacties lovend. Vooral het inschrijven geeft nogal wat problemen. Je eigen ervaring is volgens mij altijd de belangrijkste. Al vind iedereen de dienst niks en jij vind het prima, wat is dan het probleem.[...]
Heb je ook gelijk in. Het is ook niet perse een "ik wil weg". Maar ik wil wel even opnieuw kijken hoe groen het gras bij de buren nu is
En uiteindelijk is het ook voornamelijk hobby. Als het wat uurtjes kost om op te zetten heb ik ook wat langer kunnen hobbyen
/u/35508/crop61e6aa7b579e2_cropped.png?f=community)
:strip_icc():strip_exif()/u/485368/crop56fb87f6373c9_cropped.jpeg?f=community)
/u/263454/wie%2520dit%2520leest%2520is%2520gek.png?f=community)
:strip_icc():strip_exif()/u/46311/crop67969c002c0ce_cropped.jpg?f=community)
/u/63360/cyberjack_avatar.png?f=community){kind=avatar}
/u/604550/crop5616bb6cb8e0c_cropped.png?f=community)
:strip_icc():strip_exif()/u/457808/crop5686a95ab9c87_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/458263/crop57c47684e8777_cropped.jpeg?f=community)
/u/615926/crop60fd7652c3b18_cropped.png?f=community)
:strip_icc():strip_exif()/u/71319/crop63827a2053b9b_cropped.jpg?f=community)
:strip_icc():strip_exif()/u/101865/crop5e04c97889698_cropped.jpeg?f=community)
-------------------------------------------------
nench.sh v2019.07.20 -- https://git.io/nench.sh
benchmark timestamp: 2025-02-06 08:14:23 UTC
-------------------------------------------------
Processor: AMD EPYC 7282 16-Core Processor
CPU cores: 4
Frequency: 2794.748 MHz
RAM: 7.8Gi
bash: line 156: swapon: command not found
Swap: -
Kernel: Linux 6.1.0-29-amd64 x86_64
Disks:
sda 50G SSD
CPU: SHA256-hashing 500 MB
13.150 seconds
CPU: bzip2-compressing 500 MB
16.084 seconds
CPU: AES-encrypting 500 MB
5.160 seconds
ioping: seek rate
min/avg/max/mdev = 1.66 us / 4.01 us / 8.45 ms / 30.3 us
ioping: sequential read speed
generated 108.4 k requests in 5.00 s, 26.5 GiB, 21.7 k iops, 5.29 GiB/s
dd: sequential write speed
1st run: 331.88 MiB/s
2nd run: 242.23 MiB/s
3rd run: 247.00 MiB/s
average: 273.70 MiB/s
IPv4 speedtests
your IPv4: 31.220.73.xxxx
Cachefly CDN: 20.12 MiB/s
Leaseweb (NL): 0.42 MiB/s
Softlayer DAL (US): 0.00 MiB/s
Online.net (FR): 21.56 MiB/s
OVH BHS (CA): 3.63 MiB/s
IPv6 speedtests
your IPv6: 2a02:c206:2150:xxxx
Leaseweb (NL): 0.29 MiB/s
Softlayer DAL (US): 0.00 MiB/s
Online.net (FR): 20.41 MiB/s
OVH BHS (CA): 3.60 MiB/s
-------------------------------------------------
Terwijl ik nu "zogenaamd" NVME heb.
Maarja, da's het blijkbaar niet waard dus.[ Voor 8% gewijzigd door RobertMe op 23-02-2025 22:18 ]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
| -------------------------------------------------
nench.sh v2019.07.20 -- https://git.io/nench.sh
benchmark timestamp: 2025-03-02 11:16:35 UTC
-------------------------------------------------
Processor: AMD EPYC 9634 84-Core Processor
CPU cores: 8
Frequency: 2246.624 MHz
RAM: 15Gi
Swap: -
Kernel: Linux 5.14.0-427.42.1.el9_4.x86_64 x86_64
Disks:
vda 512G HDD
CPU: SHA256-hashing 500 MB
0.420 seconds
CPU: bzip2-compressing 500 MB
3.723 seconds
CPU: AES-encrypting 500 MB
0.937 seconds
ioping: seek rate
min/avg/max/mdev = 41.5 us / 134.7 us / 812.8 us / 32.9 us
ioping: sequential read speed
generated 7.46 k requests in 5.00 s, 1.82 GiB, 1.49 k iops, 372.8 MiB/s
dd: sequential write speed
1st run: 633.24 MiB/s
2nd run: 656.13 MiB/s
3rd run: 649.45 MiB/s
average: 646.27 MiB/s
IPv4 speedtests
your IPv4: 89.58.40.xxxx
Cachefly CDN: 259.74 MiB/s
Leaseweb (NL): 0.47 MiB/s
Softlayer DAL (US): 0.00 MiB/s
Online.net (FR): 142.55 MiB/s
OVH BHS (CA): 25.28 MiB/s
IPv6 speedtests
your IPv6: 2a03:4000:66:xxxx
Leaseweb (NL): 0.31 MiB/s
Softlayer DAL (US): 0.00 MiB/s
Online.net (FR): 145.16 MiB/s
OVH BHS (CA): 26.57 MiB/s
------------------------------------------------- |
:no_upscale():strip_icc():strip_exif()/f/image/s9tDnboVHUkGjM0QMDRdDIPA.jpg?f=user_large)
Korte update::
Na een dagje prutsen begin ik te neigen naar een cancellation binnen 14 dagen bedenktijd
Intussen weer een goede twee weken verder. Contact is "dood gebloed" met van hun kant als laatste een "het is doorgezet naar de netwerk afdeling". Dat ik iperf heb opgezet (thuis en op Contabo VPS) is dus verder geen reactie meer op gekomen behalve dan dat het was doorgezet. Vervolgens heb ik wel nog 1 of 2 mails gestuurd, o.a. dat mijn thuis IP (gek genoeg) veranderd was (gebeurt echt "nooit", maar blijkbaar nu wel) en dus het nieuwe IP doorgegeven, en had modem reboot gedaan waardoor ook de Ziggo snelheidsupdate was doorgevoerd van 200 down naar 250 dus dat ook maar er bij gezet. Dat het intussen 400/40 is heb ik hun nog niet eens over geïnformeerd, ik zat toch nog steeds op hun te wachten. En gek genoeg, lijk ik met die 400/40 wel een iperf3 te kunnen doen waar een snelheid van 200+ uit komt, maar ook daar niet het maximum (IIRC 300-350). Terwijl een run van thuis naar een publieke server prima 390 of meer doet. Het lijkt dus eerder alsof het verkeer gek gesegmenteerd wordt, waardoor er veel meer protocol overhead is of zo (bedenk ik me nu ik dit type).
Namelijk IPv6. Ze geven een /64 adres uit. Maar blijkbaar routeren ze niet de /64 naar de VPS . De VPS heb ik op de prefix maar /72 gezet. Dit geeft dus nog 8 bits om te segmenteren. Waardoor ik Docker met IPv6 kan gebruiken (in die 8 bits). Waarbij containers dus rechtstreeks aan het internet gehangen kunnen worden met een GUA adres. Alleen..., kan ik die containers niet eens pingen. Wat er blijkbaar, altijd, gebeurt is dat de router van Netcup een neigbor solicit ("ARP request" bij IPv4) de deur uit doet voor het "onbekende" IP adres. Alleen kan mijn VPS hier "niks mee". Want de "fysieke" interface heeft bv <prefix>::1. Maar mijn reverse proxy draait in een container op <prefix>:8000::80. Vervolgens komt er op de "fysieke" interface een neighbor solicit voor <prefix>:8000::80 waar de VPS niks mee kan, want dat IP adres kent hij niet, op de interface waarop de solicit binnen komt (/uberhaupt niet. Maar er is wel een bridge en een virtuele interface voor <prefix>::8000::/72). Dus daar antwoord die niet op.). Dus waarschijnlijk kan ik mijn VPS ook laten antwoorden op zo'n IP (/gewoon dat IP statisch toekennen) en komt dat verkeer dan ineens op mijn VPS aan?!).Ik verwacht in zoverre ook niet dat het/iets werkt. Maar als de prefix a:b:c:d::/64 is en de VPS heeft IP a:b:c:d::1, en je doet "vanaf thuis" een ping naar a:b:c:d::2 dan zal er een "Unreachable address" / destination unreachable error zijn. Mijn vraag is dan "vanaf welk IP komt dat?" Is dat de eigen "a:b::d::1" of een ander adres?
Netcup ARM betaal je laag in de €7 en krijg je 6 cores en 256GB opslag. Bij Hetzner betaal je bijna €8 en krijg je 4 cores en ik meen nog geen 100GB opslag. Nee, ik heb het niet perse nodig. Bij Contabo nu ook 4 cores, en meen 50GB opslag.
Je krijgt wellicht minder resources. Maar daarentegen is er een klantenservice, goed netwerk en een aanbieder die z'n zaakjes beter op orde heeft. Dat telt in mijn ogen ook.:
[...]
V.w.b. Hetzner, iets duurder, en je krijgt minder
Ongevraagde verzoeken per DM beantwoord ik niet, sorry
No shit
Daarom vraag ik okm welke host de error geeft. En niet of er een error is. Dat er een error is weet ik ook wel met 100 zekerheid. Alleen wordt bij Contabo de error door mijn VPS gegeven (hele /64 gaat naar de VOS, die ::2 niet kent en errort), en bij Netcup door een router van hun (die ::2 nergens kan vinden in het hele netwerk, omdat geen enkele VPS deze advertised op de solicit van die router). En naar mijn idee "hoort" de error dus vanaf mijn VPS te komen. Als in: de provider die de hele /64 naar de VPS stuurt en de VPS het laat uitzoeken. Waarbij ik mij ook serieus afvraag of ik bij Netcup niet gewoon een IP adres kan claimen buiten mijn subnet (en niet in gebruik is) waarvoor ik wel solicits langs zie komen. Dan kan ik dus zomaar verkeer naar een andere VPS over nemen. Of een of andere rogue neighbor discovery implementatie die op elke solicit een advertise stuurt dat mijn VPS dat IP heeft. Dan kan dus niemand meer een IP adres gebruiken omdat ze allemaal in gebruik zijn
Ik ken Contabo niet met ipv6.:
[...]
No shit
Uiteraard werkt ping vanaf de VPS zelf ook niet. Maar punt is dat verkeer überhaupt niet bij de VPS aan komt.
) is het IP dat de error stuurt dus dat van de laatste hop voor de VPS), en daarnaast een tcpdump dus een solicit laat zien voor dat IP adres.
Als je vps niet eens antwoordt op de pung, dan begrijp ik niet waarom je verwacht dat je een reply van buiten krijgt - maar dat terzijde.:
[...]
Uiteraard werkt ping vanaf de VPS zelf ook niet. Maar punt is dat verkeer überhaupt niet bij de VPS aan komt.
Ik krijg zowel bij Contabo als Netcup een /64. Echter gebruik ik op de "fysieke" interface een /72. Vervolgens gebruik ik Docker met IPv6 waarbij ik dus 8 bits (/64 vs /72) heb om Docker bridges GUAs te geven. Alleen komt bij Netcup dat verkeer dus niet aan. Als ik a:b:c:d::/64 als prefix heb dan heb ik bv op a:b:c:d:8000::443 een HTTP server draaien, in Docker. Bij Contabo werkt dit out of the box prima. Verkeer naar de a:b:c:d::/64 prefix wordt altijd naar mijn VPS gestuurd, en de VPS kent a:b:c:d:8000::/72 want hij heeft zelf een bridge met adres a:b:c:d:8000::1/72 (+ dus een route dat a:b:c:d:8000::/72 direct bereikbaar is op die bridge). Bij Netcup werkt dit echter niet. Want die sturen niet alle verkeer van a:b:c:d::/64 naar de VPS. Maar die sturen in de plaats een neighbor solicit voor a:b:c:d:8000::443. Echter is er geen enkel systeem (en dus ook mijn VPS niet) die reageert op die solicit. Immers is er geen enkel "direct bereikbaar" systeem met dat IP adres. Mijn VPS zou het door hoepels heen wel kennen, maar moet daarvoor over een bridge heen, en dat is dus weer niet de bedoeling van solicits. De solicit is immers een ARP opvolger (/IPv6s variant van IPv4s ARP) en hoort dus niet over routers heen te gaan. Maar volgens mij zijn er wel userspace implementaties voor neighbor discovery die het wel relayen.
Oftewel: bij Contabo ligt er in hun router een route vast dat de volledige /64 naar mijn VPS gestuurd moet worden. En wat mijn VPS daar mee doet moet die zelf weten. En dat dit het geval is is dus simpel te bewijzen door een ping te doen naar een niet gebruikt IP adres binnen de prefix, de error is dan afkomstig van mijn VPS. Bij Netcup echter wordt niet de volledige /64 naar mijn VPS gestuurd (maar wordt in de plaats een solicit gedaan binnen het hele netwerk (case in point: ik zie ook de meest willekeurige solicits voor andere prefixes voorbij komen, "continu")), waardoor ik dus geen volledige controle heb over welke IPs ik waar gebruik. En dezelfde test (ping naar niet gebruikt IP binnen de prefix) bewijst dit doordat de error afkomstig is van een Netcup router (als ik een traceroute doe (naar het in gebruik zijnde IP
Ik draai mijn eigen router en het Ziggo modem staat in bridge. Enige dat Ziggo dus weet is welke prefix zij mij hebben toegekend
Verder weten ze daar helemaal niks van.Netcup geeft gewoon aan welke prefix je hebt/is toegewezen. Deze kan dan als static worden gebruikt op de VPS. Daarnaast geven ze uiteraard ook de te gebruiken gateway aan.
Naar mijn idee dus niet, en bij Contabo ook niet nodig. Waar Netcup (/de hosting provider) voor moet zorgen is dat de prefix waarvan ze zeggen dat dat die "van mij" is ook wordt afgeleverd. Welke IP adressen ik vervolgens daadwerkelijk toeken en hoe ik de rest inricht (of ik het in kleinere subnets bv verdeel) is voor hun in principe niet relevant.
Er is geen bridge op de fysieke interface. En noch de fysieke interface noch een hypothetische bridge waar die interface in zit kan in de geschetste scenario's "het IP adres" hebben. Want dat IP adres zit in een ander subnet, én zou leiden tot overlappende subnets.
Als het IP adres op de fysieke interface geconfigureerd is werkt het uiteraard prima. Netcup stuurt een neighbor solicit en de VPS reageert daaro. Immers heeft die dat IP adres op de interface (/in het broadcast domain) waarop de solicit binnen komt. Echter werkt dat dus niet als het IP adres, volledig valide, op een andere interface, en dus ander broadcast domain, is ingesteld. Een neigbor solicit is immers niet routeerbaar.
Met IPv6 zijn "(interne) adressen" redelijk not done. Immers geeft een /96 subnet al net zoveel mogelijke IP adressen als IPv4, en je krijgt ook nog eens een /64, dus nog veel en veel meer mogelijkheden. NAT / masquarading hoort dus helemaal niet thuis in een IPv6 wereld. En zelfs de Docker documentatie maakt gebruik van 2001:db8:..., dat gereserveerd is voor documentatie en valt onder de GUA (lees: publieke) adressen. Port forwarding (/DNAT) is dus niet nodig, enige dat nodig is is het toestaan om het verkeer (1-op-1) te forwarden. (Daar waar bij IPv4 dus destination nat wordt toegepast om het destination IP (en evt poort) te wijzigen, en het verkeer daarnaast ook bestemd is aan het publieke IPv4 adres (van de server), en bij IPv6 aan het GUA adres van de container).
Je wilt zeggen dat hoe een hosting provider een IPv6 subnet toekent en routeert naar een VPS (met in ieder geval een prefix administratief toegekend / gecommuniceerd naar de klant) niks met VPS ervaringen te maken heeft?
. Ook gecombineerd dus met het feit dat ik uberhaupt in no-time met een tcpdump een tiental NDP solicits per seconde voorbij zie komen. Wat mij ook een slecht gevoel geeft omtrent "security" en hoe de VPSen onderling (niet) gescheiden zijn. Want doe ik hetzelfde op mijn Contabo VPS, dan gebeurt er gewoon "niks". Komt geen enkel NDP verkeer voorbij. Staat intussen minuutje (/minuten?) te tcpdumpen en 0 icmp6 verkeer en dus ook geen NDP solicits.
De site geeft enorm de indruk dat ze een reseller zijn van een andere partij. Maar blijkbaar is Avoro sen handelsnaam van het Duitse dataforest GmbH. Ze hebben hun netwerk en peering wel enigszins op orde. Wel een beetje maf dat Avoro achter CloudFlare hangt.
Ongevraagde verzoeken per DM beantwoord ik niet, sorry
:no_upscale():strip_icc():strip_exif()/f/image/HZfl0zC7DSsny9zAkBjYOdS8.jpg?f=user_large) | :no_upscale():strip_icc():strip_exif()/f/image/GMcv0zDBOO8gViVBwqV9h50i.jpg?f=user_large) |
:strip_exif()/f/image/Ae3NH33NKzmOTgGtxZLk6wnc.png?f=user_large)
[ Voor 22% gewijzigd door rcthans op 22-05-2025 08:15 ]
Sowieso is het niet heel netjes om Plex te draaien bij een provider die dit expliciet verbiedt. Als ze erachter komen ben je sowieso je account kwijt. Dus ik hoop dat je niet teveel waarde hecht aan je servers bij Hetzner.
Ik geloof dat Hetzner het niet expliciet verbiedt (wss wel impliciet met voorwaarden), maar dat het juist Plex is die het niet toestaat om via Hetzner IP-adressen media te streamen, omdat ze juridische problemen willen voorkomen.:
[...]
Sowieso is het niet heel netjes om Plex te draaien bij een provider die dit expliciet verbiedt. Als ze erachter komen ben je sowieso je account kwijt. Dus ik hoop dat je niet teveel waarde hecht aan je servers bij Hetzner.
) en een MariaDB instance.
☎ Telecommunicatie van vroeger
🚅Alles over spoor en treintjes
:strip_exif()/u/55543/crop5eb8fd6c1bf0a_cropped.gif?f=community)
/u/638477/crop5a43b13f728ef_cropped.png?f=community)
:strip_icc():strip_exif()/u/53213/crop57ace20969734.jpeg?f=community)