Is Arch Linux good for real-time Java?

jbpark · 2015-09-21 12:03:21

I have been developing a parking lot management software for about a year.
What I'm recently considering my software is to upgrade it using real time Java (RTSJ).
Would Arch support real-time Java?
Thank you for any comment on my question.
Bye-bye.

Awebb · 2015-09-21 12:15:26

How does a parking lot management software benefit from RT?

jbpark · 2015-09-21 13:31:29

We can get a guarantee on the system response time like how fast the software service a vehicle arriving at a parking lot. For example, it is a good characteristic of a system if it can give a gate bar open command within 0.3 second after a car arrival, I think.

mrunion · 2015-09-21 14:35:56

I thought real-time meant resolutions less than .250 seconds. .3 is not considered real-time is it?

(This is purely an academic question, but I tend to agree with Awebb's questioning the need for true "real-time".)

Last edited by mrunion (2015-09-21 14:36:18)

jbpark · 2015-09-22 00:19:50

By definition, real-time means some limit or restriction in terms of time is regarded highly and according to that system resource is allocated to meet the user requests.
Nowadays, real-time clock is approaching nano-second unit. By the way, I don't want to discuss about the academic meaning of realtime system. What I want to know is whether Arch Linux is a good operating system to develop real-time Java application. Please, keep that in mind great readers.

mpan · 2015-09-22 00:59:26

ArchLinux is a Linux, and Linux is not an RTOS. So basically you're asking if non–RTOS is good for RT applications. The short answer is: no, because it's not an RTOS, so it can't guarantee the primary requirement of RT computing — response times.

Let's restate the question: is a Linux–based OS good for running an application that requires low response times in range of up to 300ms? The answer is: yes. Servers, routers and dozen other device types all around the world are running Linux and respond with predictable times much lower than 300ms despite they execute code much more complex than a simple, fixed procedure required in your case. Given you don't misuse the system by — for example — running a game server or a website on the same machine — there should be no problems. And ArchLinux is probably among the best choices for the task, as it allows you to choose configuration to fit your particular needs.

There is, however, a second issue: reliabity and availability. ArchLinux is a cutting edge, rolling release distro. We're ones, who are in the first lines of users that are being hit by all sorts of bugs and sudden changes. If you're going to use Arch, better prepare good rollback procedures and accept that ocasionally the system may have degraded performance or stop working entirely. Also it's not a install–and–forget distro. While I would risk using it this way on embedded platform that has no access to outside world, I would never allow an out–of–date Arch to be connected to any network (especially company's internal one).

ewaller · 2015-09-22 03:46:37

All I can say is that 250 mS is an eternity. Java might be up to it. In my world, loop times are measured on the order of 10mS. Java would be hopeless for real time hard deadline systems with those kind of deadlines.

mpan · 2015-09-22 04:59:19

ewaller:
Have you ever tested your assumptions about Java's performance or are you still believing in mythology from 90s?

<warning>Language wars ahead!</warning>

trapanator · 2015-09-22 06:37:49

mpan wrote:

ewaller:
Have you ever tested your assumptions about Java's performance or are you still believing in mythology from 90s?
<warning>Language wars ahead!</warning>

There's an extension for real time programming in java. But I second you, the JVM isn't born for this purpose.

Solvialle · 2015-09-22 08:14:47

ewaller wrote:

In my world, loop times are measured on the order of 10mS.

That may be the case in your world, but in the real world, time is measured in seconds, not in siemens.

mpan wrote:

Have you ever tested your assumptions about Java's performance or are you still believing in mythology from 90s?

Even today, GC pauses can reach 100ms, making Java pretty unsuitable for real time.

Last edited by Solvialle (2015-09-22 08:19:01)

ewaller · 2015-09-22 14:28:20

To be honest, no. I have not tested these assumptions. Real time has many meanings. There are hard deadlines and soft deadlines. I am certain Java is fast enough for real time systems in which bad things don't happen if a deadline is missed. I am talking about things like flight control systems, anti-lock braking systems, power generation and distribution, induction motor controllers, air bag deployment systems, In my mind, anything interpreted or running on a pseudo machine is not up to these tasks. Neither is any language where magic happens in the background beyond the control of the programmer. Here I am looking at any language that does automatic garbage collection.

Hard deadline, safety critical systems have to be deterministic. I don't even know where I would start trying to prove that a pseudo compiled language running on an interpreter with automatic background stuff happening could be guaranteed to hit a deadline. Java, C#, and Python are all terrific languages. They can certainly be used to create snappy human interactive soft real time systems. They are not the tools for deterministic, hard deadline, safety critical systems. Ada, C, and C++, and assembly language are. Even at that, these systems require specialized heap management to keep you out of harms way.

Last edited by ewaller (2015-09-22 14:29:36)

Awebb · 2015-09-22 15:06:15

WTF? Can you folks pull up your pants for a second and stay on topic? I was trying to salvage this thread, because it could be a grade A shopping thread, but I was interested in the Java RT topic. However, I have rarely seen such an uninformed clusterfuck in a thread here on this bbs.

Again, for those people who didn't hear the bell:

1. There is an RT extension for Java, dealing with prominent problems like garbage control timings.
2. OP writes software, that controls gates for cars, not some colider timer for the LHC.
3. OP wants to refine the software with RT components.
4. The question was, whether Arch Linux is suitable as a development platform.

