PureVoltage.com - am I the crazy one?

mw · February 2025

Looks like they changed my route from HE to Cogent too

allthemtings · February 2025

Slightly offtopic but did you/are you moving away from Royale completely or did you get the issues straightened out? @mw

mw · February 2025

@allthemtings said:
Slightly offtopic but did you/are you moving away from Royale completely or did you get the issues straightened out? @mw

Too early to tell at this stage and we're planning on diversifying fully before making the decision to outright drop them.

All I can say is there has been no effort on their end whatsoever to keep us besides offering a "free server" along with the condition that we need to tell them we will not move away to get it, which we declined as a "free server" doesn't address the core reasons we are considering moving away.

We've also been relegated from having direct access to their CEO via Discord (which we had since the beginning) to having to use their standard ticketing queue system which to us feels like they themselves have lost interest in our relationship.

danblaze · February 2025

It's funny, I have a couple servers on their end with 10G ports each, and all of them are currently running over 5Gbps normally.

I also ran a iperf3 test with my other one located at crunchbits and it was also quite good.

From my personal experience, at least their network shouldn't be grossly oversold and the capacity is adequate.

However - things may be different to specific areas.

I'm very curious if you try to diversify and test the speed of your network?

For example, using Speedtest, or pulling some public mirrors, etc. to test the rate issue more holistically.

Or do you have them open a new server and grant them access and you use the same test methods. This will help to reproduce any problems.

Otherwise a lot of times this is like trying here and there like a fly on the wall, but it doesn't help solve the problem.

mw · February 2025

@danblaze said:
It's funny, I have a couple servers on their end with 10G ports each, and all of them are currently running over 5Gbps normally.

I also ran a iperf3 test with my other one located at crunchbits and it was also quite good.

From my personal experience, at least their network shouldn't be grossly oversold and the capacity is adequate.

However - things may be different to specific areas.

I'm very curious if you try to diversify and test the speed of your network?

For example, using Speedtest, or pulling some public mirrors, etc. to test the rate issue more holistically.

Or do you have them open a new server and grant them access and you use the same test methods. This will help to reproduce any problems.

Otherwise a lot of times this is like trying here and there like a fly on the wall, but it doesn't help solve the problem.

I've done Speedtest.net, iperf to every public iperf server on Google, iperf to my own 20/40G boxes in EU, HTTP, rclone (SFTP, Google Drive, Dropbox, OneDrive)

I sent them the exact commands used with iperf3 server IPs so they could check 1:1 what they see in their own testing. I'm waiting to hear back about the strange MTU issue because it might be linked to the high TCP retransmissions I'm seeing and if they want access to my server they're welcome, but they haven't asked for that.

mw · February 2025

I got sent a screenshot saying the switch says MTU 9000

I did test jumbo frames, but anything above 1472 gets fragmented. I asked about encapsulation again, let's hope they shed some more light on that specifically.

EDIT:

Is there a better way to test this than:

ping -M do -s size IP?

root@x:~# ping -M do -s 1476 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1476(1504) bytes of data.
1484 bytes from 1.1.1.1: icmp_seq=1 ttl=61 time=1.14 ms
1484 bytes from 1.1.1.1: icmp_seq=2 ttl=61 time=1.10 ms
^C
--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.102/1.123/1.144/0.021 ms

root@x:~# ping -M do -s 1477 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1477(1505) bytes of data.
^C
--- 1.1.1.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1027ms

root@x:~# iperf3 -c ping.online.net -p 5208 -P 1 -t 30 -i 5 -Z
Connecting to host ping.online.net, port 5208
[  5] local 169.197.86.x port 15998 connected to 51.158.1.21 port 5208
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-5.00   sec   855 MBytes  1.43 Gbits/sec  160730   35.7 MBytes
[  5]   5.00-10.00  sec  1.50 GBytes  2.57 Gbits/sec  73537   48.8 MBytes
[  5]  10.00-15.00  sec  1.45 GBytes  2.48 Gbits/sec  63885   61.1 MBytes
[  5]  15.00-20.00  sec  1.67 GBytes  2.87 Gbits/sec  75722   53.5 MBytes
[  5]  20.00-25.00  sec  1.51 GBytes  2.59 Gbits/sec  91514   47.3 MBytes
[  5]  25.00-30.00  sec  1.76 GBytes  3.02 Gbits/sec  87000    108 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-30.00  sec  8.71 GBytes  2.50 Gbits/sec  552388             sender
[  5]   0.00-30.07  sec  8.65 GBytes  2.47 Gbits/sec                  receiver

