Slow download speed - Heze/Persei Fremont/CA Servers

[ddrnewb 1]

Curiously, your speed test says your VPN is on NL

 

Because speedtest.net does not trace the physical location of your IP address. It only checks for the registered location of the IP address.

 

 

We're not getting anywhere with this. We need an actual comparison of the data of many different users to see where the error is.

Too many people are reporting worse speeds with AirVPN in comparison to other VPN providers. The general explanation is either shaping or bad peering. I started to doubt this claim when someone noticed this "shaping" only takes effect when using Windows. On Linux that person could reach full speeds.

 

I am really interested in solving this for everybody here and everyone to come in the future. Posts containing "I experience bad speeds with AirVPN" are so frequent now, it definitely is one more question to append to my signature FAQ, but guess what - there's no solution.

 

Let me think about how to do this..

 

(Sent via Tapatalk 4)

 

I've used some VPN services where the speed was much worse than what I am currently experiencing with AirVPN's Persei and Heze. Namely Cyberghost VPN and Pure VPN. Their west coast USA servers were absolutely terrible. 8~10Mbps download average, frequent spikes in latency, plagued with packet loss and constant interruptions.

To be fair, I do like the reliability of Persei and Heze, although I do experience packet loss occasionally. So unless the problems get worse, I am probably staying with AirVPN for a while.

But it pisses me off to no end if VPN support is too quick to blame the problems to the user or his ISP, suggesting problem with the user's router setup or oversold node/traffic shaping by the ISP, when there is no concrete evidence to do so.

I guess it's much more convenient to blame the user and his ISP rather than admitting inadequacy of their VPN servers.

[pj 72]

I guess it's much more convenient to blame the user and his ISP rather than admitting inadequacy of their VPN servers.

 

 

This is not the case. To prove that, we transparently and continuously publish a lot of relevant data for each and every server. Everybody, even if not subscribed to our service, can access them anytime, through the servers monitor on our web site by clicking "Status" on the upper menu (click on the servers names to display the details of each server):

 

https://airvpn.org/status

https://airvpn.org/servers/Heze

https://airvpn.org/servers/Persei

 

If a datacenter starts failing to deliver what it was agreed upon, we have no hesitations to withdraw the server(s) in those datacenters, as we have done sporadically and when necessary in the past (currently this problem is arising with Zaurak in Kiev). I am sure that you can understand that for us it would be totally insensate, i.e. a self-damaging behavior, maintaining servers in problematic datacenters and pretending that it's all right.

About Heze and Persei, look at the data collected during the last weeks: apparently there are no particular issues for immediate concern. This is confirmed also by our deep monitoring system which so far has nothing to report.

 

It must also be said that no other complaints on the servers have been filed by any customer about Heze and Persei recently, but I assure you that we'll continue to monitor the servers, just like we do and we have always done for every other server in the infrastructure.

 

Your last message is in my opinion an unfair attempt to bring damage to AirVPN reputation and image. I also repute that your last message is highly offensive toward the support staff and the community, made of persons who answer in the forum as a courtesy to try to solve problems, not to "blame" you or any other user. You shall immediately stop to post defamatory messages in our forums.

 

pj

AirVPN co-founder

[ddrnewb 1]

 

I guess it's much more convenient to blame the user and his ISP rather than admitting inadequacy of their VPN servers.

 

 

This is not the case. To prove that, we transparently and continuously publish a lot of relevant data for each and every server. Everybody, even if not subscribed to our service, can access them anytime, through the servers monitor on our web site by clicking "Status" on the upper menu (click on the servers names to display the details of each server):

 

https://airvpn.org/status

https://airvpn.org/servers/Heze

https://airvpn.org/servers/Persei

 

If a datacenter starts failing to deliver what it was agreed upon, we have no hesitations to withdraw the server(s) in those datacenters, as we have done sporadically and when necessary in the past (currently this problem is arising with Zaurak in Kiev). I am sure that you can understand that for us it would be totally insensate, i.e. a self-damaging behavior, maintaining servers in problematic datacenters and pretending that it's all right.

