- Posts: 62
- Thank you received: 3
Bandwidth consumption
5 years 2 months ago - 5 years 2 months ago #905
by kerberos
Bandwidth consumption was created by kerberos
I have identified that the opensky client is creating approx 0.8 MB traffic per minute, where most of it is in "send" direction
This is calculated a bandwidth of 1.5 GB per day or 45 GB per month.
This is up to 10 times more than other clients and can cause trouble for people who wan to run the devices on a metered internet connection e.g. using the mobile network offsite
Why is this required?
This is calculated a bandwidth of 1.5 GB per day or 45 GB per month.
This is up to 10 times more than other clients and can cause trouble for people who wan to run the devices on a metered internet connection e.g. using the mobile network offsite
Why is this required?
Last edit: 5 years 2 months ago by kerberos.
- strohmeier
- Offline
- Administrator
-
Less
More
- Posts: 393
- Thank you received: 93
5 years 2 months ago - 5 years 2 months ago #906
by strohmeier
Replied by strohmeier on topic Bandwidth consumption
Simple: because we receive and store every single message that is received and decoded. Yes, that's significantly more bandwidth (also for us, not to mention storage requirements) but that's the point of this whole undertaking as stated right on the front page. That raw data enables later large-scale research into many domains that require more than just (even fine-grained) trajectory data, i.e. "where does an aircraft fly". For trajectories, researchers could just use any of the other sites out there, but they wouldn't be able to, say, develop wind and temperature models [1] or analyze collision avoidance systems in depth [2]. It's the whole raison d'être of OpenSky. We are keenly aware it's not an option for everyone to feed OpenSky because of that, but it's not something we can compromise on. We rather have fewer feeders who can provide that sort of data instead of basically duplicating all the other pure tracking sites out there.
[1] www.lenders.ch/publications/conferences/IPSN18_3.pdf
[2] www.cs.ox.ac.uk/files/11077/DASC_2019.pdf
[1] www.lenders.ch/publications/conferences/IPSN18_3.pdf
[2] www.cs.ox.ac.uk/files/11077/DASC_2019.pdf
Last edit: 5 years 2 months ago by strohmeier.
5 years 2 months ago - 5 years 2 months ago #907
by kerberos
Replied by kerberos on topic Bandwidth consumption
Thanks for quick response and the technical details behind it.
However you should make this transparent to your feeders. There is a number of people who are using the devices isolated for better coverage by using a mobile network. Even some home connections do have a limit (higher, but this additional traffic should be considered)
In most cases this has a limited bandwidth which will fail in a worst case scenario feeding properly 24/7 because the connection either stopped completely or is working with reduced bandwidth, unable to feed properly due to that.
However you should make this transparent to your feeders. There is a number of people who are using the devices isolated for better coverage by using a mobile network. Even some home connections do have a limit (higher, but this additional traffic should be considered)
In most cases this has a limited bandwidth which will fail in a worst case scenario feeding properly 24/7 because the connection either stopped completely or is working with reduced bandwidth, unable to feed properly due to that.
Last edit: 5 years 2 months ago by kerberos.
5 years 2 months ago #916
by bibdun
Replied by bibdun on topic Bandwidth consumption
There are 3 things you can do.
1. Send multiple contacts in a single packet.
2. Compress the packet.
3. I am pretty sure there are contacts which do not need to be sent on.
I'm basically giving up on this due to the high bandwidth requirements.
Not everyone is on multiple Gig links.
1. Send multiple contacts in a single packet.
2. Compress the packet.
3. I am pretty sure there are contacts which do not need to be sent on.
I'm basically giving up on this due to the high bandwidth requirements.
Not everyone is on multiple Gig links.
The following user(s) said Thank You: kerberos
