Re: Potential HD Mouse Extensions API Specification [ETA by 2025]
Posted: 27 Feb 2021, 06:11
Chief Blur Buster, do you think you can convince the USB IF (Implementor Forum) to change the fundamental smallest Temporal Resolution for their Micro-Frames to be < 125 µs Micro-Frame in a future USB revision?
If I'm a betting man, they probably don't care about latency like we do and don't see the urgency or need to make a breaking change to the USB protocol / standard to have their Micro-Frame get smaller than 125 µs.
That's why I made the topic Impending Input Bottle Neck in Wired Communications Protocols (USB)
I'm serious about wanting some of us to resurrect IEEE 1394 (Commonly known as FireWire) and take the existing technology, knowledge, and specs and iterate and improve on it.
Since FireWire was already at 8 kHz for it's main clock and all packets are sent Isochronously & Asynchronously to memory directly within 125 µs, that gives us a chance to work on improving the future versions of the Open Source Spec to what we need with finer Temporal Resolution Packets to be sent.
I'm talking about getting the base packet's "Temporal Resolution" to improve from:
125.0000000 µs
_65.5000000 µs
_31.2500000 µs
_15.6250000 µs
__7.8125000 µs
__3.9062500 µs
__1.9531250 µs
__0.9765625 µs
with each major iteration
And since the last patent on IEEE 1394 has recently expired, I think there is a easier chance to improve on the tech with a open source / open standard group taking over and improving on it.
Kind of like how 3D printing came about from expired Dot Matrix printer patents, we can do something amazing with low latency interfaces.
We can maintain existing backwards compatibility with current FireWire devices & protocols and just move forward on improving the latency.
FireWire S400 had 4 KiB packets every 125 µs
FireWire S800 had 8 KiB packets every 125 µs
We can improve on it with 1600 Mbps speeds use 8 KiB every 65.5 µs
Next iteration can have 3200 Mbps speeds use 8 KiB every 31.25 µs
And so forth.
Yes, bandwidth will improve for the connection, but that isn't the main focus, the main focus is the low latency and continuous stream of packet data to the host and directly to memory in a safe way that can't be abused.
We have more knowledge of the dangers of DMA and how to secure against it, we can use that to improve on the IEEE 1394 protocol and make it better & safe.
If I'm a betting man, they probably don't care about latency like we do and don't see the urgency or need to make a breaking change to the USB protocol / standard to have their Micro-Frame get smaller than 125 µs.
That's why I made the topic Impending Input Bottle Neck in Wired Communications Protocols (USB)
I'm serious about wanting some of us to resurrect IEEE 1394 (Commonly known as FireWire) and take the existing technology, knowledge, and specs and iterate and improve on it.
Since FireWire was already at 8 kHz for it's main clock and all packets are sent Isochronously & Asynchronously to memory directly within 125 µs, that gives us a chance to work on improving the future versions of the Open Source Spec to what we need with finer Temporal Resolution Packets to be sent.
I'm talking about getting the base packet's "Temporal Resolution" to improve from:
125.0000000 µs
_65.5000000 µs
_31.2500000 µs
_15.6250000 µs
__7.8125000 µs
__3.9062500 µs
__1.9531250 µs
__0.9765625 µs
with each major iteration
And since the last patent on IEEE 1394 has recently expired, I think there is a easier chance to improve on the tech with a open source / open standard group taking over and improving on it.
Kind of like how 3D printing came about from expired Dot Matrix printer patents, we can do something amazing with low latency interfaces.
We can maintain existing backwards compatibility with current FireWire devices & protocols and just move forward on improving the latency.
FireWire S400 had 4 KiB packets every 125 µs
FireWire S800 had 8 KiB packets every 125 µs
We can improve on it with 1600 Mbps speeds use 8 KiB every 65.5 µs
Next iteration can have 3200 Mbps speeds use 8 KiB every 31.25 µs
And so forth.
Yes, bandwidth will improve for the connection, but that isn't the main focus, the main focus is the low latency and continuous stream of packet data to the host and directly to memory in a safe way that can't be abused.
We have more knowledge of the dangers of DMA and how to secure against it, we can use that to improve on the IEEE 1394 protocol and make it better & safe.