About Heze and Persei, look at the data collected during the last weeks: apparently there are no particular issues for immediate concern. This is confirmed also by our deep monitoring system which so far has nothing to report.

 

It must also be said that no other complaints on the servers have been filed by any customer about Heze and Persei recently, but I assure you that we'll continue to monitor the servers, just like we do and we have always done for every other server in the infrastructure.

 

Your last message is in my opinion an unfair attempt to bring damage to AirVPN reputation and image. I also repute that your last message is highly offensive toward the support staff and the community, made of persons who answer in the forum as a courtesy to try to solve problems, not to "blame" you or any other user. You shall immediately stop to post defamatory messages in our forums.

 

pj

AirVPN co-founder

 

Please note that I was also stating my experience with other VPN providers and I said "VPN support". It was not specifically aimed at AirVPN.

However, you can see from this thread that your staff's suggestion that my ISP was the reason for the sub-par speeds I am experiencing with AirVPN has been proven to be false.

This should be impossible if my ISP was indeed traffic shaping.

 

Yes, the situation that people are not getting 100+ Mbps download is probably not a cause for "immediate concern". I don't believe your deep monitoring system would report something like that either.

I've noticed that your servers can provide high speed during non-peak hours and weekdays, while the speed can drop to as low as 15Mbps during peak hours and weekends.

it is indeed a problem for people who have 100+ Mbps Internet and was looking for a VPN that can provide somewhere close to that speed reliably.

[OpenSourcerer 1441]

I guess it's much more convenient to blame the user and his ISP rather than admitting inadequacy of their VPN servers.

 

I don't blame anyone here because a vast amount of users are more than satisfied with their speed (hrrhrr, including me ), and some of them subscribed to 100 Mbit plans (unfortunately, not including me ). I was pointing at those who fail to reach these speeds. One particular case highly interests me because that person downloaded with full speed on Linux and failed to do so on Windows. So I assume reasoned this shaping thing has something to do with Windows, it's (TCP/IP stack) (default) configuration, the hardware drivers and/or the driver's configuration. Going to drill down on that...

[pj 72]

b

 

Please note that I was also stating my experience with other VPN providers and I said "VPN support". It was not specifically aimed at AirVPN.

 

 

Hello again,

 

true. My sentences covered all the cases. I am also the legal representative person for Air so I wish to act to reasonably prevent actions from competitors who could feel to have been defamed by posts appearing in our forums.

 

 

However, you can see from this thread that your staff's suggestion that my ISP was the reason for the sub-par speeds I am experiencing with AirVPN has been proven to be false.

This should be impossible if my ISP was indeed traffic shaping.

 

 

Why? Before posting, I have once again re-read Comcast policy on traffic shaping and it appears totally consistent with what you observe. I am not saying that it must be traffic shaping necessarily, but I don't see any reason to rule it out. Here:

http://customer.comcast.com/help-and-support/internet/network-management-information

 

Comcast writes that traffic shaping is applied on the basis of current network conditions and recent amounts of data transferred by users. It also writes that when the congestion management technique is applied to an individual user’s account, it is usually only for a very brief period of time.

 

Comcast has determined that select portions of the network tend to be congested only for small portions of the day

 

And even, in order to trigger traffic shaping:

customers’ accounts must exceed a certain percentage of their upstream or downstream bandwidth (both currently set at 70%) for longer than a certain period of time, currently set at 15 minutes.

 

So, in peak times your traffic will be shaped unconditionally in case of congestions. Additionally, anytime your traffic will be shaped (assuming you have a 100/10 Mbit/s line) whenever you keep uploading at least 7 Mbit/s for 15 minutes and/or downloading at least 70 Mbit/s for 15 minutes.

 

Duration of such shaping is "brief", and congestion occurs "only for small portions of the day". Both definitions have not much legal meaning, they can be easily stretched in multiple ways. In practice I feel that Comcast can shape for as long as it wishes according to those definitions.

 