iperf Done.

bobsburgers · February 2025

@mw said:

@MannDude said:

@MeltedMembrane said:

@PureVoltage said:

@mw said:

@PureVoltage said:
I'd be happy to have our team spin up another server on the same switch to run some more tests tomorrow.

Let's continue this tomorrow - and I apologise for the snarky comment.

In the meantime, what tweaks do you recommend I try? It's just that I have never had an issue even on pure stock Debian when test endpoints are a couple of ms away.

No worries. I'll send some over shortly to you

Would you mind sharing with the class? Would be super curious to learn more about how to juice networking performance, if you don't mind

You can modify sysctl.conf which can have a big effect. I usually replace my kernel with xanmod on things that require high performance as well.

On mobile, but you can Google "cloudlare tcp sysctl.conf" and other related phrases. In a pinch, be specific with ChatGPT and ask it to pump out a config. Tell it what hardware you have and kernel and to tell you what each value means and why it chose that particular numerical value for each setting. Can start tweaking from there.

For anyone interested, below is the sysctl.conf changes provided to us from PureVoltage and below is what we already use on all our 40/20G boxes:

Provided by PureVoltage
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432
Using our standard 40G tune applied via tuned to all our 40G servers
https://tuned-project.org

# Network buffers for high-speed networks
net.core.rmem_max=268435456
net.core.wmem_max=268435456
net.core.rmem_default=268435456
net.core.wmem_default=268435456
net.core.optmem_max=134217728
net.ipv4.tcp_rmem=4096 87380 134217728
net.ipv4.tcp_wmem=4096 87380 134217728
net.ipv4.udp_mem=8388608 12582912 268435456
net.ipv4.udp_rmem_min=16384
net.ipv4.udp_wmem_min=16384

# TCP optimizations
net.ipv4.tcp_fastopen=3
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
net.ipv4.tcp_mtu_probing=1
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_notsent_lowat=131072
net.ipv4.tcp_window_scaling=1
net.ipv4.tcp_low_latency=1
net.ipv4.tcp_timestamps=1
net.ipv4.tcp_sack=1
net.ipv4.tcp_no_metrics_save=1
net.ipv4.tcp_synack_retries=2
net.ipv4.tcp_syn_retries=2
net.ipv4.tcp_max_syn_backlog=65536
net.ipv4.tcp_max_tw_buckets=2000000
net.ipv4.ip_local_port_range=1024 65535
net.ipv4.tcp_fin_timeout=10

# Network processing tuning
net.core.netdev_budget=1200
net.core.netdev_budget_usecs=14000
net.core.dev_weight=600
net.core.somaxconn=65535
net.core.netdev_max_backlog=250000
net.core.flow_limit_table_len=8192
net.core.bpf_jit_enable=1
net.core.bpf_jit_harden=0
net.core.rps_sock_flow_entries=32768
net.core.warnings=0

We did use Xanmod at a point in time, but we've since moved to using tuned + our own testing/trial-and-error and have had tremendous results. We have a tuned profile for each hardware spec at the hypervisor level and individual profiles for VMs.

Can't believe you never tuned the system as soon as you recieved the server. I always tune sysctl and get superior single thread speeds. Makes a world of difference. Purevoltages network is actually amazing in NY to APAC and EU. Their NY dc is start of the art.

mw · February 2025

@bobsburgers said:
@mw said:

@MannDude said:

@MeltedMembrane said:

@PureVoltage said:

@mw said:

@PureVoltage said:
I'd be happy to have our team spin up another server on the same switch to run some more tests tomorrow.

Let's continue this tomorrow - and I apologise for the snarky comment.

In the meantime, what tweaks do you recommend I try? It's just that I have never had an issue even on pure stock Debian when test endpoints are a couple of ms away.

No worries. I'll send some over shortly to you

Would you mind sharing with the class? Would be super curious to learn more about how to juice networking performance, if you don't mind

You can modify sysctl.conf which can have a big effect. I usually replace my kernel with xanmod on things that require high performance as well.

