Hacker News Reader

Comment by rudolph9 | Hacker News Reader

What OS do you use?

And does the mouse being a ps/2 input vs USB make a difference?

Right now I use Linux, unfortunately a series of corporate games left QnX without a window manager and mostly useful for embedded work. But if someone were to do a 64 bit port of it it would be an awesome workstation OS even today. And that's just the UI, under the hood it was very impressive as well. Extremely elegant and well thought out.

Are there any open source real-time operating systems?

None with a GUI. I never released mine, and it's so far behind the times now it would take major work to get it ported to the 64 bit era and even then it would still be a C based OS.

This would be one way in which the Rust crowd could really make a difference.

Redox seems like a big effort that has at least some of the properties you're looking for:

https://www.redox-os.org/

But Redox is not a real time OS is it? I've not seen it written as part of the design or as a future goal.

It's a microkernel with even the drivers running in userspace, and has its own graphics stack. Seems the ideal setting to go for realtime requirements for the UI. I don't know if they've done anything in that direction but it seems the most well positioned to fulfill the requirements jacquesm was hoping for.

If they can see it through then that's a pretty good development. But there is more to QnX than just 'realtime' and 'microkernel', their whole philosophy about how a cluster of machines should work, the services location and so on is very well thought out. I'd be happier if Redox took some more lessons from Erlang and QnX on board than to do a re-invention. We have a lot of knowledge about systems like that lying around and re-inventing the wheel is fun but also ultimately will lead to having to re-learn those lessons the hard way.

Perhaps you should lend a hand then? :)

Not for large systems, but in the embedded space there is Nuttx (now managed by Apache foundation).

Blackberry BB10 was based on QNX. The UI "feel" was fantastic.

Yes, it was fantastic - minimal, elegant, simple, fast, had low learning curve and everything had a description - even icons in action bar[0]. As their competitors, namely iOS7+ and Android 5+ totally replaced gradients into flat design I was very welcoming the balanced UI redesign on my Z10[1]. However, autocompletion on their touch keyboard was probably the best [2], you had 3-5 suggestion that were spread around on the keyboard and to use them I had to place a finger below and flick it up. On BB Passport it was even more pleasant with physical keyboard - it had small gesture sensor and reacted on swipes in the air above the keyboard.

On the developer side, documentation was also amazing. There are tens of full, working example applications. BB10 used QT behind the scenes (Cascades UI). It had also a Python (2.x) binary on the device among other typical UNIX programs.

[0]: https://developer.blackberry.com/devzone/files/design/bb10/i...

[1]: https://developer.blackberry.com/devzone/design/bb10/10_3_vi...

[2]: https://developer.blackberry.com/devzone/design/bb10/keyboar...

I've been involved with Qt for a long time and got a Z10 as a conference freebie, but the great developer documentation is actually news to me! I prefer to just use phones, I develop for PC hardware for fun and embedded platforms for money these days. At the time, some of my coworkers helped with porting Qt to QNX. I worked on a different Qt project on QNX and I was also duly impressed by the technical quality and elegance of the OS.

The BB10 UI was built on something like QML (the language and runtime) from Qt 4 with their own UI elements and an OpenGL based backend from the acquired company The Astonishing Tribe. They had animations e.g. for slider switches running in the render thread, perfect 60 fps. Qt Quick (the UI framework based on QML, colloquially called "QML") only got an OpenGL backend in Qt 5.