Now... Directly from inside Heze and Persei, I have downloaded files from Dallas locations in selected dedicated servers (so even far away geographically) during your reported peak times. Although such tests must be repeated, at the moment the performance recorded in download has been fluctuating from 750 to 850 Mbit/s (saturating the 1 Gbit/s line when summed up with bandwidth usage from connected clients).

 

My momentary conclusion is that your problem is NOT caused by congestion on Heze or Persei. I would also tend to exclude that the cause is in your system. Again, everything is pointing to Comcast traffic shaping. We'll see in the future, while more data will be gathered and what other members of the staff will think about it. I will also take care to read your considerations (if any) about all of the above.

 

 

Yes, the situation that people are not getting 100+ Mbps download is probably not a cause for "immediate concern".

 

 

We are very frank about it: read the Terms of Service. We are bound to not oversell by guaranteeing a bandwidth allocation of 8 Mbit/s per client anytime, in the whole of our infrastructure. On single servers, it is inappropriate to think that we can provide 100+ Mbit/s per client. Even with the next generation AirVPN, when 1 Gbit/s lines could be replaced by 10 Gbit/s lines, that will be difficult (at the current prices). Remember that x Mbit/s for a client means x*2 Mbit/s on the server.

 

That said, currently we can provide without much issues from 40 to 70 Mbit/s, as you have already noticed. You can also compare the Top 10 Users speed table in the "Status" menu. Interestingly, clients connecting from dedicated servers always beat those performances, because on dedicated servers you don't have traffic shaping, extreme line sharing & overselling that you experience with providers which tend to sell "100 Mbit/s" peak Internet at very low prices.

 

 

I don't believe your deep monitoring system would report something like that either.

 

Oh, it does. In the Top 10 Users speed you see only the top 10 clients speeds, but we can see the real speeds of all the clients. You can't see that but you can see the total used bandwidth on the whole infrastructure. Additionally, the monitoring system monitors CPU load of each and every server, which is an excellent indicator to show when a server is at capacity, and dozens of other significant parameters.

 

Kind regards

[pj 72]

 

I guess it's much more convenient to blame the user and his ISP rather than admitting inadequacy of their VPN servers.

 

I don't blame anyone here because a vast amount of users are more than satisfied with their speed (hrrhrr, including me ), and some of them subscribed to 100 Mbit plans (unfortunately, not including me ). I was pointing at those who fail to reach these speeds. One particular case highly interests me because that person downloaded with full speed on Linux and failed to do so on Windows. So I assume reasoned this shaping thing has something to do with Windows, it's (TCP/IP stack) (default) configuration, the hardware drivers and/or the driver's configuration. Going to drill down on that...

 

The TAP driver for Windows is more limited than in other systems. I have read reports on the field according to which it can't handle more than 80 Mbit/s throughput (try to google for that). Add this to a myriad of problems in Windows (including network managers interfering with the tun/tap interface) and maybe (maybe) you have a first hint at least for some cases.

 

I am not sure whether the new TAP driver will solve this limitation, in any case Eddie 2.9.2 uses it whenever possible, let's see if it will bring improvements for Windows systems. Eddie developer has been handling this issue recently.

 

Bye!

[ddrnewb 1]

b

 

Please note that I was also stating my experience with other VPN providers and I said "VPN support". It was not specifically aimed at AirVPN.

 

 

Hello again,

 

true. My sentences covered all the cases. I am also the legal representative person for Air so I wish to act to reasonably prevent actions from competitors who could feel to have been defamed by posts appearing in our forums.

 

 

>

However, you can see from this thread that your staff's suggestion that my ISP was the reason for the sub-par speeds I am experiencing with AirVPN has been proven to be false.

This should be impossible if my ISP was indeed traffic shaping.

 

 

Why? Before posting, I have once again re-read Comcast policy on traffic shaping and it appears totally consistent with what you observe. I am not saying that it must be traffic shaping necessarily, but I don't see any reason to rule it out. Here:

http://customer.comcast.com/help-and-support/internet/network-management-information

 

Comcast writes that traffic shaping is applied on the basis of current network conditions and recent amounts of data transferred by users. It also writes that when the congestion management technique is applied to an individual user’s account, it is usually only for a very brief period of time.

 

Comcast has determined that select portions of the network tend to be congested only for small portions of the day

 

And even, in order to trigger traffic shaping:

customers’ accounts must exceed a certain percentage of their upstream or downstream bandwidth (both currently set at 70%) for longer than a certain period of time, currently set at 15 minutes.

 

So, in peak times your traffic will be shaped unconditionally in case of congestions. Additionally, anytime your traffic will be shaped (assuming you have a 100/10 Mbit/s line) whenever you keep uploading at least 7 Mbit/s for 15 minutes and/or downloading at least 70 Mbit/s for 15 minutes.

 

Duration of such shaping is "brief", and congestion occurs "only for small portions of the day". Both definitions have not much legal meaning, they can be easily stretched in multiple ways. In practice I feel that Comcast can shape for as long as it wishes according to those definitions.

 

Now... Directly from inside Heze and Persei, I have downloaded files from Dallas locations in selected dedicated servers (so even far away geographically) during your reported peak times. Although such tests must be repeated, at the moment the performance recorded in download has been fluctuating from 750 to 850 Mbit/s (saturating the 1 Gbit/s line when summed up with bandwidth usage from connected clients).

 

My momentary conclusion is that your problem is NOT caused by congestion on Heze or Persei. I would also tend to exclude that the cause is in your system. Again, everything is pointing to Comcast traffic shaping. We'll see in the future, while more data will be gathered and what other members of the staff will think about it. I will also take care to read your considerations (if any) about all of the above.

 

 

Yes, the situation that people are not getting 100+ Mbps download is probably not a cause for "immediate concern".

 

 

We are very frank about it: read the Terms of Service. We are bound to not oversell by guaranteeing a bandwidth allocation of 8 Mbit/s per client anytime, in the whole of our infrastructure. On single servers, it is inappropriate to think that we can provide 100+ Mbit/s per client. Even with the next generation AirVPN, when 1 Gbit/s lines could be replaced by 10 Gbit/s lines, that will be difficult (at the current prices). Remember that x Mbit/s for a client means x*2 Mbit/s on the server.

 

That said, currently we can provide without much issues from 40 to 70 Mbit/s, as you have already noticed. You can also compare the Top 10 Users speed table in the "Status" menu. Interestingly, clients connecting from dedicated servers always beat those performances, because on dedicated servers you don't have traffic shaping, extreme line sharing & overselling that you experience with providers which tend to sell "100 Mbit/s" peak Internet at very low prices.

 

 

I don't believe your deep monitoring system would report something like that either.

 

Oh, it does. In the Top 10 Users speed you see only the top 10 clients speeds, but we can see the real speeds of all the clients. You can't see that but you can see the total used bandwidth on the whole infrastructure. Additionally, the monitoring system monitors CPU load of each and every server, which is an excellent indicator to show when a server is at capacity, and dozens of other significant parameters.

 

Kind regards

 

I am aware of Comcast's pratice in traffic shaping. But as I've repeated stated in this thread, I do not believe it is the reason for the speeds I am experiencing with AIrVPN.

 

Why?

 

1) I can get 100+ Mbps download speed reliably, any time of the day, without VPN and with a different VPN provider using UDP protocol on port 443.

 

2) The city that I live in is one of the "model" cities for Comcast. It is one of the first cities to receive upgrades and performance boosts. And the neightborhood I live in is a low-income neighborhood where most households subscribe to cheap DSL plans. So it is highly unlikely that my node is oversaturated.

 

3) If I was on an oversold node, I would notice it immediately, as I've previously stated repeatedly. I've dealt with oversold nodes before. I even forced the ISP(Charter) to fix it and give me full refunds for 6 consecutive months.

 