On mobile, but you can Google "cloudlare tcp sysctl.conf" and other related phrases. In a pinch, be specific with ChatGPT and ask it to pump out a config. Tell it what hardware you have and kernel and to tell you what each value means and why it chose that particular numerical value for each setting. Can start tweaking from there.

For anyone interested, below is the sysctl.conf changes provided to us from PureVoltage and below is what we already use on all our 40/20G boxes:

Provided by PureVoltage
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432
Using our standard 40G tune applied via tuned to all our 40G servers
https://tuned-project.org

# Network buffers for high-speed networks
net.core.rmem_max=268435456
net.core.wmem_max=268435456
net.core.rmem_default=268435456
net.core.wmem_default=268435456
net.core.optmem_max=134217728
net.ipv4.tcp_rmem=4096 87380 134217728
net.ipv4.tcp_wmem=4096 87380 134217728
net.ipv4.udp_mem=8388608 12582912 268435456
net.ipv4.udp_rmem_min=16384
net.ipv4.udp_wmem_min=16384

# TCP optimizations
net.ipv4.tcp_fastopen=3
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
net.ipv4.tcp_mtu_probing=1
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_notsent_lowat=131072
net.ipv4.tcp_window_scaling=1
net.ipv4.tcp_low_latency=1
net.ipv4.tcp_timestamps=1
net.ipv4.tcp_sack=1
net.ipv4.tcp_no_metrics_save=1
net.ipv4.tcp_synack_retries=2
net.ipv4.tcp_syn_retries=2
net.ipv4.tcp_max_syn_backlog=65536
net.ipv4.tcp_max_tw_buckets=2000000
net.ipv4.ip_local_port_range=1024 65535
net.ipv4.tcp_fin_timeout=10

# Network processing tuning
net.core.netdev_budget=1200
net.core.netdev_budget_usecs=14000
net.core.dev_weight=600
net.core.somaxconn=65535
net.core.netdev_max_backlog=250000
net.core.flow_limit_table_len=8192
net.core.bpf_jit_enable=1
net.core.bpf_jit_harden=0
net.core.rps_sock_flow_entries=32768
net.core.warnings=0

We did use Xanmod at a point in time, but we've since moved to using tuned + our own testing/trial-and-error and have had tremendous results. We have a tuned profile for each hardware spec at the hypervisor level and individual profiles for VMs.
Can't believe you never tuned the system as soon as you recieved the server. I always tune sysctl and get superior single thread speeds. Makes a world of difference. Purevoltages network is actually amazing in NY to APAC and EU. Their NY dc is start of the art.

its still performing poorly. run an iperf on your box to scaleway for me? i want to see something

mw · February 2025

Big shout out to PureVoltage's Jake for being such a team player. They have been extremely willing to help get to the bottom of this.

As it stands, we've tested -everything- and seem to have hit something odd which if fixed we are happy to proceed and full send.

All SSH traffic, irrespective of port or whether using mainline SSH or rclone's SSH seem to be limited to 200-250Mbps

Everything else is fast

Does anyone have any advice for things to look at to understand why this is?

I've already let PureVoltage know about this but while I wait for a response maybe one of you dweebs have seen this before?

MikePT · February 2025

I had a few interactions with PureVoltage's team, Jake is indeed a great guy!

So what speeds are you now able to reach, excluding SSH/rsync?

And what's your config like?
I need to tune a few 2x25Gbps servers too.

nullnothere · February 2025

@mw said: All SSH traffic, irrespective of port or whether using mainline SSH or rclone's SSH seem to be limited to 200-250Mbps

Everything else is fast

Can you try disabling a few/all ciphers to test out if there's anything going on in crypto land for SSH? There should be some quick online guides to help you select/disable some ciphers to test it out. Ciphers will impact speed/performance (depending on CPU on both sides) but they may come into play only at >10G, certainly not to limit you to 250Mbps.

I'm also curious on your kernel and the CPU (as well as the distro you're using to test things out).

When you say everything else is fast, do you mean even things like wget/curl for HTTP/S or do you mean only iperf?

Please do post your findings.

MaxTakeba · February 2025

@mw said:
Big shout out to PureVoltage's Jake for being such a team player. They have been extremely willing to help get to the bottom of this.

As it stands, we've tested -everything- and seem to have hit something odd which if fixed we are happy to proceed and full send.

