The last time I compared flash storage to real disks was, admittedly, a while back; but at that time my 512 Mbyte IBM microdrive beat (in terms of seek-time or transfer rate) every flash module I had access to by a significant margin (once the microdrive was spun up). The lag while you waited for the first block you asked for was huuuuge, but if you kept it busy it was faster.
For real speed, you want battery-backed volatile RAM. The cheapest way to simulate this is to have a RAID controller stuffed full of cache, but backed by real disks.
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.
Thus limiting uptime to about 270 years. What's wrong with gettimeofday? Assuming this is a system call, the variation in the time required to execute the syscall will render the extra resolution worthless.
Look at all the work it has to do: context switch (into kernel) + rdtsc + memory access (to get the original tsc value, unless they are counting time from power-on) + subtraction (unless they are counting time from power-on) + division (to scale from CPU ticks to nanoseconds) + context switch (out of kernel).
Phil
Re:Soft real-time Vs Hard real-time
on
RT Linux Patches
·
· Score: 1
If you have a situation where the stakes are high, no hard real-time system can guarantee to keep up, and the statistical assurance of soft real-time systems is not good enough; then you need to find another solution, probably not one involving an O/S: custom hardware, custom software "on the metal", or not using a computer.
Modern hard real-time systems can guarantee responses in scales of milliseconds, and modern soft real-time systems need to be measured in microseconds. The gap is still there, but the odds are that very few real-world tasks are in there...
LynxOS is not Linux. It can run linux programs natively, which is pretty impressive, but it is not a certified real-time safety-critical variant of Linux.
Phil
Mod parent down, -1 troll/-1 clueless
on
RT Linux Patches
·
· Score: 1
So a blue-screen is worse than a panic now?
There are operating systems other than Windows, Linux, *BSD, Unix, MacOS, OS X, OS/390 and z/OS which are far better suited to running the software which controls my car than any of the aforementioned.
This is because an OS designed from the ground up for real-time, safety-critical tasks will always beat an OS designed for running word processors, compilers, business applications, games, or multimedia editing software when it comes to controlling my car.
Phil
Re:Good news, folks
on
RT Linux Patches
·
· Score: 2, Insightful
I agree. It would probably now be easier for a company with an existing RTOS which is massively out-of-date to dump that and fix-up linux, rather than develop their own product further. New entries to the market will still find it very difficult as the path to certification is painful if you haven't trodden it before.
I hope this happens, as a lot of the work they would need to do to get certified would benefit desktop linux, particularly in the realm of hardcore POSIX conformance.
Phil
Soft real-time Vs Hard real-time
on
RT Linux Patches
·
· Score: 5, Informative
There are two types of real-time, soft and hard. This is how you distinguish the two:
Hard real-time says "Do this within the next ## seconds or you might as well not bother as we'll all be dead". Soft real-time says "Do this within the next ## milliseconds if you can, otherwise the sound on the DVD playback might skip".
The parent is talking about hard real-time scheduling, which is what these patches help with. Hard real-time has sharp deadlines, enormous penalties for missing a deadline, and (relatively) long periods between deadlines. Of course, there are short-deadline hard real-time systems, like ABS controllers in cars; however these tasks will usually be handled by dedicated hardware.
Soft real-time is a more interesting topic for desktop Linux, because you aren't usually in a situation where your desktop machine can kill you by inaction. Soft real-time has fuzzy deadlines, small or no penalties for missing deadlines, and (relatively) short periods between deadlines. DVD playback is a good example: if a frame is delayed by a small amount or even skipped entirely the viewer is unlikely to notice provided it doesn't happen too often. Same for games.
NT has subsystems, of which Win32 is just one. Microsoft services for Unix is another, as is their standard POSIX stuff. They don't like to tell anyone the API for writing your own subsystem, if they did I'd be tring to write a UML subsystem.
Good question. Answer: it doesn't. Unless you're RedHat, Novell, IBM, or one of the other organisations with a commercial interest in it.
The problem, as I see it, is that we need these guys on board because they plough a lot of resources into linux and that ultimately benefits us. Thus we need to pretend that the market-share of linux matters, while continuing to realise that it's a worthless metric.
Phil
Re:Good news, folks
on
RT Linux Patches
·
· Score: 3, Insightful
Not necessarily. Those aren't the only two choices: Realtime Solaris and QNX RTOS are also possibilities. Even better, they could stop trying to add DVD players to my engine-management unit. I don't feel there's anything compelling missing from my current car, which has a number of separate systems and a fairly simple (so far as I can tell) EMU which co-ordinates their efforts,
The linux (kernel.org) codebase is not really stable enough to meet the needs of embedded systems. If someone wants to build an embedded controller for a car they'll need a stable embedded OS for at least 9 months before they start production -- 6 months to write the software and testcases, and 3 months to test and debug at a minimum. During this time, there is no benefit to selecting linux -- you aren't getting the new features because you've frozen the kernel; however, there is a downside to selecting linux -- bugs which surface later (perhaps in the testing phase) will not be fixed in the form of a patch to your level.
That suggests you need to buy your linux embedded from a commercial venture, to ensure it's supported. At which point, linux needs to be judged against the commercial competition; it will probably lose that battle because the commercial ones will be certified compliant to a myriad standards, and linux won't be. Certification is important to establish a chain-of-blame should anything go wrong.
These and other real-time patches do not reduce the average time required to do a system-call on your system (they probably increase it slightly).
Real-time priority only has an absolute meaning if you have a single-process system.
What real-time means is that a process or thread with a real-time scheduler (SCHED_RR or SCHED_FIFO) and higher-priority than any other process/thread in the system will complete its work in the shortest possible time. You can use the POSIX real-time calls to eliminate multiprocessing: set the scheduler to SCHED_FIFO and the priority to max on every process in the system and bingo, batch processing.
If you want your gnome or kde desktop to respond more rapidly, you probably need to make several processes real-time. The more real-time processes you have, the less real-time means -- if you set everything to realtime priority you're back to where you are now. Judicious use of SCHED_RR and balancing priorities might net you some improvement, but probably not enough to notice.
There are possibly some benefits to making multimedia apps such as xine run real-time, but unless you have playback problems now you won't notice the difference.
Continuing the same off-topic-topic, I have a question: Are there figures on the percentage of PCs used to play games? I get the feeling most of the companies pushing linux are pushing it for business use, which suggests that the business market is larger...
Phil
Re:Good news, folks
on
RT Linux Patches
·
· Score: 2, Insightful
...there's very little to go wrong.
"very little" is more than I want to be going wrong in my car at 70MPH.
Phil
Re:Good news, folks
on
RT Linux Patches
·
· Score: 2, Insightful
On a serious note, the design decisions for a general-purpose desktop/server OS are very different than for a safety-critical embedded system like an ECU. There is often no reason to have a pre-emptive multitasking OS in application-specific systems, as they only do one thing.
There are embedded OSs for which every line of code has been checked and audited. I think that's a good thing where lives are at stake. For Linux to meet those requirements would require a massive slow-down to the development effort, which would reduce how useful it is as a desktop platform.
Pure x86-64 (long mode) is a lot less of a hack than i686 -- the memory model is flat and is feels a lot RISCier than any prior x86 architecture. Gentoo for amd64 on my 2GHz Athlon 64 (which cost me less than GBP 500 to build) seems around 50% faster than 32-bit gentoo on the same machine.
I would, however, love a PPC64 machine; I've used a fair few of them recently, in the form of pSeries machines running AIX 5.2 and they seem to be about 50% faster clock-for-clock than my Athlon64. As a side note, Unix on PPC seems like a good idea, I wonder if Apple will try it*.
If I were to buy or be given a Mac, I would replace keyboard and mouse with USB PC components and run Linux on it. The OS X GUI seems to me to be an unconscionable waste of a powerful processor.
Phil
PS: Has anyone tried the IBM PPC compiler for OS X? On AIX it can give you some seriously good code (build with -O5 and link with -qipa=level=2).
* I know. But OS X is not Unix, never has been, and probably never will be. I'll believe it's Unix whe the Open Group tell me it is.
Porting all of OS X to x86 would be a huge waste of time, when they could simply take linux, bolt a ported version of the OS X GUI layers on top and sell that. Linux has the x86 hardware support that Darwin does not. Even with that time-saving plan, it's still a dumb idea.
The reason it's dumb is that it would create confusion in the marketplace over which Apple products work where. Apple's strength is in the simplicity of their message, in the knowledge that you can buy the entire contents of the Apple store and it'll all work together. Maybe if they didn't have the G5 processor there'd be a market for some Opteron-based systems, but the migration would be longer and more painful than the m68k->PPC switch.
If they did try this, here's why the market would reject it:
Corporate roll-outs will not happen because Microsoft won't port Office to any non-windows x86 platform.
Home-users will tend to either stick with the OS which came on their PC (windows), be technical enough to use Linux, or own a real Mac.
It might seem like a nice dream, but it'll never happen. Deal with it.
Slashdot Mirror
== ~0x0
Get it right.
Phil
The last time I compared flash storage to real disks was, admittedly, a while back; but at that time my 512 Mbyte IBM microdrive beat (in terms of seek-time or transfer rate) every flash module I had access to by a significant margin (once the microdrive was spun up). The lag while you waited for the first block you asked for was huuuuge, but if you kept it busy it was faster.
For real speed, you want battery-backed volatile RAM. The cheapest way to simulate this is to have a RAID controller stuffed full of cache, but backed by real disks.
Phil
How about a NAS device which connects to the network with (a) Gig-ethernet fibre port(s)?
Phil
Judges in Britain are called Mr Justice $surname. Just like Dukes are His Grace $fullname etc.
Phil
I did.
That page has no results from the DS6k or DS8k.
Phil
One DS6000 is 3U high and stores 4.8TBytes.
One rack is 42U high and can therefore contain 14 DS6000 units.
So the statement of 67.2 TBytes/rack is correct.
Phil
Thus limiting uptime to about 270 years. What's wrong with gettimeofday? Assuming this is a system call, the variation in the time required to execute the syscall will render the extra resolution worthless.
Look at all the work it has to do: context switch (into kernel) + rdtsc + memory access (to get the original tsc value, unless they are counting time from power-on) + subtraction (unless they are counting time from power-on) + division (to scale from CPU ticks to nanoseconds) + context switch (out of kernel).
Phil
If you have a situation where the stakes are high, no hard real-time system can guarantee to keep up, and the statistical assurance of soft real-time systems is not good enough; then you need to find another solution, probably not one involving an O/S: custom hardware, custom software "on the metal", or not using a computer.
Modern hard real-time systems can guarantee responses in scales of milliseconds, and modern soft real-time systems need to be measured in microseconds. The gap is still there, but the odds are that very few real-world tasks are in there...
Phil
LynxOS is not Linux. It can run linux programs natively, which is pretty impressive, but it is not a certified real-time safety-critical variant of Linux.
Phil
So a blue-screen is worse than a panic now?
There are operating systems other than Windows, Linux, *BSD, Unix, MacOS, OS X, OS/390 and z/OS which are far better suited to running the software which controls my car than any of the aforementioned.
This is because an OS designed from the ground up for real-time, safety-critical tasks will always beat an OS designed for running word processors, compilers, business applications, games, or multimedia editing software when it comes to controlling my car.
Phil
I agree. It would probably now be easier for a company with an existing RTOS which is massively out-of-date to dump that and fix-up linux, rather than develop their own product further. New entries to the market will still find it very difficult as the path to certification is painful if you haven't trodden it before.
I hope this happens, as a lot of the work they would need to do to get certified would benefit desktop linux, particularly in the realm of hardcore POSIX conformance.
Phil
There are two types of real-time, soft and hard. This is how you distinguish the two:
Hard real-time says "Do this within the next ## seconds or you might as well not bother as we'll all be dead". Soft real-time says "Do this within the next ## milliseconds if you can, otherwise the sound on the DVD playback might skip".
The parent is talking about hard real-time scheduling, which is what these patches help with. Hard real-time has sharp deadlines, enormous penalties for missing a deadline, and (relatively) long periods between deadlines. Of course, there are short-deadline hard real-time systems, like ABS controllers in cars; however these tasks will usually be handled by dedicated hardware.
Soft real-time is a more interesting topic for desktop Linux, because you aren't usually in a situation where your desktop machine can kill you by inaction. Soft real-time has fuzzy deadlines, small or no penalties for missing deadlines, and (relatively) short periods between deadlines. DVD playback is a good example: if a frame is delayed by a small amount or even skipped entirely the viewer is unlikely to notice provided it doesn't happen too often. Same for games.
Phil
How did he get 0, Troll and not +4, Funny?
/., AOLers are gonna be confused enough anyway.
Okay it might mislead newbs, but this is
Phil
NT has subsystems, of which Win32 is just one. Microsoft services for Unix is another, as is their standard POSIX stuff. They don't like to tell anyone the API for writing your own subsystem, if they did I'd be tring to write a UML subsystem.
Phil
Good question. Answer: it doesn't. Unless you're RedHat, Novell, IBM, or one of the other organisations with a commercial interest in it.
The problem, as I see it, is that we need these guys on board because they plough a lot of resources into linux and that ultimately benefits us. Thus we need to pretend that the market-share of linux matters, while continuing to realise that it's a worthless metric.
Phil
Not necessarily. Those aren't the only two choices: Realtime Solaris and QNX RTOS are also possibilities. Even better, they could stop trying to add DVD players to my engine-management unit. I don't feel there's anything compelling missing from my current car, which has a number of separate systems and a fairly simple (so far as I can tell) EMU which co-ordinates their efforts,
The linux (kernel.org) codebase is not really stable enough to meet the needs of embedded systems. If someone wants to build an embedded controller for a car they'll need a stable embedded OS for at least 9 months before they start production -- 6 months to write the software and testcases, and 3 months to test and debug at a minimum. During this time, there is no benefit to selecting linux -- you aren't getting the new features because you've frozen the kernel; however, there is a downside to selecting linux -- bugs which surface later (perhaps in the testing phase) will not be fixed in the form of a patch to your level.
That suggests you need to buy your linux embedded from a commercial venture, to ensure it's supported. At which point, linux needs to be judged against the commercial competition; it will probably lose that battle because the commercial ones will be certified compliant to a myriad standards, and linux won't be. Certification is important to establish a chain-of-blame should anything go wrong.
Phil
Understand this:
These and other real-time patches do not reduce the average time required to do a system-call on your system (they probably increase it slightly).
Real-time priority only has an absolute meaning if you have a single-process system.
What real-time means is that a process or thread with a real-time scheduler (SCHED_RR or SCHED_FIFO) and higher-priority than any other process/thread in the system will complete its work in the shortest possible time. You can use the POSIX real-time calls to eliminate multiprocessing: set the scheduler to SCHED_FIFO and the priority to max on every process in the system and bingo, batch processing.
If you want your gnome or kde desktop to respond more rapidly, you probably need to make several processes real-time. The more real-time processes you have, the less real-time means -- if you set everything to realtime priority you're back to where you are now. Judicious use of SCHED_RR and balancing priorities might net you some improvement, but probably not enough to notice.
There are possibly some benefits to making multimedia apps such as xine run real-time, but unless you have playback problems now you won't notice the difference.
Phil
It may not be a troll, but it is off-topic.
Continuing the same off-topic-topic, I have a question: Are there figures on the percentage of PCs used to play games? I get the feeling most of the companies pushing linux are pushing it for business use, which suggests that the business market is larger...
Phil
On a serious note, the design decisions for a general-purpose desktop/server OS are very different than for a safety-critical embedded system like an ECU. There is often no reason to have a pre-emptive multitasking OS in application-specific systems, as they only do one thing.
There are embedded OSs for which every line of code has been checked and audited. I think that's a good thing where lives are at stake. For Linux to meet those requirements would require a massive slow-down to the development effort, which would reduce how useful it is as a desktop platform.
Phil
I, for one, don't like the idea of Linux running as the OS for my engine-management system.
The first pile-up after they're introduced and slashdot'll be covered in "So that's what a beowulf cluster of Linux EMUs looks like".
Pure x86-64 (long mode) is a lot less of a hack than i686 -- the memory model is flat and is feels a lot RISCier than any prior x86 architecture. Gentoo for amd64 on my 2GHz Athlon 64 (which cost me less than GBP 500 to build) seems around 50% faster than 32-bit gentoo on the same machine.
I would, however, love a PPC64 machine; I've used a fair few of them recently, in the form of pSeries machines running AIX 5.2 and they seem to be about 50% faster clock-for-clock than my Athlon64. As a side note, Unix on PPC seems like a good idea, I wonder if Apple will try it*.
If I were to buy or be given a Mac, I would replace keyboard and mouse with USB PC components and run Linux on it. The OS X GUI seems to me to be an unconscionable waste of a powerful processor.
Phil
PS: Has anyone tried the IBM PPC compiler for OS X? On AIX it can give you some seriously good code (build with -O5 and link with -qipa=level=2).
* I know. But OS X is not Unix, never has been, and probably never will be. I'll believe it's Unix whe the Open Group tell me it is.
Porting all of OS X to x86 would be a huge waste of time, when they could simply take linux, bolt a ported version of the OS X GUI layers on top and sell that. Linux has the x86 hardware support that Darwin does not. Even with that time-saving plan, it's still a dumb idea.
The reason it's dumb is that it would create confusion in the marketplace over which Apple products work where. Apple's strength is in the simplicity of their message, in the knowledge that you can buy the entire contents of the Apple store and it'll all work together. Maybe if they didn't have the G5 processor there'd be a market for some Opteron-based systems, but the migration would be longer and more painful than the m68k->PPC switch.
If they did try this, here's why the market would reject it:
Corporate roll-outs will not happen because Microsoft won't port Office to any non-windows x86 platform.
Home-users will tend to either stick with the OS which came on their PC (windows), be technical enough to use Linux, or own a real Mac.
It might seem like a nice dream, but it'll never happen. Deal with it.
Phil
Dude,
That's an ASP script, which executes code in a command shell.
There is absolutely no way that runs on the client machine as-is.
If you modified it to be a client-side script, well even the default IE settings would stop that behaviour.
Phil
+1 funny, -1 old reference