4) As for traffic shaping, I am not a high bandwidth user so it's very unlikely that I would be targeted for it if Comcast was seletively targeting its users for traffic shaping. I rarely download torrents on my computer. Most of my torrent downloading is done on a dedicated server located in Netherlands.

If I need to transfer some files to my computer, I use FTP to do so, but I rarely have the need for it. I use VPN for different reasons than hiding my download habbits from my ISP.

 

Therefore, I don't believe traffic shaping is affecting the very brief moments when I do speedtests while connected to AirVPN, especially when Comcast's "Speedboost" feature should be kicked in. In addition, there is no explanation as to how I can get 100+Mbps download with a different VPN provider.

 

Here, I just did some speed tests.

 

Without VPN:

 

Alkaid (Chicago)

 

Sabik (Los Angeles)

 

Persei (Fremont)

 

Heze (Fremont)

 

Do you really think the Comcast's traffic shaping is affecting the speeds this much? This inconsistently?

[ddrnewb 1]

These speed test results were done within 3 minutes of each other. All conditions same except the VPN server I was connected to.

Protocol = SSL 443

 

Test Set #1:

9:21 PM PST - Persei (Fremont, CA) Server

 

9:18 PM PST - Merope (Los Angeles, CA) Server

 

-----------------------------------------------------------------

 

Test Set #2:

9:26 PM PST - Persei (Fremont, CA) Server

 

9:29 PM PST - Merope (Los Angeles, CA) Server

 

 

What can you conclude from this? Still traffic shaping by my ISP?

[ddrnewb 1]

This is actually the review that convinced me to purchase AirVPN subscription: https://airvpn.org/topic/11784-tier-1-speed-tests-us-servers/

 

I read it again today and noticed this:

 

I did several tests and all tests were done from a tier one connection, from a Windows 2012 R2 Server, which wasn't running anything at the time.

I only tested on airvpn servers that were under 25% load at the time and ran 5-15 tests and provided the median results.

 

Top Tier West Coast General Test

 

Heze (California) to MonkeyBrains (San Fracisco, CA)

 

Isn't it strange that he was able to get only 84.58 Mb/s on Heze server when the load was under 25%?

 

It seems to me that there might be an issue with the datacenter that houses your Persei and Heze server. And are the servers truly 1Gbps? Full-duplex?

[Staff 10014]

 

I guess it's much more convenient to blame the user and his ISP rather than admitting inadequacy of their VPN servers.

 

I don't blame anyone here because a vast amount of users are more than satisfied with their speed (hrrhrr, including me ), and some of them subscribed to 100 Mbit plans (unfortunately, not including me ). I was pointing at those who fail to reach these speeds. One particular case highly interests me because that person downloaded with full speed on Linux and failed to do so on Windows. So I assume reasoned this shaping thing has something to do with Windows, it's (TCP/IP stack) (default) configuration, the hardware drivers and/or the driver's configuration. Going to drill down on that...

 

Hello!

 

Have you seen this: https://airvpn.org/topic/13652-eddie-udp-443-on-windows-vs-linux/?do=findComment&comment=27068 ?

 

Kind regards

[ddrnewb 1]

How long are you going to keep my posts under moderator queue?

I didn't expect this kind of censorship from a VPN company.

[pj 72]

Hello!

As I wrote, I needed at least two days to gather more data during the peak times you reported. I did not detect any congestion on Heze or Persei, various tests bring the total throughput extremely near to 1 Gbit/s. Download rates from USA servers are stable around 800 Mbit/s. As far as I am concerned the case is closed until new feedbacks from customers arrive. Of course if you get better performance with Merope, connect to Merope: peering, routing etc. may be better for you than with Heze and Persei.

About your other questions:
 

Do you really think the Comcast's traffic shaping is affecting the speeds this much? This inconsistently?

Yes, it's written in the Comcast policies, as I showed you. Traffic shaping can vary continuously. "Very brief periods of time" may well mean anything, even less than your 3 minutes reference, of course. So the behavior you observed is not incompatible with traffic shaping, but as it has already been written it could be also due to congestion somewhere between Comcast and the datacenter (not on Heze or Persei datacenter, at least from my tests in these days), or even bad peering/routing. But let's wait for feedbacks from other customers using those servers, as I told you it's not that a few days of testings can be considered conclusive.
 

Isn't it strange that he was able to get only 84.58 Mb/s on Heze server when the load was under 25%?

No, that's not particularly strange. There are many additional factors to be considered when you tunnel traffic: overhead both in CPU and traffic, forced hop and of course peering and routing between the particular speed tester server and the VPN server [staff edit: network path capacity - weakest backbone or node in the path determines theoretical upper limit].

 

As usual, these speed test are quick bursts which can be misleading. In that review, note also that the worst result was obtained from a Comcast testing server to one of our servers in Florida. It's an additional hint which makes me wonder about Comcast peering. Anyway trying to analyze the peering agreements and related problems between our tier 1-2-3 providers with all the residential ISPs in the world goes well beyond our duties and also our abilities in terms of time. We already have quite demanding requirements for datacenters, it's the best we can do and it's much more than what most of our competitors do. Just consider that many VPN providers do not even allow various p2p protocols on USA servers, to make a significant example.
 

It seems to me that there might be an issue with the datacenter that houses your Persei and Heze server. And are the servers truly 1Gbps? Full-duplex?

At the moment no such problems can be detected by my tests. Yes, they are truly "1 Gbit/s full-duplex". This is of course a simplification. Saying that a server has a "1 Gbit/s line" is a quick way, a sort of abstraction, to mean that (trying to be quick here) from the server network card to the uplink port(s), and from the uplink port to the dc volume routers, passing through the whole network, the infrastructure can sustain (reasonably 24h/24 except under very special circumstances and problems) 1 Gbit/s bandwidth to/from that server. In reality the configuration can be much more complex and you don't have a "1 Gbit/s line" but a battery of 1, 10, 100 or even 1000 Gbit/s ports, switches, volume routers etc. with a battery of fiber cables etc.
 

How long are you going to keep my posts under moderator queue?
I didn't expect this kind of censorship from a VPN company.

Come on and don't be ridicolous now, be nice and patient for 24 hours for once, if there are delays in the moderation queue they are not a lethal threat to your freedom of expression on technical forums aimed to help technically the AirVPN community. Now let's wait with patience to gather more data and also see if more feedback from other customers come in.

Kind regards
pj
 

[go558a83nk 364]

just another try to point in the direction of this thread.  have you tried the buffer changes ddrnewb?

 

https://airvpn.org/topic/13652-eddie-udp-443-on-windows-vs-linux/

[amnesty 18]

just another try to point in the direction of this thread.  have you tried the buffer changes ddrnewb?

 

https://airvpn.org/topic/13652-eddie-udp-443-on-windows-vs-linux/

+1

[ddrnewb 1]

just another try to point in the direction of this thread.  have you tried the buffer changes ddrnewb?

 

https://airvpn.org/topic/13652-eddie-udp-443-on-windows-vs-linux/

 

Yea I have tried the buffer changes. I noticed my buffer was set at 8192 too. So I changed it to 262144 and did some speedtests on UDP.

Saturday 11:52 AM PST - Persei

 

It's much better but I also got this result using identical settings.

Friday 10:21 PM PST - Persei

 

I also tried setting the buffer sizes to 524288 but no improvement from 262144.

 

So yea, increasing the buffer size seems to improve speed but it's still nowhere close to what I had been getting with other VPN providers.

 

Also, very disappointed by PJ's continued suggestion that it must be traffic shaping by my ISP Comcast when it fails to explain how I was getting 100+Mbps download speed with other VPN providers.

Not to mention I've never experienced any kind of throttling during the last 5 years of using Comcast at my current location. But as soon as I post this thread here to question the slower speed I am experiencing

with AirVPN, it must be traffic shaping by Comcast. Quite ridiculous.