All SSH traffic, irrespective of port or whether using mainline SSH or rclone's SSH seem to be limited to 200-250Mbps

Everything else is fast

Does anyone have any advice for things to look at to understand why this is?

I've already let PureVoltage know about this but while I wait for a response maybe one of you dweebs have seen this before?

SSH/SFTP is a bit of a fun problem. Even if you use the lightest of ciphers, cracking above 150mbps with even 100ms of latency or higher is the limit, I've honestly never been able to get higher. Even with some tuning.

I'll do some digging as this topic interests me as since I live in NZ and the two dedis and the 1 host c vps I work with have latency of about 220ms and higher... Latency is definitely a factor.

nullnothere · February 2025

@MaxTakeba said: SSH/SFTP is a bit of a fun problem. Even if you use the lightest of ciphers, cracking above 150mbps with even 100ms of latency or higher is the limit, I've honestly never been able to get higher. Even with some tuning.

I think it all depends on the in-between links.

I've had pretty good consistent throughput (not always of course) reaching 35-40 MB (so roughly 300+ Mbps) with latencies from 150ms to 250ms.

No tuning, standard vanilla SSH (rsync over SSH, Debian).

Latency does impact things but if the links are not particularly congested things are pretty stable.

mw · February 2025

@nullnothere said:

@mw said: All SSH traffic, irrespective of port or whether using mainline SSH or rclone's SSH seem to be limited to 200-250Mbps

Everything else is fast

Can you try disabling a few/all ciphers to test out if there's anything going on in crypto land for SSH? There should be some quick online guides to help you select/disable some ciphers to test it out. Ciphers will impact speed/performance (depending on CPU on both sides) but they may come into play only at >10G, certainly not to limit you to 250Mbps.

I'm also curious on your kernel and the CPU (as well as the distro you're using to test things out).

When you say everything else is fast, do you mean even things like wget/curl for HTTP/S or do you mean only iperf?

Please do post your findings.

I'll give that a shot this weekend but in all honesty I don't think it's an issue. Using the standard config I apply to all these servers I'm able to push 30Gbps+ over SSH using rclone without much fuss from Netherlands <-> Germany and have seen 20Gbps on US East <-> Netherlands from another provider here during our testing. It's why we have always used SSH and why the poor performance on PureVoltage is an issue in the first place.

So far I have tested HTTP using stock nginx and SSH, with the former I can hit 10Gbit using aria2c with 4 threads, while with SSH using rclone and 16 transfers with 4 connections per transfer I hit some sort of limit @ 200-250Mbps. With SCP over a single connection it also hits the same limit, leading me to believe whatever the issue is won't be fixed by throwing more concurrents.

@MikePT said:
I had a few interactions with PureVoltage's team, Jake is indeed a great guy!

So what speeds are you now able to reach, excluding SSH/rsync?

And what's your config like?
I need to tune a few 2x25Gbps servers too.

I spoke about the speeds in the message above. I'm sure I can get near line rate with more effort too. I posted my sysctl.conf somewhere above in this thread too. Nothing exotic at all hahaha

@MaxTakeba said:

@mw said:
Big shout out to PureVoltage's Jake for being such a team player. They have been extremely willing to help get to the bottom of this.

As it stands, we've tested -everything- and seem to have hit something odd which if fixed we are happy to proceed and full send.

All SSH traffic, irrespective of port or whether using mainline SSH or rclone's SSH seem to be limited to 200-250Mbps

Everything else is fast

Does anyone have any advice for things to look at to understand why this is?

I've already let PureVoltage know about this but while I wait for a response maybe one of you dweebs have seen this before?

SSH/SFTP is a bit of a fun problem. Even if you use the lightest of ciphers, cracking above 150mbps with even 100ms of latency or higher is the limit, I've honestly never been able to get higher. Even with some tuning.

I'll do some digging as this topic interests me as since I live in NZ and the two dedis and the 1 host c vps I work with have latency of about 220ms and higher... Latency is definitely a factor.

As mentioned above, I can cook over SSH at well above 10Gbit under ideal conditions even cross continent. It's why we have always used SSH.

mw · February 2025

We just ran tests with stock SSH over a Wireguard tunnel and performance was great - so we now know for certain the slowness is due to some form of traffic management they're doing. We hope this can be resolved

nullnothere · February 2025

@mw said: I'll give that a shot this weekend but in all honesty I don't think it's an issue.

