Slashdot Mirror

Looks like it.

This function is a non-portable RTLinux extension. gethrtime returns the time in nanoseconds since the system bootup. This time is never reset or adjusted. gethrtime always gives monotonically increasing values. hrtime_t is a 64-bit signed integer.

The actual resolution of gethrtime is hardware-dependent. It is guaranteed to be better than 1 microsecond.

Odd that RT Linux is the first hit in google actually.

6. Q: How well does it work?

A: Quite well. Worst-case times are about 15microseconds between the assertion of an interrupt and the starting of the realtime handler on a generic x86 PC, and better on the Alpha and PowerPC platforms. These times are close to the hardware limit, yet all of the power of Linux remains easily accessible to the realtime programmer.

There are two major projects whose purpose is to create a hard real-time kernel running on top of Linux -- RT Linux and RTAI.

There are also others, but they are a lot more immature than those two.

1. Mono has nothing to do with Linux development.
   
   
2. Linux is not trying to be a Windows clone, instead it is a rather successful Unix clone.
   
   
3. An operating system that addresses computing in a way that MSFT's don't? Do you mean like SE Linux or RTLinux?

RTLinux is a hard real-time operating system that handles time-critical tasks and runs Linux as its lowest priority execution thread. In RTLinux, a small hard-realtime kernel shares one or more processors with standard Linux. This allows the system to run accurately timed applications to perform data acquisition, systems control and robotics, while still serving as a standard Linux workstation. - from RTLinux

I wouldn't say you're stupid, but isn't typing "www.rtlinux.org" easier than posting a question on Slashdot?

Typically the larger projects are the ones that aleady have so many people involved, in the interests of sanity, code must be rejected and some questions in mailing lists ignored. However, smaller projects are EXTREMELY rewarding and really collaborative on a truly cool level.

If you want an example of some small projects that work well, check out the COMEDI project as well as the RT-Linux project.

Also, if you want to join something with the potential to be cool and sexy, go to rtlab.org and join my project! We are developing a generic scientific experiment interface. The software is built on top of RT-Linux (real-time OS's are sexy!) and the COMEDI data acquisition drivers. This is a great opportunity to work on sexy code, as you get to do both Kernel level programming when working on the RT thread, and user-level programming for the user interface (we use Qt/GUI). Join now! Email me at calin@rtlab.org if you are interested in finding out more about the software and/or think you can help! -Calin

There is a lot of good stuff here. Some of the more useful and general-purpose patches -- such as VLAN, TUX, and Software Suspend -- should get a chance to become mainstream. The various IPC and speed improvements should make it in, too.

There's currently a debate over which real-time scheduler is the best. Personally, I'd like to see it resolved in the same way as the other options with choices: let all of them be integrated into the mainstream, and let the user select which one to use, either at compile or boot time! I'd like to see an option in the kernel configuration, asking what real-time scheduler you wanted: MontaVista, RTLinux, RTSched, Linux-SRT, RTAI, DWCS, something else, or simply the default.

Linux needs a real-time scheduler today. Currently, things become choppy whenever it decides to service the system in some way, such as syncing the disk. Playing movies, audio/video recording, burning CD's, even playing games would benefit from real-time support. I hope that this can become mainstream in 2.6!

Super eurobeat from Avex and Konami unite in your DANCE!

[ http://www.microsoft.com/presspass/press/2001/jun0 1/06-04UshersPR.asp ]

" Windows XP offers an easy-to-use, real-time communication experience, enabling people to communicate and connect like never before," said Bill Gates, chairman and chief software architect for Microsoft.

The above is a parody, and isn't necessarialy meant to harm the company in question. Just in case you couldn't notice...

--

a) their small, minimalist design allows for fewer bugs, greater flexibility, etc, etc(all the old arguments you hear about them)...

No arguement about the flexibility. I look forward to one day having enough free time to play with and enjoy that feature.

The minimalist design allowing for fewer bugs is somewhat a red herring. By focusing on a smaller piece of code, you'll naturally find fewer bugs there vs. a larger piece of code (all else being equal). Once you add in the sevvices, the bug count is back up to where it was.

There is some benefit that at least the bugs are isolated from each other, and thus more limited in the damage they can do. However, if the service is a critical one, the system will still be dead.

b) the fact that very little code is in the kernel allows for better realtime performance. The less time that must be spent in kernel mode(where interrupts are disabled), the more time can be devoted to actual work and servicing devices.

Interestingly, RTLinux is a good example of that approach. It makes the entire kernel pre-emptable for the real time services.

L4 and EROS kernels are even faster than previous generation microkernels.

L4 is a good example of improvements in the area of microkernels. It's on my list of things to check out when I get that mythical free time. EROS is also very interesting. A microkernel with persistant objects to replace nearly everything! It's also on my list.