mpan has given a good answer: Linux is not an RT OS. I have to add: There are RT kernel, but they are not in the repository.

anatolik · 2015-09-22 15:48:49

mpan wrote:

Let's restate the question: is a Linux–based OS good for running an application that requires low response times in range of up to 300ms? The answer is: yes. Servers, routers and dozen other device types all around the world are running Linux and respond with predictable times much lower than 300ms despite they execute code much more complex than a simple, fixed procedure required in your case. Given you don't misuse the system by — for example — running a game server or a website on the same machine — there should be no problems.

I am not going to speak about Java VM, but when we talk about kernel response time we usually mean process scheduler latency. And many consumer devices need extra-low latency for media and especially audio playback. For example ChromeOS and top Android devices like Nexus 6 have a goal of 10ms audio latency that means ~5ms CPU scheduler latency. To achieve it they run audio services with RT (realtime) priority to make sure heavy tasks do not block audio process. Well, to achieve 5ms latency on consumer electronic devices requires some kernel profiling/debugging.

So I pretty much sure that standard kernel at server x86 hardware can easily achieve 50ms process scheduling latency.

jbpark · 2015-09-28 07:34:37

Thank you very much folks. I learned from you a lot. If I refine my goal here. I am imagining a Parking Manager System having a soft real-time property. My current program shows about 30ms average car passing delay(from the arrival of the first byte of car image to the ACK from the gate bar simulator) on Windows 7 where I assigned priority 10 to each Parking Manager Threads. What I want to do is to decrease the maximum passing delay (well less than 60ms or something).
For your reference, car passing delay includes
- Car image reception (thru 15m ethernet cable, image size: about 60K)
- Registration status checking accessing MySQL DB
- Issuing gate open command to a gate bar and getting ACK from it.
* Later time, we are going to add car tag number extractor from the image this process alone might take 50 to 200ms.
So what I hope is to limit total car passing dealy under 250ms.
Let me tell you the performance we would be able to get in the near future.

Awebb · 2015-09-28 08:00:57

Let*s simplify this even more!

1. Which RT Java implementation do you want to use? What Java VM is this supposed to run at in the end? Is this implementation in the Arch repositories?
2. Since you want to use Arch as a dev platform, and not for running the final product, are you comfortable enough with Arch to install packages from outside the repositories, either from the AUR or even by writing your own PGKBUILD? Are you comfortable enough with Arch to deal with possible problems with your 3rd party packages after a big update?
3. Do you know how to configure, install and maintain a real time kernel (should the VM you use require this to really benefit from your efforts)?

mpan · 2015-09-28 10:50:52

jbpark:
I don't like the smell of words "image recognition" standing near to "real time". It's hard to set a time limit on image analysis algorithms. MySQL smells even worse, as it was not designed to give constrainted–time responses and may generate random delay spikes. Were you considering changing your idea to something asynchronous and condtionally letting cars in fast, but then fully analysing available adata in non–RT environment? If the data is not valid, the gate opening process may be aborted, with a visual and audible alarm provided. For all drivers that have privileges to use the parking lot, this should work seamlessly, for most those who doesn't nearly instantly and few of those, who manage to slip through the gate… well, either they're not important or the actual defence system (namely the lawyer) should be used. A camera that picks up car's licence plates earlier may be helpful too, even if it would give more false positives.

I'm questioning the solution chiefly because it seems like you're trying to setup an RT application primarily with components that don't belong to the real time domain. It may be easier to use non–RT way or only use soft constraints here and there.

Last edited by mpan (2015-09-28 10:57:24)

trapanator · 2015-09-28 11:53:40

I suspect that the application is in not the RT environment.

Arch Linux

#1 2015-09-21 12:03:21

Is Arch Linux good for real-time Java?

#2 2015-09-21 12:15:26

Re: Is Arch Linux good for real-time Java?

#3 2015-09-21 13:31:29

Re: Is Arch Linux good for real-time Java?

#4 2015-09-21 14:35:56

Re: Is Arch Linux good for real-time Java?

#5 2015-09-22 00:19:50

Re: Is Arch Linux good for real-time Java?

#6 2015-09-22 00:59:26

Re: Is Arch Linux good for real-time Java?

#7 2015-09-22 03:46:37

Re: Is Arch Linux good for real-time Java?

#8 2015-09-22 04:59:19

Re: Is Arch Linux good for real-time Java?

#9 2015-09-22 06:37:49

Re: Is Arch Linux good for real-time Java?

#10 2015-09-22 08:14:47

Re: Is Arch Linux good for real-time Java?

#11 2015-09-22 14:28:20

Re: Is Arch Linux good for real-time Java?

#12 2015-09-22 15:06:15

Re: Is Arch Linux good for real-time Java?

#13 2015-09-22 15:48:49

Re: Is Arch Linux good for real-time Java?

#14 2015-09-28 07:34:37

Re: Is Arch Linux good for real-time Java?

#15 2015-09-28 08:00:57

Re: Is Arch Linux good for real-time Java?

#16 2015-09-28 10:50:52

Re: Is Arch Linux good for real-time Java?

#17 2015-09-28 11:53:40

Re: Is Arch Linux good for real-time Java?

Board footer