I'd tend to agree - I've rarely come across any SSH issue on modern CPUs and I assume if you're on 10+Gbps links you're on a fast enough CPU anyway. Nevertheless, it's more to rule out some strange odd thing.

@mw said: So far I have tested HTTP using stock nginx and SSH, with the former I can hit 10Gbit using aria2c with 4 threads, while with SSH using rclone and 16 transfers with 4 connections per transfer I hit some sort of limit @ 200-250Mbps.

@mw said: stock SSH over a Wireguard tunnel and performance was great

Was this also the case if you changed SSH ports (i.e. without WG)?

So is it the SSH port that is being shaped or is there something that is detecting SSH traffic and shaping that particular stream?

mw · February 2025

@nullnothere said:

@mw said: I'll give that a shot this weekend but in all honesty I don't think it's an issue.

I'd tend to agree - I've rarely come across any SSH issue on modern CPUs and I assume if you're on 10+Gbps links you're on a fast enough CPU anyway. Nevertheless, it's more to rule out some strange odd thing.

@mw said: So far I have tested HTTP using stock nginx and SSH, with the former I can hit 10Gbit using aria2c with 4 threads, while with SSH using rclone and 16 transfers with 4 connections per transfer I hit some sort of limit @ 200-250Mbps.

@mw said: stock SSH over a Wireguard tunnel and performance was great

Was this also the case if you changed SSH ports (i.e. without WG)?

So is it the SSH port that is being shaped or is there something that is detecting SSH traffic and shaping that particular stream?

i ran ssh over port 80 and it was the same situation lol

no clue why anyone would ever shape SSH

nullnothere · February 2025

@mw said:

@nullnothere said:

@mw said: I'll give that a shot this weekend but in all honesty I don't think it's an issue.

I'd tend to agree - I've rarely come across any SSH issue on modern CPUs and I assume if you're on 10+Gbps links you're on a fast enough CPU anyway. Nevertheless, it's more to rule out some strange odd thing.

@mw said: So far I have tested HTTP using stock nginx and SSH, with the former I can hit 10Gbit using aria2c with 4 threads, while with SSH using rclone and 16 transfers with 4 connections per transfer I hit some sort of limit @ 200-250Mbps.

@mw said: stock SSH over a Wireguard tunnel and performance was great

Was this also the case if you changed SSH ports (i.e. without WG)?

So is it the SSH port that is being shaped or is there something that is detecting SSH traffic and shaping that particular stream?

i ran ssh over port 80 and it was the same situation lol

no clue why anyone would ever shape SSH

So they have something that is doing some sort of DPI equivalent for SSH traffic?

Can you also just give a shot at some cipher changes to see if there's anything there that changes your traffic rate. Might give a clue on what is really going on.

Really puzzled.

MaxTakeba · February 2025

@mw said:
We just ran tests with stock SSH over a Wireguard tunnel and performance was great - so we now know for certain the slowness is due to some form of traffic management they're doing. We hope this can be resolved

I decided to test the same scenario with a fresh ubuntu install on a KS-GAME-LE I'm about to put up for sale.

Without WG = 80mbps average over a 1 minute test.
With WG = 20mbps average over a 1 minute test.

I expected it to be lower as I'm adding another layer of encryption ON TOP of the already encrypted traffic.

I don't think I can add much more to this so I will bow out from posting, however I am watching with great interest as to see what the root cause is and resolution.

nullnothere · February 2025

@MaxTakeba said: Without WG = 80mbps average over a 1 minute test.

With WG = 20mbps average over a 1 minute test.

That doesn't seem to be OK. Can you also check with a MTR to see if there's any consistent packet loss? SSH is TCP but WG is UDP so TCP on UDP should only have fragmentation issues but I'm a little surprised at the loss of througput.

Also, what is the latency between the end points you were testing?

MaxTakeba · February 2025

@nullnothere said:

@MaxTakeba said: Without WG = 80mbps average over a 1 minute test.

With WG = 20mbps average over a 1 minute test.

That doesn't seem to be OK. Can you also check with a MTR to see if there's any consistent packet loss? SSH is TCP but WG is UDP so TCP on UDP should only have fragmentation issues but I'm a little surprised at the loss of througput.

Also, what is the latency between the end points you were testing?