IMO, overhead penalty invloved with context switching in a u-kernel OS is totally worth it, especially for a desktop system. And QNX proves that it can be done right.

Our conclusions are not too far apart. I'm not so much saying that microkernel is bad or that it won't work, I just don't think it's time is here just yet, and Mach in it's current form isn't it. I do look forward to the HERD being ready for prime time. The 1.0 version will probably perform poorly vs. Linux, but it will provide a good platform to build from in the Free Software world. (yep, it's on my list :-)

-- Eat your greens or I'll hit you!

RTLinux is a soft realtime platform if I'm not mistaken.

RTLinux is hard real time.

A better comparison is QNX to Cygnus eCos, the Linux-preemptive RT/Linux kernel/system, WindRiver's VxWorks, etc... It is really unfair (for both sides) to compare a "lightweight" OS for small, embedded systems against a be-all/do-all behemoth like Linux (which does have a minimum size limitation).

I'm sure you'll be able to find some overlap, but it's really a question of "which is better for this application" and not "which is better period".

-- Bryan "TheBS" Smith

Try Real Time Linux. It has the normal linux with X, ethernet, etc running as the lowest priority task. And it's open source...

On the Real-Time Linux mailing list, this entire load of piffle was discussed in February, when EETimes ran an article. I'm sure you can find archives somewhere around http://www.rtlinux.org/.

Poor Mr. Wilshire was misquoted in the original article, and if you search for his emails in the archives, you will see the thread. Well, since I can't be bothered finding the URL, I'll post his message to the list verbatim.

I have not asked permission to post this, so I hope that Mr. Wilshire will accept my apologies.

Date: Tue, 15 Feb 2000 11:05:25 -0800
From: Phil Wilshire
To: Nicholas Mc Guire , "rtl@rtlinux.cs.nmt.edu"
Subject: [rtl] Re: article on the Workshop

Nicholas Mc Guire wrote:
>
> Hi All !
>
>http://www.eetimes.com/story/OEG19991220S0029
>
> VIENNA, Austria - Developers of embedded-Linux systems
> ...
> also decided to back Cygnus Solutions' EL/IX as a common applications
> programming interface (API) for embedded Linux.
>
> Nearly 100 developers and programmers attended the grass-roots Real
> Time Linux Workshop here last week, and all but one voted to proceed
> with the use of EL/IX as their API.
>
> ...the other non-sense sniped...
>
> I conclude that there where two workshops in vienna
> on that peter and me organized and obviously a second one
> that we did not know of...
> It is simply stupid to belive that puting fals information
> out on the net will help push EL/IX as a standard API .
> I guess a view people out there did not understand the
> ideas of open source and even less the intent and spirit of the
> realtime linux workshop in Vienna.
>
> since the article claims to be based on information from
> phil whilshire maby he could comment on it .
>
> D'ehre
> Der Herr Hofrat

Willingly I will comment. There was some consderable misunderstanding in the way this article was presented.
I was NOT allowed to see the results of a brief telephone interview and much that was printed was a shock to me.
I do think that the statements about adopting EL/IX unchanged were inferred from another source.
My statement was that we would work together with CYGNUS to help develop EL/IX into something we all could use.

This is a warning to all of us not to accept telephone interviews and publication without prior approval of the result.

I have been waiting for this backlash in the community and hope that my true motives in all this are clear. If one of us make a mistake we are, in general, merciless.


I want Linux to succeed and I want Real Time Linux to succeed.
i have devoted many man hours in my own time to helping the community in many ways.
I want the Real Time Community to grow stronger and develop the way forward for this technology rather than leave it in the hands of commercial entities.
This includes Cygnus.
If they push EL/IX as the "Open Source" API and it bears no relationship at all to what is really needed then we all loose. We need to work together with everyone, Cygnus included, and produce what we need as an API. We also cannot present to the waiting users out there a confusing variety of API's. The Real Time Linux community is a very strong force we have what it takes to make this happen.

I apologise to the community for any misrepresentation . Those that know me will confirm that I am VERY careful in making any such statements. I will continue to be even more careful in the future.

I hope that we can resolve this with a simple public flogging.

regards
Phil Wilshire
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail majordomo@rtlinux.cs.nmt.edu OR
echo "unsubscribe rtl " | mail majordomo@rtlinux.cs.nmt.edu
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/

is the linux patches at here complient with this API spec?
--

I hope that "most slashdot readers" did not find this segment of the market to be a "revelation." I would rather call it Real-Time than appliances. If the kernel works great in an embedded environment, there is an infinite market out there with less stringent requirements. Some vendors make a good living just providing an environment that bridges these worlds. Having Linux as this common thread makes sense to me. I encourage the slashdot community to seek more of these revelations.

Real-Time Linux may yet become part of the
standard kernel. It's such a good concept that
it definitely should.

Marko