Another very good Qt-based phone OS (after the Nokia N9, got one of these at a conference as well) that failed :(

By the way, the Ford Sync 3 IVI ("in-vehicle infotainment system") is also based on QNX and Qt and it received fairly good reviews. I think I made some tiny contribution to it, if only helping a coworker with something.

> And does the mouse being a ps/2 input vs USB make a difference?

The difference used to be very noticeable. Nowadays my PC doesn't have a PS/2 port.

Is the difference due to changes in the operating system or is it due to differences in hardware usb vs ps/2 inputs?

Mainly due to hardware :

- USB works by polling for changes at fixed intervals

- ps/2 works with interrupts, so the OS will know immediately when hw does something.

What about USB mice with 250-1000Hz polling rate. I can't imagine it's still a problem.

I might even argue that it’s a worse problem.

A kid who asks you 1000 times a second whether you are there yet is going to know within 1ms of when you get there, but I imagine we’d all like being the driver much more if there were no “are we there yet”s and all the kid needed was one “We’re here” exactly when you arrive.

As I understand it, USB2 drivers don’t actually poll — the host controller chip polls the mouse. On USB3, there’s a real interrupt mechanism.

There is in fact an interrupt mechanism for input devices - the host sends a request with a long timeout and the device responds to the outstanding request when it has something exciting to report, or when the timeout is about to expire. This is used frequently in low input rate devices like keyboards. Gaming mice use a high polling rate because it saves you the effort of keeping track of outstanding requests - you just report your current state immediately on every request, and the driver end can decide how often to ask you.

I may need to update my knowledge (I hope I do if you’re right), but from my understanding USB is a CPU-emulated protocol, which is to say there are no pins for “mouse button”, and the CPU has to do some “figuring out what this data means” work for each input event. Then, all this is done on a multitasking CPU that may or may not prioritize the interpretation and processing of that input.

That all being true, having a publish/subscribe model is still not the same as having a true interrupt (and I’d have to do some digging to figure out whether there wasn’t still polling somewhere in the pub/sub pipeline)

While this is intuitively obvious, it doesn't really always play out that way in practice since interrupts can be expensive to handle. For example polled IO can be significantly lower latency than waiting for interrupts.

You’ve piqued my curiosity. Please explain.

Essentially you're spinning waiting for the event that you know must come. Your latency will be on the order of a few clock cycles. Whereas if you use interrupts you are always at least a state-save and state-restore underway before you can service the next event, and likely a lot more than that.

The difference is real time control of stepper motors with crazy speeds when microstepping at 300K steps / second or more interpolating across 5 axis vs moving them at a snails pace of maybe 10K steps / second (on really nice and otherwise idle hardware, miss a single step and your goose is cooked, now you have a cumulative error).

I thought I'd seen a rather dramatic benchmark of this but I can't find it now. (I think it was in the context of io_uring, whose documentation mentions that polled IO is much lower latency and I'd trust Jens Axeboe on that one.)

This intuitively makes sense especially with SSDs and especially with NVMe SSDs: you're not going to have to wait that long, especially compared to the overhead of an interrupt. Also, if you're reading sequentially, once you get one I/O completion you're going to get a lot more in a short timeframe—it makes sense to just poll for those instead of handling every one as an interrupt. Interrupts are pretty expensive (I honestly don't have a good grasp of how Linux interrupt handling works but it can easily be on the order of microseconds.)

It also has some side benefits like preventing the CPU from going into a lower power state for only a short period of time.

Does a serial port poll or interrupt?

If it’s possible to interrupt on a serial port, are there existing examples of how to configure a mouse or keyboard to interrupt over a serial port?

It can do both, but I believe you need hardware flow control working to get proper interrupt behavior for that. I don't think any mice actually did it that way back in the day.

All serial chips that I'm familiar with since the 8 bit days would do interrupts, the only time that I worked without is when we were just using GPIO pins to emulate serial ports.

Depends on how you configure the chip. You don't actually need a chip, you can bit-bang serial just fine if you have accurate enough timing.

Typically a serial port would contain a small buffer which would fill up, upon completion of the first byte an interrupt would be generated and you'd respond to that and read out the register freeing up room for more bytes to be received. Transmit the same but reversed, as soon as a byte had left the shifter in the chip it would generate an interrupt so you could re-use that space for more bytes to send.

This works quite well. Hardware flow control can help in case the OS doesn't respond fast enough to the interrupts, so you don't lose characters.

Reply on news.ycombinator.com