Peertube: How many simultaneous viewers are supported for 100Mbit/s bandwidth on a 1080p video?

[lucacalcaterra]

~ 100Mbps

_Originally posted by @Chocobozzz in https://github.com/Chocobozzz/PeerTube/issues/1735#issuecomment-477046012_

With 100Mbps
how many viewers at the same time with a video of 1080P ?

[test2a]

https://www.psav.com/bandwidth-calculator according to this you will server around 600 users with 100 mbps, but if you have p2p enabled, the bandwidth is greatly reduced as all users will be contributing their bandwidth. someone with more experience could give you some figures but essentially going p2p is the way forward

[lucacalcaterra]

https://www.psav.com/bandwidth-calculator according to this you will server around 600 users with 100 mbps, but if you have p2p enabled, the bandwidth is greatly reduced as all users will be contributing their bandwidth. someone with more experience could give you some figures but essentially going p2p is the way forward

Ok but... In this calculator High usage type consider SD Video quality, not in our case that quality is full hd (1080p), so i think users are drastically less

[JohnXLivingston]

The amount of RAM (assigned to cache) and your hard drive speed can also limit performances.

[Avatat]

The amount of RAM (assigned to cache) and your hard drive speed can also limit performances.

In the case of 100 Mbps uplink? Definitely not :)

[lucacalcaterra]

The amount of RAM (assigned to cache) and your hard drive speed can also limit performances.

In the case of 100 Mbps uplink? Definitely not :)

Completely agree. If you have no sufficient bandwith... machine resources cannot save you i suppose

[JohnXLivingston]

Completely agree. If you have no sufficient bandwith... machine resources cannot save you i suppose

I said «limit», not «increase»... Ok, for 100Mbps it should not change anything, but for 1Gbps for example, if you have no cache at all, a single classic hard drive can't follow.

[Avatat]

@lucacalcaterra, it depends on the bitrate.
As I found here, the base bitrate for 1080p30 video is set to 3300 Kbps:

  // For 1080p video with default settings, this results in the following formula:
  // 3300 + (x - 30) * (1320/30)
  // Example outputs:
  // 1080p10: 2420 kbps, 1080p30: 3300 kbps, 1080p60: 4620 kbps

According to this, you can fit ~30 watchers on 100 Mbps uplink.

[markvdb]

With a 1080p60 video, you'll want the bitrate to be between 4.5 and 9 Mbps. That means that assuming nothing else happening on the server, and without any p2p mechanism for lowering bandwidth consumption, your network uplink constrains you to ~ 10 resp. 20 parallel users.

I haven't seen any proper real world stats regarding bandwidth savings thanks to PeerTube's p2p technology yet. This is something I'd like to see more info about in the documentation, as it's supposed to be one of PeerTube's killer features.

Here's what my gut feeling says about bandwidth savings using PeerTube's p2p features:

• The ideal scenario is when one or a few videos suddenly become popular with desktop or laptop users. I'd expect massive bandwidth savings in that case.
• The worst case scenario is probably sustained low intensity demand from mobile users for a wide selection of videos offered.

[rigelk]

@markvdb the "killer feature" is more the redundancy by other instances, as they bring consistently more bandwidth than most small p2p swarms.

[markvdb]

I wholeheartedly agree that this is a killer feature for those instances that federate.

The thing is, even I as a really interested user with quite a bit of relevant technical background had not immediately thought of this. This fediverse concept is so (refreshingly!) new that one doesn't immediately see those wonderful technical advantages.

Would you like me to try and add something based upon the information gained here to the sysadmin section of the documentation?

[rigelk]

@markvdb sure! Having the kind of evaluation you made earlier added to the FAQ would be nice too.

[Avatat]

And I believe that many users will keep their favorite channels' videos and seed them by regular (Web)Torrent clients.
To make it true, we have to wait for a better WebTorrent support in popular clients.

[rigelk]

@Avatat except instances are not all using WebTorrent, since we advise to switch to HLS for better performance.

[test2a]

how about we use a sort of stress test to get some real world statistics? @lukesmithxyz already operates his own peertube instance. Maybe @lukesmithxyz can record a test with how many concurrent viewers can his instance handle on a particular video, the disk write speed, network usage, p2p benefit and just the real world results.