224MS and that MTR would be clean(currently reinstalling as I am about to throw it up in Service Transfers).

Test was 10 minutes ago so 0 loss during that time.

My MTR (this is from another dedi that I have, same specs and everything) is very long to BHS but the performance is within what I'd expect. My international transport beyond as55850 (Mercury) get's really funky.

mw · February 2025

@MaxTakeba said:

@mw said:
We just ran tests with stock SSH over a Wireguard tunnel and performance was great - so we now know for certain the slowness is due to some form of traffic management they're doing. We hope this can be resolved

I decided to test the same scenario with a fresh ubuntu install on a KS-GAME-LE I'm about to put up for sale.

Without WG = 80mbps average over a 1 minute test.
With WG = 20mbps average over a 1 minute test.

I expected it to be lower as I'm adding another layer of encryption ON TOP of the already encrypted traffic.

I don't think I can add much more to this so I will bow out from posting, however I am watching with great interest as to see what the root cause is and resolution.

that cant be right. as for nested encapsulation, just run a speedtest (tls) on a vpn (wg) on your phone. you wouldn't expect to get less than 95% of your line rate unless your vpn was bad. same applies here

MaxTakeba · February 2025

@mw said:

@MaxTakeba said:

@mw said:
We just ran tests with stock SSH over a Wireguard tunnel and performance was great - so we now know for certain the slowness is due to some form of traffic management they're doing. We hope this can be resolved

I decided to test the same scenario with a fresh ubuntu install on a KS-GAME-LE I'm about to put up for sale.

Without WG = 80mbps average over a 1 minute test.
With WG = 20mbps average over a 1 minute test.

I expected it to be lower as I'm adding another layer of encryption ON TOP of the already encrypted traffic.

I don't think I can add much more to this so I will bow out from posting, however I am watching with great interest as to see what the root cause is and resolution.

that cant be right. as for nested encapsulation, just run a speedtest (tls) on a vpn (wg) on your phone. you wouldn't expect to get less than 95% of your line rate unless your vpn was bad. same applies here

Too late unfortunately.

It's up for service transfer and I don't want to mess with any of my production dedi's with this.

I may experiment with my RO from Host-C tomorrow and I can double check.

mw · February 2025

@MaxTakeba said:

@mw said:

@MaxTakeba said:

@mw said:
We just ran tests with stock SSH over a Wireguard tunnel and performance was great - so we now know for certain the slowness is due to some form of traffic management they're doing. We hope this can be resolved

I decided to test the same scenario with a fresh ubuntu install on a KS-GAME-LE I'm about to put up for sale.

Without WG = 80mbps average over a 1 minute test.
With WG = 20mbps average over a 1 minute test.

I expected it to be lower as I'm adding another layer of encryption ON TOP of the already encrypted traffic.

I don't think I can add much more to this so I will bow out from posting, however I am watching with great interest as to see what the root cause is and resolution.

that cant be right. as for nested encapsulation, just run a speedtest (tls) on a vpn (wg) on your phone. you wouldn't expect to get less than 95% of your line rate unless your vpn was bad. same applies here

Too late unfortunately.

It's up for service transfer and I don't want to mess with any of my production dedi's with this.

I may experiment with my RO from Host-C tomorrow and I can double check.

i have a box with host-c too lemme know if u want me to double check ur tests

nullnothere · February 2025

@mw said: anyone would ever shape SSH

Did you get to the bottom of this? Any insights?

Very curious on whatever the issue is/was.

mw · February 2025

@nullnothere said:

@mw said: anyone would ever shape SSH

Did you get to the bottom of this? Any insights?

Very curious on whatever the issue is/was.

We could not and have been refunded by PureVoltage - we're currently in final testing with another provider which has performed as expected

MaxTakeba · February 2025

@mw said:

@nullnothere said:

@mw said: anyone would ever shape SSH

Did you get to the bottom of this? Any insights?

Very curious on whatever the issue is/was.

We could not and have been refunded by PureVoltage - we're currently in final testing with another provider which has performed as expected

Glad there was a resolution, unfortunate PureVoltage couldn't get to the bottom of it.
I also want to apologize I didn't get back to you when I said I would. Work has been mega busy.

Howdy, Stranger!

Categories

In this Discussion

PureVoltage.com - am I the crazy one?

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

PureVoltage.com - am I the crazy one?

Comments