I’m currenty using Oracle Free Tier for Jellyfin (hosted in Paris) and i wanted to know what is the proper way to speed up media delivery when i’m far away from the server location ? (Korea currently)
EDIT :
After all your replies, my VPN through Hong Kong give me the best speed.
I know it sounds funny, but look up the “long, fat pipe problem.” Latency matters to TCP network connections and signals can only move so fast through a wire.
They are limited to 50mbps, as far as I remember, and considering your distance, I would say the ping speeds should be somewhere between 170ms and 250ms.
Which means (unless I grossly misunderstand the concept)
that your video(s) are stored not only on your own server but also shared out to other servers which also keep a copy cached.
So in this scenario it would be very much immune to these concerns because your video(s) will be streamed from the closest federated server to you which has a copy, meaning you will always get the best throughput no matter what your physical location is or what it was when you uploaded.
Ideally yes, but only the public videos are shared with other servers. Most of the videos on my instance are internal, so only people who have an account on it can access the videos.
Videos are shared p2p between users currently watching the same video. Even then they only keep a certain amount in cache to share with others, so they must watch roughly the same section of the video as each other aswell.
You’re probably limited by your TCP window sizes and congestion control algorithm. Look up a TCP throughput calculator and adjust your window size/congestion control as needed.
If your hosting provider doesn’t grant access to this level, you could try various tunnels, like a UDP VPN that might be more resiliant. Again, not sure how limited you are with your provider. Worst case you could UDP VPN into a server in the same city as your host
Yeah, I wouldn’t think high latency would be too much of an issue for streaming (except maybe for the initialisation), as long as the client has a decent buffer size and doesn’t wait for a packet to arrive before requesting the next one. What client are you using to play your videos?
Peering is actually a complex issue. The ISP you’re currently using might not have a good peering with your data center operator.
One way to force a different peering is by complaining to your ISP. Include the server’s IP address in the complain, and their sysadmin might take a look and alter their routing table so traffics going to your data center will go through different route (assuming the ISP is not shitty and have multiple high quality peering AND actually looking at your support request).
Another way is by using a VPN. By using a VPN, you’ll bypass your ISP’s network routing. Your traffic will go through your VPN provider’s data center instead, which have completely different peering partners than your ISP. Try connecting to different country (e.g. Singapore, Hong Kong, Japan, Europe) to see which one is the fastest. For example, your ISP might have a good peering to Hong Kong, so by connecting to a Hong Kong VPN server, you’ll bypass your ISP’s shitty peering to Europe.
Finger cross though. In general, connection between this part of Asia and Europe is not great because there is no direct route. Connection to US is a lot faster in comparison because there are many direct undersea fiber optics links.
I used to oversee WAN and peering operations for a large multi site. Residential ISPs almost never respond to reports of inefficient routes unless you are one of their peers, big business customers, or you really know your stuff and send in a detailed report showing asymetric routes, bad bgp info, etc.
As far as a VPN goes, that probably wouldn’t help either. You will probably increase the number of hops and latency. Your route will still egress your isp gateway, to your VPN provider, then travel over the Internet and to your remote server, while adding additional protocol overhead. Yes, it is remotely possible that there is an improved link from his regional VPN node to his remote provider, but unlikely from my experience with traffic engineering.
Residential ISPs almost never respond to reports of inefficient routes unless you are one of their peers
Oh man, fucking tell me about it. I remember Verizon support gave the absolute runaround when I was trying to debug why my server was absolute garbage in San Jose vs LA. Took me 3 separate support calls for them to finally do something about it. It also took me a while to figure out it was an ISP issue in the first place.
Actually in my case it did help. I got faster speed to one of my VPS in Paris (OVH) if I use VPN to Singapore first. Heck, even my VPS in Singapore (also OVH) is faster too after connecting to the VPN. My ISP probably really have a bad peering with OVH.
That’s interesting. Any chance your ISP could have been qos’ing streaming video? Although Singapore would be about the one place where a VPN concentrator would help; it is pretty much the big fiber hub in that local region for East, West, North connectivity.
I don’t think they have QoS beyond enforcing soft data cap at 2TB. Another weird thing I notice with this ISP is how bad sites hosted behind cloudflare would perform. It usually fine, but sometimes they have random high latency on random assets (js, css or image files), and when it happens the speed to that site would tank too to just a few hundred KB/s or less. When it happens it’ll magically gone by using a VPN.
Welcome to the reason why a competitor to YouTube is almost impossible. Network routing is extremely complicated and short of laying your own cables or having multiple points of presence there’s not much you can do about it.
I’ve only ever used Oracle cloud in an enterprise environment, so I don’t know what features you have available. I’m also much more familiar with AWS. But you should be able to create a proxy endpoint in your present region, and traverse the cloud providers internal network. That would likely improve your streaming. You could also create a VPN endpoint in your current region and terminate your traffic inside your cloud providers network, but that would add protocol overhead.
I would look at tools like iperf to look at your packet loss because being further from your server will increase latency, but shouldn’t impact the streaming unless you also have packet loss.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
Okay, so I have actually lived in Korea for 15 years, and am into self hosting, servers for media, etc.
What I can tell you is, you are fucked. Peering to anywhere other than Japan is a nightmare.
Give up and build your own server in your own home. No amount of peering tricks or CDNs will help you.
The best you’ll get in terms of connections to major service providers is hosting in Dallas, which should get you around 100mbps.
I know it sounds funny, but look up the “long, fat pipe problem.” Latency matters to TCP network connections and signals can only move so fast through a wire.
They are limited to 50mbps, as far as I remember, and considering your distance, I would say the ping speeds should be somewhere between 170ms and 250ms.
My PeerTube server https://tube.jeena.net is in Germany and I’m also in Korea, but I don’t really feel any speed problems.
Ok but isn’t peertube defederated?
Which means (unless I grossly misunderstand the concept)
that your video(s) are stored not only on your own server but also shared out to other servers which also keep a copy cached.
So in this scenario it would be very much immune to these concerns because your video(s) will be streamed from the closest federated server to you which has a copy, meaning you will always get the best throughput no matter what your physical location is or what it was when you uploaded.
Ideally yes, but only the public videos are shared with other servers. Most of the videos on my instance are internal, so only people who have an account on it can access the videos.
*
defederatedVideos are shared p2p between users currently watching the same video. Even then they only keep a certain amount in cache to share with others, so they must watch roughly the same section of the video as each other aswell.
Ah interesting.
So unless you are watching a currently very popular video you are likely just streaming from the server where the video was originally uploaded?
That is my understanding.
You’re probably limited by your TCP window sizes and congestion control algorithm. Look up a TCP throughput calculator and adjust your window size/congestion control as needed.
If your hosting provider doesn’t grant access to this level, you could try various tunnels, like a UDP VPN that might be more resiliant. Again, not sure how limited you are with your provider. Worst case you could UDP VPN into a server in the same city as your host
Yeah, I wouldn’t think high latency would be too much of an issue for streaming (except maybe for the initialisation), as long as the client has a decent buffer size and doesn’t wait for a packet to arrive before requesting the next one. What client are you using to play your videos?
Jellyfin Media Player or the website player
Peering is actually a complex issue. The ISP you’re currently using might not have a good peering with your data center operator.
One way to force a different peering is by complaining to your ISP. Include the server’s IP address in the complain, and their sysadmin might take a look and alter their routing table so traffics going to your data center will go through different route (assuming the ISP is not shitty and have multiple high quality peering AND actually looking at your support request).
Another way is by using a VPN. By using a VPN, you’ll bypass your ISP’s network routing. Your traffic will go through your VPN provider’s data center instead, which have completely different peering partners than your ISP. Try connecting to different country (e.g. Singapore, Hong Kong, Japan, Europe) to see which one is the fastest. For example, your ISP might have a good peering to Hong Kong, so by connecting to a Hong Kong VPN server, you’ll bypass your ISP’s shitty peering to Europe.
Finger cross though. In general, connection between this part of Asia and Europe is not great because there is no direct route. Connection to US is a lot faster in comparison because there are many direct undersea fiber optics links.
I used to oversee WAN and peering operations for a large multi site. Residential ISPs almost never respond to reports of inefficient routes unless you are one of their peers, big business customers, or you really know your stuff and send in a detailed report showing asymetric routes, bad bgp info, etc.
As far as a VPN goes, that probably wouldn’t help either. You will probably increase the number of hops and latency. Your route will still egress your isp gateway, to your VPN provider, then travel over the Internet and to your remote server, while adding additional protocol overhead. Yes, it is remotely possible that there is an improved link from his regional VPN node to his remote provider, but unlikely from my experience with traffic engineering.
Oh man, fucking tell me about it. I remember Verizon support gave the absolute runaround when I was trying to debug why my server was absolute garbage in San Jose vs LA. Took me 3 separate support calls for them to finally do something about it. It also took me a while to figure out it was an ISP issue in the first place.
Actually in my case it did help. I got faster speed to one of my VPS in Paris (OVH) if I use VPN to Singapore first. Heck, even my VPS in Singapore (also OVH) is faster too after connecting to the VPN. My ISP probably really have a bad peering with OVH.
That’s interesting. Any chance your ISP could have been qos’ing streaming video? Although Singapore would be about the one place where a VPN concentrator would help; it is pretty much the big fiber hub in that local region for East, West, North connectivity.
Fiber map
I don’t think they have QoS beyond enforcing soft data cap at 2TB. Another weird thing I notice with this ISP is how bad sites hosted behind cloudflare would perform. It usually fine, but sometimes they have random high latency on random assets (js, css or image files), and when it happens the speed to that site would tank too to just a few hundred KB/s or less. When it happens it’ll magically gone by using a VPN.
Thank you for your reply! I’ve just tested with my VPN and Hong Kong gives me the best speed. (Like 20x more)
I was expecting you’ll get like 2x improvement max. 20x is crazy lmao.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
5 acronyms in this thread; the most compressed thread commented on today has 13 acronyms.
[Thread #160 for this sub, first seen 24th Sep 2023, 08:15] [FAQ] [Full list] [Contact] [Source code]
Welcome to the reason why a competitor to YouTube is almost impossible. Network routing is extremely complicated and short of laying your own cables or having multiple points of presence there’s not much you can do about it.
I’ve only ever used Oracle cloud in an enterprise environment, so I don’t know what features you have available. I’m also much more familiar with AWS. But you should be able to create a proxy endpoint in your present region, and traverse the cloud providers internal network. That would likely improve your streaming. You could also create a VPN endpoint in your current region and terminate your traffic inside your cloud providers network, but that would add protocol overhead.
I would look at tools like iperf to look at your packet loss because being further from your server will increase latency, but shouldn’t impact the streaming unless you also have packet loss.