[markvdb]

I tried to summarise some of the findings from this thread, together
with general system dimensioning advice into a FAQ update:
https://github.com/Chocobozzz/PeerTube/pull/3246 . Hope that helps...

Op di 3 nov. 2020 om 08:58 schreef Rigel Kent [e-mail]:
>

@test2a of course, but Framasoft is already at a good place to have that data. Contacting a single other instance is not going to bring any news to the table.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

--
Mark Van den Borre
Hogestraat 16
3000 Leuven, België
[phone]

[Avatat]

we advise to switch to HLS for better performance.

I don't fully understand that, and for me, PeerTube without Torrent support loses all sense. Because, as I said - I believe that users should support their favorite channels, and there is nothing simpler than running (Web)Torrent client, downloading all the videos, and seeding it back to the other users.
Can't we make WebTorrent better, improve something?

@LukeSmithxyz already operates his own peertube instance.

If we "have" access to the real PeerTube instance, we don't need to test anything - it's sufficient to gather metrics like the number of viewers, resolutions which they view, and how much bandwidth they generate, from the instance perspective of course.

[rigelk]

@Avatat I'm afraid there is only so much we can do with WebTorrent. BitTorrent was not optimized for the web, and even with a perfect WebTorrent library, it would suffer from the same playback issues.

[test2a]

If we "have" access to the real PeerTube instance, we don't need to test anything - it's sufficient to gather metrics like the number of viewers, resolutions which they view, and how much bandwidth they generate, from the instance perspective of course.
@Avatat what i am saying is if someone like @lukesmithxyz can do a test, he can check live bandwidth usage from his vps dashboard, the IO usage and same for cpu. view count is not exactly an accurate source of information in the current case when we want to see how many particular viewers can a 1GBPS or lesser data pipe handle or where the bottleneck is, most probably the storage. what about if the network or IO has hit its limits, does the software degrade the performance to some extend, like forcing people to lower resolutions or does the system crash? what if there are some transcoding job running during that time, are they stopped temporarily.
these kinds of tests can be done in a live test with a lot of test data, then we would get a better idea how to improve the software

[Avatat]

In this case, stress testing is a good idea, but I wouldn't do stress tests on a live, production instance :)

If we need, I could set up a test instance, and collect metrics from it. I almost have no resource limits, so we could test many cases.

[tuxayo]

@rigelk

I'm afraid there is only so much we can do with WebTorrent. BitTorrent was not optimized for the web, and even with a perfect WebTorrent library, it would suffer from the same playback issues.

Is there anything in BitTorrent V2 that might help? http://bittorrent.org/beps/bep_0052.html

Or in μTP that just landed in WebTorrent?
https://github.com/webtorrent/webtorrent/blob/master/CHANGELOG.md#v01090---2020-10-22
https://en.wikipedia.org/wiki/Micro_Transport_Protocol

[test2a]

@avatat well in that case go ahead ;-). we can probably get a bunch of people to do tests, cpu tests, network bandwidth, disk IO, CDN, p2p, hls, remote storage, server redundancy. on and on. This should be a fun exercise

and now with work on livestreaming going full steam, we should have some idea about what the instance admins should be concerned about and any steps they need to mitigate any bottlenecks if at all possible.

[rigelk]

@tuxayo no, and μTP is not supported by web browsers.

[rigelk]

closing since we have updated FAQ in #3246.

[lucacalcaterra]

@Avatat well in that case go ahead ;-). we can probably get a bunch of people to do tests, cpu tests, network bandwidth, disk IO, CDN, p2p, hls, remote storage, server redundancy. on and on. This should be a fun exercise

and now with work on livestreaming going full steam, we should have some idea about what the instance admins should be concerned about and any steps they need to mitigate any bottlenecks if at all possible.

I've setup a prometheus and grafana docker stack to monitor loads . But my instance has too few users for now...let see

[test2a]

@lucacalcaterra and @Avatat hi. i just set up a repo https://github.com/test2a/peertubestresstest
its silly but this is what i could think up. lets head up there and organise testing there. we can then report findings to improve the software
edit: i have included the new livestreaming tests in the repo

[Avatat]

Hello!
I will back to this issue at the beginning of the new year :+1: