Where can I get nanosecond latency streaming?
A wire
A rather short wire. Short enough for Grace Hopper to give away to students during lectures.
Gazette: Cloud-native millisecond-latency streaming
31–40 of 53 posts
Re: Gazette: Cloud-native millisecond-latency streaming
#32Gazette is at the core of Estuary Flow ( https://estuary.dev ), a real-time data platform. Unlike Kafka, Gazette’s architecture is simpler to reason about and operate. It plays well with k8s and is backed by S3 (or any object storage).
Interesting, are there any open source alternatives to tinybird? https://www.tinybird.co/
I've wrote one, but it's not public/production-ready yet. Built on top of clickhouse as well.
Basically pipe is just a collection of WITH statements with some template processing.
Re: Gazette: Cloud-native millisecond-latency streaming
#33Earlier quoted context omitted.
Yes, it really is. The problem is it takes a lot more than one frame for most modern software to change a pixel on the screen. I'm sitting in Hawaii on wifi right now and the first random US mainland server I pinged responded in 120ms, which means sending only took 60ms. Now say you're running a 30 Hz game with 2 frames of input lag, and you've already lost before even considering the input lag of the monitor itself.…
> OS window compositors generally add a whole frame of input lag globally to every windowed app. Is there a way to verify this is the case? In X11 Linux specifically. Also does variable refresh rate like freesync help with this?
Not exactly what you ask for, but some reviewers measure it like this: https://www.rtings.com/monitor/tests/inputs/input-lag
Re: Gazette: Cloud-native millisecond-latency streaming
#34What's the use case for millisecond-latency streaming? HFT? Remotely driving heavy machinery? Anything else?
A millisecond is an eternity in HFT.
Re: Gazette: Cloud-native millisecond-latency streaming
#35Earlier quoted context omitted.
No it isn't. John Carmack found a tv ten years ago that had 200-300ms of latency due to all its post processing and wrote an essay about it. That doesn't mean that it is "frequently" faster to send packets to other continents than change pixels on screens. It doesn't even apply to modern tvs set up for latency, let alone computer monitors.
Yes, it really is. The problem is it takes a lot more than one frame for most modern software to change a pixel on the screen. I'm sitting in Hawaii on wifi right now and the first random US mainland server I pinged responded in 120ms, which means sending only took 60ms. Now say you're running a 30 Hz game with 2 frames of input lag, and you've already lost before even considering the input lag of the monitor itself.…
No it really isn't. Are you really doubling down on this by talking about software that has built in latency?
Any game that runs at half the frame rate of a cheap TV and has an architecture designed to not draw frames immediately has nothing to do with what you're saying. That would be like someone deciding to send packets every 100ms and claiming 100ms extra latency.
All of this is forgetting that packets can be fired off whenever but with vsync on, frames need to wait for a specific timing. If you take that away you can set pixels with less latency.
Re: Gazette: Cloud-native millisecond-latency streaming
#36> the broker is pushing new content to us over a singled long-lived HTTP response
Any plans to support websocket?
https://gazette.readthedocs.io/en/latest/brokers-tutorial-in...
Re: Gazette: Cloud-native millisecond-latency streaming
#37Gazette is at the core of Estuary Flow ( https://estuary.dev ), a real-time data platform. Unlike Kafka, Gazette’s architecture is simpler to reason about and operate. It plays well with k8s and is backed by S3 (or any object storage).
Interesting, are there any open source alternatives to tinybird? https://www.tinybird.co/
Not an exact match, but https://github.com/soketi/soketi might work for your needs (API-compatible with https://pusher.com )
Re: Gazette: Cloud-native millisecond-latency streaming
#38Earlier quoted context omitted.
You don't need io_uring. For many workloads being slow & inefficient is acceptable, isn't awful. But gee I'd rather start from a modern baseline that has high levels of mechanistic sympathy with the hardware, where things like network & io work can be done in an efficient async manner. Why do I need io_uring? Because it sounds awful and unhackerly to suffer living in a much lesser worse world.
if you want mechanistic sympathy and low latency then you can't really do much better than dpdk; uring is still going through the very generic and abstracted kernel networking stack.
Every time we've used something built on dpdk in production it was horribly bloated and slow.
I'm pretty sure this stuff is optimized for marketing benchmarks, not the real world.
Re: Gazette: Cloud-native millisecond-latency streaming
#39From reading the docs, this has an IMO surprising design decision: the “journal” is a stream of bytes , where each append (of a byte string) is atomic and occurs in a global order. The bytes are grouped into fragments, and no write spans a fragment boundary. This seems sort of okay if writes are self-delimiting and never corrupt, and synchronization can always be recovered at a fragment boundary. I suppose it’s neat…
:wave: Hi, I'm the creator of Gazette.
> But this seems quite brittle if multiple writers write to one journal and one malfunctions (aside from possibly failing to write a delimiter, there’s no way to tell who wrote a record, and using only a single writer per journal seems to defeat the purpose).
Yes, writers are responsible for only ever writing complete delimited blocks of messages, in whatever framing the application wants to use.
Gazette promises to provide a consistent total order over a bunch of raced writes, and to roll back broken writes (partial content and then a connection reset, for example), and checksum, and a host of other things. There's also a low-level "registers" concept which can be used to cooperatively fence a capability to write to a journal, off from other writers.
But garbage in => garbage out, and if an application correctly writes bad data, then you'll have bad data in your journal. This is no different from any other file format under the sun.
> there’s no way to tell who wrote a record
To address this comment specifically: while brokers are byte-oriented, applications and consumers are typically message oriented, and the responsibility for carrying metadata like "who wrote this message?" shifts to the application's chosen data representation instead of being a core broker concern.
Gazette has a consumer framework that layers atop the broker, and it uses UUIDs which carry producer and sequencing metadata in order to provide exactly-once message semantics atop an at-least-once byte stream: https://gazette.readthedocs.io/en/latest/architecture-exactl...
Re: Gazette: Cloud-native millisecond-latency streaming
#40Earlier quoted context omitted.
Is it safe to say that a single thread using io_uring should be as fast or faster than N threads performing the same set of I/O tasks in a blocking manner? In other words, can you count on the kernel to use its own threads internally whenever an I/O task might actually need to use a lot of CPU?
If you saturate the submission queue with CPU-bottlenecked tasks, it defeats the value-add of io_uring - at that point, you might as well replace your kernel-space thread pool with a user-space one.
Sure, but that approach forces you to consider/research just how much CPU your I/O tasks may or may not require. What if I'm not sure? How CPU-intensive is open()? What about close()? What about read()?
It would simplify my design process if I could count on io_uring being optimal for ~all I/O tasks, rather than having to treat "CPU-heavy I/O" and "CPU-light I/O" as two separate things that require two separate designs.