2 ms·

> 1 second of a 1080p Netflix stream will use 5x the total daily bandwidth of an IoT device reporting temperature once every 10 seconds Don't have a Netflix fi

by lucb1e 2y ago

> 1 second of a 1080p Netflix stream will use 5x the total daily bandwidth of an IoT device reporting temperature once every 10 seconds Don't have a Netflix file to test with but YT, the video data is 73KiB for the first second (tested by ffmpeg'ing the first second into a new file with codecs set to 'copy'). The page, however, seems to fetch about 9 megabytes in the first second of loading (various features still loading such as comments). Reporting temperature, let's say it's super secure with IV and MAC headers and trailers and another nonce for replay protection (all in all 3x 32 bytes) plus the actual value and other metadata (like which device the report is from) of, say, another 32 bytes, plus IPv6 headers etc. is a couple hundred bytes. Call it 256. There are a gross ten minutes in a day, coming to 144×256 = 36 KiB. Huh, that's pretty accurate when considering video data ("any second" rather than the first second specifically that needs to include the page weight). I had expected the video data to be vastly bigger compared to that sensor reporting just one value per ten minutes. That keyframe+video compression is really quite something; raw 24-bit would be 6 MiB rather than 73 KiB

zamadatix 2y ago
Video services use adaptive bitrate so a 1 second sample will give a very variable estimate. If you can watch the full video and monitor the NIC bandwidth (or, if you don't want to count headers, download the full video and look at the media info average bitrate) you'll get a more consistent number. For 1080p TV type content it's often a lot more than 262 MB/h. Raw should be 192010803*24 = ~149 MB since there are 24 frames in a second, keeping that magic of video compression alive despite the larger base rate. Netflix actually gives the value of 3 GB/hour directly for high definition content https://help.netflix.com/en/node/87 https://help.netflix.com/en/node/87 which is ~833 KB in one second (or about an average 6 mbps plus some delivery overhead) which simplifies things quite a bit though. Encryption is an interesting thought in that LoRaWAN will have encryption built in and the device would typically expect the gateway to handle producing that to IPv6 with traditional encryption and application headers. CTR is used so the packets don't gain much bloat, the minimum size is ~bytes and the maximum size is ~256 bytes. Temperature reports (4 byte float) typically fit in that 50 byte minimal packet category or 432 KB/day reporting every 10 seconds. So I suppose my estimate of 5x was a bit high after all, maybe 1-2x would have been more apt :). But it does beg the question, back to your point, what would that look like in this WiLo protocol? Standard Wi-Fi has a minimum frame size in the air is going to be closer to 100 bytes (minimum Ethernet length of 64 plus Wi-Fi bits). On top of that Wi-Fi doesn't usually act as the gateway like LoRa - does the IoT device now need to package everything in IPv6 + transport security itself and send it over the air with WiLo or is the expectation APs would be more gateway like for these clients? Dunno, wasn't able to read the actual paper in the link to see what is proposed :).

by lucb1e 2y ago

zamadatix 2y ago

Video services use adaptive bitrate so a 1 second sample will give a very variable estimate. If you can watch the full video and monitor the NIC bandwidth (or, if you don't want to count headers, download the full video and look at the media info average bitrate) you'll get a more consistent number. For 1080p TV type content it's often a lot more than 262 MB/h. Raw should be 192010803*24 = ~149 MB since there are 24 frames in a second, keeping that magic of video compression alive despite the larger base rate. Netflix actually gives the value of 3 GB/hour directly for high definition content https://help.netflix.com/en/node/87 https://help.netflix.com/en/node/87 which is ~833 KB in one second (or about an average 6 mbps plus some delivery overhead) which simplifies things quite a bit though. Encryption is an interesting thought in that LoRaWAN will have encryption built in and the device would typically expect the gateway to handle producing that to IPv6 with traditional encryption and application headers. CTR is used so the packets don't gain much bloat, the minimum size is ~bytes and the maximum size is ~256 bytes. Temperature reports (4 byte float) typically fit in that 50 byte minimal packet category or 432 KB/day reporting every 10 seconds. So I suppose my estimate of 5x was a bit high after all, maybe 1-2x would have been more apt :). But it does beg the question, back to your point, what would that look like in this WiLo protocol? Standard Wi-Fi has a minimum frame size in the air is going to be closer to 100 bytes (minimum Ethernet length of 64 plus Wi-Fi bits). On top of that Wi-Fi doesn't usually act as the gateway like LoRa - does the IoT device now need to package everything in IPv6 + transport security itself and send it over the air with WiLo or is the expectation APs would be more gateway like for these clients? Dunno, wasn't able to read the actual paper in the link to see what is proposed :).