kierank

The main driver tarball is GPL.

All the tarballs are too complex to follow though, we extract them one by one here: https://github.com/OpenBroadcastSystems/mlnx-driver

This is definitely not correct. For many SIMDable workloads it's possible to achieve order of magnitude improvements over the compiler.

Have you done any work to see whether the NIC hardware packet pacing mechanisms could improve QoE by reducing bursts?

How do you think this will need to be re-architected for HTTP3? Will you do kernel bypass with a userspace stack?

RTP PCM packets timed to a Precision Time Protocol clock.

As most (all?) PC audio devices don't support clock drifting the audio clock to the PTP clock, this application will either resample fractionally or click now and then. So not AES67 in the true sense.

I like the way the author says PAL/NTSC video triggering is obsolete, when it's used every day for timing purposes in a broadcast facility.

I have 5G home broadband in London and receive 700Mbps down with no cap. There's service from multiple operators. Yes we've had teething issues but they were all resolved.

It's more than that even. They lobbied governments to mandate use of this technology such that whenever you buy any device (e.g TV, Phone etc) you have to pay a tax for something even if you don't use it

There's no driver for XQD cards in Linux because of a $100 specification for example

ISO is full of vested interests that don't want hobbyists, the interested public, academics, and professionals to access the documents and be able to implement them at a lower cost.

Nominally to cover the costs of production. However, this is a convenient barrier to entry for Open Source and amateur developers that many companies who are standards participants don't object to.

External access to the bare metal is still possible and thus information can be leaked via Meltdown and Spectre

This is an argument for organisations to go back to being on-prem, running their non-public facing workloads privately.

Uh, there's a whole world of Open Source out there beyond cloud-related tools and JS libraries.

Conveniently those requirements exactly matched the buffers of legacy FPGA designs. Funny that.

Except for minor services such as Verisign's DNS which uses netmap, sure.

Your employer amongst other dinosaur hardware manufacturers is also making this a nightmare to implement in software because of the tiny packet burst requirements (40us). My team will spend thousands of man hours and our servers will waste huge amounts of energy because power-saving can't be turned off in order to hit these crazy requirements.

In 40 years time we'll be still having to comply with this nonsense because some manufacturers didn't want to update their FPGA designs. It's like fractional frame rates all over again.

This is really where the broadcast industry lost its collective mind.

Lots of people missing the point in this discussion, the goal of this is to send Uncompressed video over closed IP networks in a studio for example. I talked about some of the problems at Demuxed last year (referencing BBC R&D's work): https://www.youtube.com/watch?v=A4L5xEXXlas

Yes, in my company we generate and receive uncompressed video in software and get to these kinds of bandwidths from a couple of servers running dual 100GbE: https://www.youtube.com/watch?v=A4L5xEXXlas

Open Media track

Yeah, sorry about that, that site's getting replaced soon.

Yes, easily possible with Infiniband but quite complex with Ethernet.

I'm sure many of them have done interesting things.

But the area I write software on in broadcast has a large number of these engineers holding back progress, most of whom are close to retirement age and now have heavy influence in standards bodies. For uncompressed video over IP for example they propose insanely tight standards such as packets must arrive within ~40us (that's us, not ms) of their allotted time, something very difficult to reach in software. (I will be talking about this at demuxed next week...)

They also insist that legacy artefacts from the analogue era must remain such as VBI stay for another generation to save around 1ms of latency (and of course their precious line buffers).

They are one reason the broadcast industry isn't able to move fast enough compared to the web. As I've explained to them, some of us will have to deal with the mess they have created in 40 years time.

Still selling overpriced broadcast hardware of course and trying as hard as they can to make sure software can't enter their market.

People to write code instead of sitting on their high horse. That and performance as good as c, not c-like, not selective benchmarks, not other nonsense.

Does this have AVX-512 available?

This is similar to what the Wifibroadcast people are doing to make low-cost First-person-video from drones:

https://befinitiv.wordpress.com/wifibroadcast-analog-like-tr...

The Dolphin systems seem more expensive than just buying 4U servers.