Slashdot Mirror
RTLinux Boasts Single-Digit uSec Responsiveness
An anonymous reader writes "A Linux implementation delivering single-digit microsecond responsiveness on 64-bit dual-core AMD Opteron processors is being demonstrated at the Embedded Systems Conference in Boston this week. From the article: "According to FSMLabs, an AMD Opteron 265 dual-core system running RTLinux can deliver guaranteed interrupt latencies of no more than five microseconds, with scheduling jitter of no more than eight microseconds, even with Linux under a heavy load." Heck, with numbers like that it seems like Linux could run circles around XP Pro for audio/video apps such as streaming, recording, and playback!"
Anyone know how this compares with BeOS? I was under the impression that (certainly for it's time) BeOS was the mutt's nuts for audio/video work.
Heck, with numbers like that it seems like Linux could run circles around XP Pro for audio/video apps such as streaming, recording, and playback!"
You say that like it's a hard mark to hit.
beos did not handle media well because of low latencies, it handled media well because of thoughtful media system design. beos actually has poor latencies and response times in a number of areas, it just accelled at scheduling and prioritisation
First, it's on a desktop system with a desktop CPU running really fast. Getting 5us interrupt latencies is not a difficult feat for an RTOS. Yes, it may beat Windows XP's latencies, but on a desktop OS, latency isn't typically a big deal (does XP even claim to be realtime?).
Second, what are the limitations? How does RTLinux handle priority inversion? How does it stack up to something like OSE-RTOS or GreenHills? Just how preemptible are those ISRs?
And finally, what is the performance penalty? Just because you are servicing interrupts at lightning quick speed, it doesn't mean you get a boost in speed. It may mean you have to lower the priority of many system services.
I am skeptical of RTLinux's claims, though the numbers seem to be in order. Maybe it is just their actions in the past (FSMLabs) that has colored my opinion of them.
Jesus saved me from my past. He can save you as well.
Why would you need fast interrupt speed for multimedia? If anything, a real-time kernel would reduce efficiency for multimedia. You need raw CPU for that, not fast interrupts. RTLinux is for applications where you need the computer to react really fast, like in science experiments.
>Heck, with numbers like that it seems like Linux
>could run circles around XP Pro for audio/video
>apps such as streaming, recording, and playback!"
To me the numbers announced are on par with hard real-time constraints, for which there are a lot more interesting and critical applications than a/v streaming, recording and playback!
How about anything the pure real-time kernels can do, such as running a car, plane, spaceship, etc ?
I'd be interested in seeing the figures for XP X64 with SMP on the same system...
The difference between spam and poop is that you don't have to dig through septic tanks looking for real food. -- Me
I'm not into audio/video stuff at all, but my girlfriend is, she's a graduate from one of the most prestigious 3D colleges in Europe, classmates are working with Pixar, Saab, BMW and so on in 3D modelling. And other courses in that college were orientated around pro video, pro audio and other stuff with cutting edge computer needs.
And all these people I chatted with, did not ever give as much of a crap about hardware. They use applications, they use Final cut Pro, or Maya, or PRman, or Logic Audio, or Cubase or Digital performer or whatever, they all have apps they like. But they aren't seeing the hardware as any kind of big deal. If they need something done faster they get a new PC.
Linux needs to get the applications before it can boast about the microsecond speed advantages.
According to the article, this OS is touted for its extremely fast responsiveness, presumably to any interrupts from external devices (since it is targeted at an embedded platform) etc. because of the way it 'reserves' the CPU for such activities.
This decreases latency (response time to some stimulus, in the most general definition) but does not increase the total throughput.
For embedded applications such as perhaps a data acquisition system that might want to sample one external circuit's output when another circuit sends a line high, this is perfect because the system can react extremely quickly and thus increase the accuracy of the data.
However, it is conceivable that because of processor reservation, you will lose some of the power available to you. Thus, you cannot say for sure that it can run circles around XP based on simply this feature...especially for a feature like encoding a video which doesn't depend much on interrupts.
There might be other reasons for why Linux is a better platform for streaming, playing, recording, or encoding video. But I doubt this is it. Real-time OS's are aimed at embedded applications, usually systems that combine both external hardware and software...
Apparently it is. Despite all the latency patches for the 2.6 linux kernel "(X) Preemptible Kernel (Low-Latency Desktop)", "[*] Preempt The Big Kernel Lock", and that Timer frequency thing, linux handles A&V like CRAP. None of the Debian/RH machines I use at work are any better than my home (Gentoo) machine, either.
I love linux, but Windows handles A/V like a champ (with the exception of, perhaps, editing the two, bug I have no experience in this area...) And I'm not going to go out and buy a dual core opteron just so my linux box can play video and sound without stuttering under a load.
Try playing WoW on a dual head setup with video playing on one screen and the game in the other. Windows handles it amazing well, while linux chokes horribly. This can be somewhat alleviated by reniceing the process, but that kind of defeats the purpose of the whole "low latency desktop" thing, doesn't it?
IMHO, audio is perhaps the one place where choice hasn't helped linux.
I use rtLinux at work (university biomed research) and we use this to collect data and drive equipment on a tight schedule. Regular linux runs as the lowest priority. Development at this level is tricky - I learned not to development code on test system because I got tired of rebooting and restarting editors when I screwed up. :)
Am I the only one who thinks ScuttleMonkey's comment on this story is a bit...out of place? Why would you need one-digit microsecond scheduling jitter for multimedia applications?
For 'real' real-time applications, this is gold though, especially now that many more people realize Linux' potential in this area - heck, even the good folks over at Windriver have realized that now, and they used to laugh at us Linux folks.
If a train station is a place where a train stops, what's a workstation?
Heck, with numbers like that it seems like Linux could run circles around XP Pro for audio/video apps such as streaming, recording, and playback!
Umm.. why compare a REAL TIME operating system to Windows?
"no more than 5 microsecs" is fine, but -- how the sustained rate, and what about garanteed completion time ? (they have a low boundary too: they shouldn't execute too fast either).
Windows could not even handle what I wanted to do when developing http://www.entertainmentwatch.com./ Linux was the only way to go to use Mambo, which rocks hardcore!
Adobe Premiere Pro?
Apple Final Cut Pro?
Cakewalk/SONAR?
I won't see anything that compares to these, but I may have over looked.
http://www.fsmlabs.com/rtlinux-is-unfair-by-design .html
Well - stop rebooting it! It's not windows which need a reboot after every application ran!
Really, My development machine at work has an uptime of 35 days, at that was a reboot because my cdrom burner went off and never came back.
That its ridiculous that RTLinux needs to run on a dual-core AMD Opteron in order to achieve those latencies ? How many RTOS *can't* do that ? How many embedded systems will be created out of dual-core AMD Opterons, considered that they are usually made out of bottom dollar hardwares ?
Don't hope you'll get this on your desktop anytime soon. This is RTLinux. Know what RT meants? Real-Time. That's a system in which you can guarantee the responsiveness.
But there's a catch: at development, you control all aspects (hardware and software) of that system. If just one component fails real-time requirements, you card castle crumbles.
In a desktop system, you can't control all aspects. That video card you just bought just added a little latency to your system, and it's not realtime. What is that program?
Never heard of it, but it fails RT requirement.
So, this is cool... but in the embedded systems field. Don't start comparing it to Windows XP and thinking you'll get it on a desktop Linux.
Misleading titles? Inflammatory blurbs? Keep in mind that Slashdot is a tabloid.
5 us latency is good and all, but that is VERY fast hardware. A better measure would be using a system somewhat comparable to an advanced industrial controller, which is where RTLinux is meant to be used, IMHO. Something like a 667 MHz VIA processor board(no affiliation) is rather high-end in that respect - rate it on such a system, and your numbers will actually mean something.
To those who compare this to XP - you've completely missed the mark. XP is not, will never be, and has never been claimed to be realtime. There really is no comparable offering from Microsoft at the moment, with Windows CE coming closest in terms of realtime capability. I doubt that 5 us is within reach on ANY hardware with WinCE, though.
Black holes are where God divided by zero
that "real time = real fast."
;)
Often, nothing could be further from the truth.
I wonder why this seems to escape Slashdot article authors.
Wait... nevermind
+++ATH0
>Heck, with numbers like that it seems like Linux
>could run circles around XP Pro for audio/video
>apps such as streaming, recording, and playback!"
Yeah, but how feasible is it to run RTLinux just to watch DVDs?
But usecond resolution would be usefull for higher-frequency data processing and control.
RTLinux, last I checked, was a real time OS completely unlike Linux that was able to run a Linux system as a subtask, much the same as Xen would. Linux tasks would have the same scheduling latency they would normally have, but programs running on RTLinux would have higher scheduling precision. However, you give up a lot in order to achieve low latency - the system doesn't have many of the features most programs would expect to be present, so don't expect, say, Open Office or Firefox to benefit from running on such a system.
On the other hand, maybe my understanding is wrong or out of date (if so, then someone please correct me).
From TFA: FSMLabs will demonstrate its real-time Linux operating... Flying Spaghetti Monster? Umm.. Intelligent Designed OS... Great
"Most of the major studios use Linux -- such as DreamWorks with more than 1,500 Linux desktops and 3,500 Linux servers. The MovieEditor Conference is an all-day event on computer-based filmmaking in downtown Los Angeles on August 3rd. Studio technology chiefs and other experts discuss ongoing work using Linux in feature animation and visual effects. Presented in collaboration with LinuxMovies.org."
/ 1551250&tid=126&tid=106
http://linux.slashdot.org/article.pl?sid=05/07/27
It has to go down to 3usec just to keep up with my double click speed.
My wife's sketchblog Blob[p]: Gastrono-me
Of course, all of these would be a lot MORE real-time if someone would update that damned PPS patch, so we had a good nanosecond clock to work with. When you get to single-digits, small fluctuations (which can't be in units smaller than 1) will be relatively large to the blocks you're working with (in this case, units of 5, making fluctuations smaller than 20% unmeasurable and fluctuations greater than 20% likely).
With a working PPS patch, you'd have a thousand times greater accuracy on the clock, therefore random errors would be a much smaller - and much more quantifiable - amount of the time spent, allowing for better adjustment and therefore better Real-Time.
Now, would anyone NEED nanosecond accuracy? Hell, no. Would it be COOL to have nanosecond accuracy, just because? Well, of course! So long as it didn't detract from anything, then anything geekier is automatically sexier.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I've been using the GPL version of RTLinux for years now, in high-speed data logger and control systems in the geophysics and biomedical fields. The problem (difficulty) is not commodity hardware (we've used off-the-shelve P1:P4, AMD, and Via boxes), it's writing the RTLinux drivers, or kernel modules, to communicate with and control the devices, such as a/d cards, serial devices, etc. That is, you can't take an application written for a non-RTLinux system, plop it on an RTLinux box, and expect hard realtime response -- you have to rewrite it.
Does anyone know how this compares to actual real time OSes like QNX RTOS?
Please correct me if I got my facts wrong.
What 10 million?
5 usec (that's micro-seconds[1], not milli-seconds) is 1/20,000th of a second, so if you take a 2 GHz CPU it's more like 2,000,000,000 clock cycles * sec^-1 divided by 20,000 sec^-1=100,000 clock cycles...
[1] which should have a mu instead of an u before the second, but SlashDot doesn't seem want to display µ...
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
You DO need realtime responsiveness as soon as you start doing mulitmedia OUTSIDE THE STUDIO. Sitting on your ass in your bedroom ripping DVDs doesn't require realtime response, but processing video LIVE does.
So does mixing audio. Because high or unpredicatble interrrupt latency leads directly to longer buffer times needed to overcome jitter, which is a pain in the ass when you are laying down tracks. Every new track based on the previous tracks gets just a little more skewed, which you have to stop and correct.
Ugh... of course, 5usec is 1/200,000th of a second, so it's actually 10.000 clock cycles... *slaps himself*
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
i really hate when people confuse network latency with CPU latency or driver latency or poor software running on the application layer.
unfortunetly (or fortunetly) you're also the only person to have read the fine article.
Science : Proprietary , Knowledge : Open Source
It says 5 microseconds, while the clock period is around 500 ps. That's 10,000 cycles, not 10 million.
Opus: the Swiss army knife of audio codec
No, you're not the only one mate. Scuttlemonkey musta got some good crack ;-)
Just consider that 5.1 = 6 channels at 96khz sample rate 24bits/sample, means each bit in a serial stream is about 60nS. Sure you can thread your processes, use asynchronous buffer blocks, but I've only mentioned audio. Throw video into the mix as well, then consider what is needed to keep DAC noise low. Oh, sorry it was streaming he mentioned. How many simultaneous streams at 2400kb/s? Ah, internet streaming, of course "you have to expect droputs".
The 888/24 is one of Digidesign's legacy interfaces, ie. no longer supported. The spec figure for clock jitter is less than 40 picoseconds RMS 22Hz-22kHz, D/A SNR 107dB unweighted Find me some hardware running Linux with figures like that and we'll talk multi-media.
I think you have *way* too many zeros in your comment -- a 1Ghz machine runs 1,000 clock cycles in a microsecond (multiply by N for a N-GHz cpu). However, I agree that it sucks that thousands of clock cycles are required to respond to an interrupt, even one generated by the cpu itself (such as by the internal clock).
slashdot will destroy his spirit, or at least it's destroyed his homepage already...
Icecast on Debian Linux already has great performance for streaming, if not "realtime" interrupts
I have no idea why you would need anything remotely like 5 microsecond latency for "streaming." When you stream media you have a buffer at the client end. If you are a bit late with a single packet it shouldn't make any difference.
But I do wonder about loads people have seen with standard datacenter server HW. For example, how many 128Kbps streams can a P4/4.3GHz/128K-cache/512MB-RAM Icecast2 server stream from the local filesystem (preencoded to 128Kbps MP3) to a 100Mbps ethernet, if that's all it's running under the Debian v2.6.10-5-686 kernel/OS?
I would hope this machine would be more than up to the task of saturating a 100Mb link. You need very little CPU and very little disk throughput. I wouldn't be surprised to find out that a 486 with a PCI 100 megabit NIC could do the job just as well.
Still, of course, a multi-threaded system won't be able to do real time for every single sample in an audio stream. Video is far easier, you only 30 FPS or so, so all you need is to do the page switch with some accuracy.
I've emailed them asking them what they've done to satisfy section 3 of the GPL version 2. I await their reply with interest.
If you were blocking sigs, you wouldn't have to read this.
Moreover, having a second core doesn't make interrupt handling latency decrease
In fact it may even increase the interrupt latency. The fact that a single CPU system could process a network interrupt faster than a dual CPU system was one of the reasons the Horseshoe cluster was build using single CPU systems.
Do you care about the security of your wireless mouse?
There are high-end commercial tools that are available for a lot of money, and some major production houses use them. However here's one for you: Find a Linux alternative to Final Cut. Basically you need a solution for around $1300 dollars that is a full featured SD/HD editor, effects, DVD authoring and so on. Oh and it also needs to be easy to use (Final Cut is extremely user friendly).
Now on the Windows side, you can get software that plays in the same league. It's questionable if it's as good as Final Cut, but it's in the same Ballpark. Sony Vegas would be one, the Adobe Video Suite would be another. Basically, if you are an individual or small orginization looking at doing smaller budget work, there are reasonably priced solutions to meet your needs. They are professional, powerful, and easy to use (I particularly like Vegas). They are also flexable in that you can do DV work, streaming media, HD (consumer and pro) and so on. You can fully produce a web demo in RealMedia in the same program you make a show for broadcast.
Now look at those Linux utilities listed. Some of them are just plain wrong (Fusion for example lists only Windows 2000 and XP as supported OSes, not Linux). Most of the ones that are real are in the "if you have to ask it's too expensive category" as in they don't even list prices on the web, it's a "contact us for a quote" situation, in fact I couldn't find prices for any commercial editor. One of the few programs I actually could find a price on was Shake (which is Apple and thus also works on OS-X) and it's $3000 and it's JUST a compositor. Vegas and Final Cut and the like do compositing as well, admittedly not near to the level of Shake, but they do it well enough for most low level work.
Now as for the free software, well if there's good stuff out there, I've never seen it. The AV editing situation on Linux is abysmal last time I tried. Maybe I was just unlucky, maybe I've never been pointed to the right products, but even when I got stuff working, it was a distant second. I tried the Planet CCRMA Fedora image, which has everything you need all installed (it's designed to give you an AV workstation) and all configured, and I found that Vegas installed on vanilla Windows was much better.
So it seems that you can use Linux, when you go really high end, but then the OS isn't so much of a big deal. You are likely buying enterprise Linux (most of the stuff only provides support under things like RHEL) and thus paying for licensing anyhow, and the software cost is enough to dwarf the OS cost. Many times it's even turnkey solutions (meaning they provide the entire hardware/software package).
Great, but what about the rest of us? What if you work for a school and want to do online education videos? What if you are a band that wants to make low-budget music videos? What if you are a film student that wants to make indy digital videos?
It seems that Linux would be the way you'd want to go since the whole free thing, but it seems the tools available for it are the very least suited. They just don't match up to the commercial tools for Mac and Windows, and the commercial tools are things you might actually use later. If you go on to work broadcast TV, it's a good chance you may run into a Final Cut workstation. Even some Hollywood movies are being done in Final Cut these days. Not likely you are going to find a Cuisene station, to them it's worth the grand or two in software and OS licenses to have something that easier to use and more powerful. Please also note that it's the ONLY free video editor listed on the site you linked to.
So I guess when I have a choice between Vegas, which does multi-track audio and video editing, effects, titles, compositing (somewhat simple but not bad) motion tracking, audio effects, streaming input output, DV input/output, MPEG input/output, and so on for like $400-500 all in one easy to use package, or Cuisene which works only with DV and is hard to use, Ardour for sound which is a pain and lacks effects, probably something like POVray to render 3d effects since nothing built in and so on for free, I'll take Vegas. The $500 plus a $100 for Windows is worth it for the fact that I can just easily get shit done.
It is the best player available for windows. It is the only player that can play crippled DVDs and VCDs without crashing and it is the only one that can handle partially downloaded files. It also handles a very large formats as opposed to a very small subset provided by the proprietory vendors.
I am sure we will get other apps soon. Its not like the Movie industry is switching to Windows for their movie production.
I know you're trolling and all, but I have boot times of less than twenty seconds for my P-II/400. This beats every other consumer OS that will run on the system. If I were to strip out as many services as possible, I could get that down to about 5 seconds, although I wouldn't have a very useful system.
What about smartphones then? It will need a real-time OS, since I still want to pick up my phone while my kernel is recompiling (or watching a movie for that matter).
That being said, is there any complete open source product out there with such guaranteed latencies?
Free beer is never free as in speech. Free speech is always free as in beer.
But I wonder if they're going to be paid a visit by the Linux trademark police.
If you were blocking sigs, you wouldn't have to read this.
Doesn't RTLabs, claim to hold a "patent" on running the Linux Kernel as a 'task' under a 'real time' kernel?i cles/moglen.html
http://www.fsmlabs.com/openpatentlicense.html
http://www.aero.polimi.it/~rtai/documentation/art
I don't think all of that has much to do with Linux. Yes, video update speed has traditionally been slow and irregular on Linux. However, if you go and analyze what's going on, you see that it involves quite a number of context switches and too many copies and (colorspace) conversions, most of them related to X. Copying and colorspace conversion are obviously expensive, but context switches can be expensive, too (they are on x86).
Much of the expensive stuff can be eliminated by using features such as XVIDEO and OpenGL, which (1) allow you to write directly to the video hardware, avoiding copying and some context switches, and (2) handle a lot of stuff in hardware (colorspace conversion, windowing, and for OpenGL even rendering).
With well working XVIDEO support or OpenGL support, it's not uncommon for things to run faster and smoother under Linux than they do under Windows. So it seems that X provides not only the problem, but also the solution.
Please correct me if I got my facts wrong.
Serious question: why should the computer be up & running (and consuming electricity) when you are not using it? So you could show off your uptime-figures? And my computer is pretty loud so I don't want to have it running when it's not needed.
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
Maybe I should run 'modprobe unrealistic_expectations' like most Linux users on Slashdot? It should load up modules 'fantasy_usage_scenarios', 'readit_inapost' and 'snd_fanboywhine'.
Heck, even servers get reboots now and then to load new kernels. Unless you like running insecure code...
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
In the university lab where I help to research the development of NQR (http://en.wikipedia.org/wiki/NQR) to detect explosives/narcotics/bioagents, our main experimental system's computer is a Pentium 90 MHz running Windows 3.11 and DOS.
We boot into 3.11 because the operational code was developed using Borland C++, but need to exit 3.11 into DOS for the "RT" interrupt capability of the driver for a A/D data acquisition board. You can imagine the hassles that this has given us. It has become a problem just to upload data to our servers.
Our main problem in upgrading the system is that the board hasn't been supported for years, a driver for anything past DOS was never developed, which was proprietary. AFAIK, the company doesn't even exist, and so its unlikey that we could even find someone who might have the code for us to inspect.
IANACoder of much of anything extensive beyond MatLab scripts, and so the idea of myself (or anyone else currently in the lab) wrtiting a new driver for the A/D board. Furthermore, I wouldn't even know where to start to point someone in that direction.
So, I've a muti-part question here, and any input would be appreciated.
1) Would this "rt" linux be up to the task, assuming that drivers are available. (I'd guess that it would, but that's a guess.)
2) How hard would it be, in general, to write a linux driver for this vague hardware?
The easiest solution to our problem might be a complete revamp of the experimental system, but this would cost us well beyond what our current research funding is. Note that wikipedia link, we're one of the few groups worldwide doing NQR research. Such little interest in the field means little funding available, so we'd prefer to be able to reuse as much of the current system as possible.
Any thoughts, ideas, recommendations? Thanks!
Or maybe not.
Sometimes at night I imagine the darkness is filled with horrible things with too many teeth, like Julia Roberts.
RTLinux is not a desktop distribution. It is designed for systems control. Like robots that build cars, small delays in response time could see welds done in the worng spot etc. This way with RTLinux, you can move robotic arms faster without fear that the OS will update too slowly to catch the data about where the arm is etc. It really has little to do with watching videos on WinXP. Most Linux distros IMO already do that better ;)
Uh huh. So you say. I think you should take a look at that: http://www.linuxdevices.com/
Apparently, lots of people don't realize yet how much Linux is being used commercially in the embedded market, and its use is just growing.
The services real time processing provides are often not required by the needs of an application. This is the case when low-latency servicing of events is needed but the complexity and potential deadlocks of a real time os are not desired. Video/Audio recording is an example of an application that needs low latency but not necessarily real time os services.
a rd.pl?Action=ShowPost&Board=realtime&Post=6&Idle=0 &Sort=0&Order=Descend&Page=1&Session=
AFAIK (well just from reading this)
http://www.linuxdevices.com/cgi-bin/board/UltraBo
a) You should be able to do what you want with this, and possibly any, version of real time Linux. The real question is what what level of responsiveness do you need?
b) Get the make/model info for the card and see if there isn't already a driver for it. If there isn't, it may be possible to get a driver written, either by finding documentation on the card, or reverse engineering the DOS drivers. Any more of an answer is kind of moot because there isn't enough information in your post.
Could you use a different/newer/supported card for this experimental system?
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
We solve this in a number of ways. For most live stuff the answer is simple: Don't use a computer. You can crow about a realtime system all you want, I'll take a video switcher any day for live video please and thanks.
For audio recording, the software takes care of this. The latencies are known to the software (if it's worth a shit) quite precisely. I tool aorund with MIDI and frequently I'll use a combination of hardware and software synths. The software ones are rendered directly to a wav file, the hardware one is recorded digitally via S/PDIF. Now normally I run my setup with pretty conservative buffering, there's about 50ms of input latency, which is an extremely noticable amount of latency. Yet, when all is saind and done and the tracks are loaded up in multi-track, you hear no latency. Why? Well the software knows about the input latency and corrects for it.
The importace of low latency comes in to play when you are doing sound on sound, musicians monitoring themselves via the software. Then it needs to be low, or they'll get screwed up. No problem, a good audio setup can get 5ms or less of latency. If you really wnt low latency, again screw the computer. Monitor via your mixer, just have the computer record.
Also I'm not so sure a RTOS is what you want. Remember RTOS is all about gaurenteeing time slices to all devices. It basically says you will get a time slice of at least x ms a minimum of every y ms. Ok, great, but what if your critical device needs more time? What if your sound input needs 2x ms to service it or needs it every y/2 ms? A non-realtime system can put off other stuff to do that, a RTOS can't since the whole design is reliable scheduling.
- work with an engineering faculty to design the replacement board,
- require spec's as part of the manufacturing contract, or
- that the specifications are placed in escrow to be released if the company goes into bankrupcy, or is no longer able to provide duplicates at specified rates.
If you need to keep the existing card, find some modern hardware that has a suitable bus. It is probably an ISA card, so your choices may be limited by that; a quick search on Froogle shows that they can still be purchased in modern motherboards.I suspect that any version of Linux could be suitable, provided you run it with minimal background tasks. Consider running the program on Linux 2.0 in single-user mode. It sounds like that would be an improvement on the current setup
Also, you may find that your existing DOS drivers work on Linux using dosemu
Good luck.
> Heck, with numbers like that it seems like Linux could run circles around XP Pro for audio/video apps such as streaming, recording, and playback!"
/. and make "m$ suckz" and so-called "Funny" comments.
Heck, with brain like that it seems you could run circles around a tree without realizing you're not getting anywhere.
Just look at his piece-of-shit submission - the only interesting part is one that was copied from TFA and the rest is a "I'm a moron" type of comment that tells everyone how stupid and clueless the submitter (and the editor) is.
If had any brains and if he bothered to spend just 10 minutes to make a quality submission, he'd have read an article or two related to RT OS and he would:
a) compare RTLinux to published latency figures of some other (open or proprietary) soft- or hard-RT OS
b) would not make that idiotic Windows XP comment since it is completely irrelevant
c) would make a link to best of those reference articles that he reviewed prior to submitting the story
Being such, the article only does a good job in making tons of likely-minded folks gather at
The editor should have edited out the stupid Windows XP comment or replace it with something meaningful. Not having done that, he hasn't done his job and I can only pass to him same compliments that I had for the submitter.
Everyone, learn how to skip stupid submissions, it's a great way to save time not stupefy yourself.
The problem is that on certain days you can skip pretty much everything.
Further proof that the Flying Spaghetti Monster is capable of intelligently designing not just biological organisms, but computer technology as well. Well done, FSM, I'd like to shake your noodley appendage.
You see? You see? Your stupid minds! Stupid! Stupid!
Wow I can't wait for my microwave to run 64bit code! Right now, nothing make more sense than Opteron for embedded work.
I gather that RTL is mainly beneficial for servers, etc. But would this low latency also benefit desktop users and the responsiveness of the UI? I mean, are clicks, etc. also of the type of interrupt that would be handled more quickly???
BenCurry.net
First off, you can go back to sleep in peace, for I am neither hurt nor feel inadequate (and if I did after reading your vomit-like prose, *that* would be definitely inadequate). And Linux is definitely not "my OS". I wonder what "owning an OS" would mean anyway...
Lol, yet another big troll like I love them, who doesn't know any better than insulting people and does not care to do some basic research on the topic... I should not even reply to this, but what the heck, this could at least help readers decide for themselves before giving the benefit of the doubt to the ruder one.
Just to name one company, which, by the way, is implanted worldwide: FSMLabs. Its activity revolves around RTLinux and RT-BSD. And you'd have found its name very quickly if you had cared to look at the site I mentioned a little bit. It even has the news about RTLinux the original author of this Slashdot article talks about... Anyway, even though RTLinux seems to be used most in research projects, it does have practical industrial and medical applications as well. Just take a look there, for instance: http://www.fsmlabs.com/case-studies.html
Of course, you may not feel the need to check this out, nor check out your own sources. Heck, you don't even feel compelled to post as anything else than an anonymous coward...
Have you checked out COMEDI?
(http://www.comedi.org/)
Comedi is a generic programming framework for most current DAQ-boards. If your board is obsolete, but still have the HW-specs for it, writing a driver is always possible. The package includes examples for how to accomplish this.
Further; if you need RT-scheduling, it supports RTAI.
A couple more points:
* Single-digit microsecond latency is completely overkill for the general-purpose application stuff he's talking about.
* Much as I like RTLinux (and much as I dislike Windows), RTLinux is a *real-time extension* for Linux. It is not stock Linux. It is most comparable to something like RTX, a real-time extension for Windows.
* Many people here seem to have a "real time systems are like regular systems, just *better*!" impression. Real time systems (and this *includes* RTLinux) make *serious* sacrifices to gain in one particular area -- latency. There is a reason that people don't use real-time systems on a day-to-day basis. They generally impact throughput greatly. They have very tough constraints on what you can do -- you can't just "run Quake as a real-time task under RTLinux" -- you're limited to doing not much else besides memory manipulations and some very limited forms of I/O in real-time. Real-time systems exist to do things like control work, where you don't give a damn about much of anything but the latency in telling a servo to change speed. They suck for most other things.
* Linux (not RTLinux, totally different applications) *is* arguably better in the latency department. My co-worker at work is doing some simulation work that depends on something that someone else wrote that really should have been done using real-time code. He's working in a truly real-time environment (with PLCs and high-speed motors involved). He's using Windows XP, and sees worst cases of something like 20 millisecond latency even with realtime scheduling on a high-speed box -- IIRC, Linux 2.6 can currently get around a quarter that. (FWIW, 2.4 had significantly worse latency than Windows.)
The editor should have edited out the stupid Windows XP comment or replace it with something meaningful. Not having done that, he hasn't done his job and I can only pass to him same compliments that I had for the submitter.
My concern is that it leads to even more misperception of real-time systems.
Remember, people. The preempt patches for Linux are a good thing for pretty much everyone -- 2.6 impacts general-purpose application latency at a level that a humany might pick it up (audio, video games, whatever). RTLinux is a completely different beast, and is a toolkit for designing highly specalized systems. There are damn few people on here who need to use RTLinux, and those who do know who they are.
Any program relying on (nontrivial) preemptive multithreading will be buggy.
I tend to think of Real-Time ISRs taking about 15 cycles to respond. However that can typically only be achieved with a super complex Real-Time OS that looks like this:
Oh well, what the hell...
Okay, I'm going to clear this up near the top of the article.
RTLinux is a *Real Time Operating System*, a tiny kernel that runs the Linux kernel. It has a rather sexy interfact that allows you to write the non-RT code that interacts with it in the regular, Linux way. You also don't need to hassle with Wind River salesmen to use it. This makes it good.
There seems to be a significant misperception here as to what an RTOS is, and the extremely misleading article summary makes it worse.
An RTOS is an extremely specific tool designed to allow someone to write code with very harsh restrictions on it with very low latency. This is almost always used for control applications (telling servos when to fire accurately). You can't "run Quake in RTLinux" and just get more accurate times -- code running as real-time in RTLinux can do very little besides memory manipulation, basic computation, and some extremely limited I/O. RTOSes are powerful tools for solving a very limited set of problems which very few people on Slashdot have.
RTLinux lets you write very simple, limited code that runs in a real-time mode, and run it on the same machine as regular Linux applications. And communicate with them. That's it. Doesn't do anything to improve the regular ol' Linux applications.
RTOSes give very low latency to the code they run -- something happens, code to handle it gets fired off very quickly. Microsecond latency (*not* millisecond) is completely overkill for the kind of general-purpose video or whatever work that people here are thinking of, unless you're trying to build some sort of specialized embedded system that does something to a real-time feed -- and your hardware's going to be very specially designed for this.
There's a good reason that we don't use RTOSes in day-to-day work. They have bad throughput, and you can't *do* very much with them in real-time. They're good if you specifically have a latency constraint from the time one sensor triggers to the time I/O goes out to another device. They aren't going to avoid audio dropouts on your GNOME desktop. Real-time is a *bad thing* from most people's standpoint -- oh, and they're really easy to accidentally hang.
If you want something to get excited about for general purpose use, look at the preempt patches for 2.6. 2.6 Linux has better latency than Windows XP (2.4 had worse). This is not RTLinux, this is regular-ol-Linux-which-can-run-Quake. My understanding is that ALSA and JACK represent improvements in the general-purpose latency area.
Unless you are designing application logic for robotic control systems, or are interfacing with PLCs, RTLinux really doesn't benefit you (okay, I'm sure there's someone out there that has a different application, but Joe Hacker with his Gentoo box doesn't benefit directly from this).
Every time realtime systems come up on Slashdot, misperceptions of 'em seem to get worse.
Any program relying on (nontrivial) preemptive multithreading will be buggy.
If you *do* want to do high priority stuff on your box, both (regular) Linux and (regular Windows, without getting RTX or any Windows RTLinux equivalents) have "realtime" scheduling options (see the "Realtime" option in Windows Task Manager, or the sched_setscheduler(2) man page under Linux). These aren't actually hard realtime, but give you all the fun of being able to lock up your box (as per realtime systems do) without losing the ability to still run general-purpose applications. You won't get single-digit microsecond latency, but you won't be worrying about audio dropout either, and you get to do fun things like use general-purpose libraries, use sockets, use virtual memory and all the other stuff that you can't do in real-time code under RTLinux.
Any program relying on (nontrivial) preemptive multithreading will be buggy.
Imagine a Beowulf Cluster of these!
So, I've a muti-part question here, and any input would be appreciated.
1) Would this "rt" linux be up to the task, assuming that drivers are available. (I'd guess that it would, but that's a guess.)
2) How hard would it be, in general, to write a linux driver for this vague hardware?
A stock linux kernel will do everything you want. No need for RT extensions, DOS wasn't/isn't/doesn't. I take it your borland code just calls inb() outb(). This is easily ported to linux. The hard part will be getting the board vendor to give you the firmware commands.
Read this article to get started:
Write a Linux Hardware Device Driver
Enjoy,
It's just the normal noises in here.
I find myself wondering about my perception of this timing business in general. I still think about usecs being fast, but nowadays machines run at lets say 2GHz.
That means that one cycle takes 0.5 nanoseconds. While cycles are easily measurable with the CPU internal cycle counter, I'm still stuck in usec land.
If you wonder how many cycles fit into 5 usec with a 2GHz Processor you find that the OS has 10000 cycles to spare.
While I'm happy that RTLinux is faster than WindowsXP (but not surprised (it says realtime damnit)) I wonder what its doing with all those cycles.
Je me souviens.
beware: chrt'ing a badly implemented application may provoke a kernel hang
--
WebDSign: thrust the Web by trust
Back to GP's post; It has been noted that it is in fact 10.000 cycles and not 10 million. I still think that is a lot. IIRC, an interrupt took about 30 cycles on the Amiga, or 300 including swithing thread context.
Or did i miss what the fuss is all about?
Yes, the submitter's jab at Windows XP is somewhat inflammatory and misguided, but so are the comments of all the self-proclaimed RT experts who always seem to come out of the woodwork at the first mention of "real-time."
The RT experts say "multimedia isn't real-time." Multimedia is absolutely real-time. If you miss a deadline for supplying the sound card with an output buffer, you get clicks and dropouts. If you miss a deadline for pulling input buffers, you lose recorded data. No, it won't launch a nuclear missile, but it is clearly a real-time operation.
The RT experts say "but multimedia doesn't need scheduling latencies that low." It's true that single digit usec latencies are beyond what most multimedia systems require, but single-digit msec responses would be extremely welcome. In fact, if you've ever followed JACK (JACK Audio Connection Kit) development, you'll discover a community of people who invest significant effort tuning their kernels and environment exactly so they can get these kinds of latencies. If you're dragging sliders on a mixer while playing back a multi-track recording, you care very much about latency. If you're using your computer as a real-time effects processor, you care very much about latency.
This is why the XP comment, while somewhat inflammatory, has some truth to it: the lower-latency your operating system, the more useful it is for these kinds of tasks. Who cares if it calls itself a "real-time" operating system or not -- what I care about it what's on my desk!
The RT experts say "no fair comparing RT Linux with Windows XP, a non-realtime system." I'm not sure why we take it as a given that this dichotomy must continue to exist. Why do we accept that general purpose operating systems can sit on an interrupt for an unbounded amount of time? If a high-priority interrupt comes in, I want it right now!
Computers are really fast these days, but latencies do not decrease in proportion to CPU speed. What good is my 20GHz Pentium VII if arbitrary drivers still grab locks for tens or hundreds of milliseconds?
Rehashing the same old lines isn't insightful, it's backward-looking. Yes, I know that "real-time is about guaranteed deadlines." But current CPUs are so fast they could probably render a mandelbrot set before they give me the CPU and I wouldn't notice. But as long as they're holding these locks, I'll never see the benefit.
My theory has always been that if the GUI responds, the user will get much less frustrated. So...why don't make the OS Kernel and the GUI run in real time?
Imagine if you never again had Windows lock up so badly that you could not find out who was hogging the processor, and kill the process.
Andy Out!
It's not "funny," it's true.
± 29 dB
Sequencing low latency MIDI is MUCH easier with VSTi instruments, as is making changes, since you aren't forced to re-record the track as audio from your device every time you make a change. The reason I say it's better to re-record the tracks after changes is to normalize sound, and get the mix at least somewhat right so you know what it's going to sound like. Quite often a live feed is too quiet to be used for an actual recording, and normalizing audio realtime is pretty much impossible. Compression is a different story, which can have a similar effect, but not exactly.
Also in general with VSTis you can get much better sound than with an external device, since you have a program that's designed to make whatever type of sound you're using very, very well. For example, the Bosendorfer grand piano VSTi, or Steinberg's The Grand both produce much better sound than anything I've ever heard from an external device, save for a real piano.
I do quite a bit of music production, and I can't work without VSTis. This software would be fine for recording 100% live sound, but that just isn't the case 99% of the time you're doing music production. Not only are VSTis important, but also VST effects and DX effects for audio post processing realtime while recording. That pretty much makes it unusable for me, and most other producers out there.
Still, it looks like a promising piece of software to bring Linux/BSD into the recording world, and as a beta I can understand it's still going through improvements, but the features I mentioned are key and currently only avaliable in Windows/MacOS. That's really the only thing keeping me from running FreeBSD as my main operating system.
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo!
You have a valid point that Linux is lackign some applications for music production, but the situation is not as bad as you seem to think, not by far.
The problem is more that if it isn't Cubase, many people don't recognize it as a midi recorder/editor/sequencer. There are alternatives, that may not be as extended as Cubase is, but are quite suitable for most projects. The first that comes to mind is ROsegarden.
With regards to multitrack recording/editing, take a look at Audacity, it seems to do really well, and offers more features then many will need.
Maybe I am a bit old fashioned, I actually use a real mixer and a stack of effect equipment for recording (all physical equipment, not virtualized).. This may make the mentioned software a bit more acceptable.
But the problem remains. People do not look for the specific functionality they need and try to find a solution that matches it well, instead they look for the program they know, or by lack thereof, something extremely similar.
The GPL just says if you give the binary, you must give the source too.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
I don't give a shit why. I don't care if it's "not a priority" or whatever other excuse you have. I care what's available, what you can do. This orignally started from some highly uninformed person claiming that a RTOS is ideal for AV work (it's not). Someone else than claimed that Linux easily beats Windows for MM speed, someone else responded that it was irrelivant because of lack of apps. That lead to a post with the list to my post.
My point is that the parent is right. In consumerland there is a derth of video apps that are useful. There are a couple that are toys maybe, but no serious apps. Past that there are only extremely expensive solutions. It's like going to buy a home theatre system and finding that there's guys selling expensive audiophile grade components, guys giving away old boomboxes, and nobody selling a consumer reciever.
So I, and others, don't care WHY Linux lacks those kind of apps, only that it does. The grand parent seemed to be under the mistaken impression that the list there provided a good alternative to what is available for Windows. No, not so much.
Please mod parent up; real world experience in this area is sorely lacking.
LRC, the best-read libertarian site on the web
with the right trick which may or may not be what they used here. When you have a dual core or even just a hyperthreaded processor, you can get Windows XP to have sub microsecond response times for a single process by locking that process to one of the cores (whether real or virtual, doesn't matter) and forcing all other processes to the other. Windows still runs fine on the other core. I saw this trick presented at a conference by someone who was working on a budget and had to interface to real time flight hardware. One of my engineers implemented and verified it before I even got home. It was really very simple and a useful trick for someone needing to have very quick response times from a single process.
This isn't that impressive for RTLinux, which is really a scheme for loading applications as loadable kernel modules running without memory protection. RTLinux is an obsolete approach; the more recent Linux variants from Lynuxworks and Montevista have a much cleaner approach, based on the low-latency fixes in the 2.6 kernel.
Would RT OS's be good for use in a heavy duty router? I would imagine IP/ATM packet routing would be best with the smallest possible latency, but you couldn't predict exactly when a packet will arrive over a specific interface. I'm thinking of something like a streaming video network (IP telephony, on-demand video, etc.), or even a gaming network, where lag means virtual death.
also, I imagine acheving low response times for interupts would be fairly easy on a multiple core system, if you just set aside all but one core for responding to interupts.
If I recall correctly, from years ago, there was an thing in the Windows NT HAL that allowed you to designate which CPU would handle interrupts...
I was thinking about this recently, thinking that if I had complete control over a dual core system, I would have all 'long' processes run on one CPU, with infrequent context switches for best efficency, while the other CPU would get all the 'short' execution time threads, for interupts and such. particularly in respect of the per-core memory cache. that way, receiving a network packet, moving the mouse, etc. would not interrupt things like video encoding/decoding, etc. but would still be quick... of coarse, each thread would have to be labeled for the scheduler to assign them appropriatly, but I think the real gains would be in keeping the cache consistant, the device drivers memory would always be in one core, and the long processes memory would remain on it's core. When I used a 2 cpu system to recalculate a large numerical database (2 gigabytes of pure numbers, back on a P-Pro 200x2 system with a whopping 256 megs of ram) The windows CPU meter would continutally switch which CPU was doing the non-multithreaded calculations. But I suppose that helped distribute the CPU heat evenly at least.
There is a very cool open-source linux app called 'jahshaka' that provides a complete compositing / editing / rendering solution for Linux
http://www.jahshaka.org/
Gekido's Lair
WHEE!
p lan/realtime.mspx
/. again!
You really have no idea what you're talking about. Take a RTS course and get back to me.
You could start by reading this: http://www.microsoft.com/technet/prodtechnol/wce/
Real-time is about timeliness, NOT speed. Speed can support the goal of timeliness, but often in real-time systems (especially embedded ones) the hardware you're working with is in fact *not* faster (or even as fast as) your standard consumer desktop. Think the processing hardware for, say, the guidance system of a missile. You wouldn't want to run Windows Vista on that, trust me.
(Of course, this might be a bad example because depending on the implementation, there might not be any operating system AT ALL)
Are you going to chase me down and reply with vitriol to every comment I post? Finally! A reason to read
+++ATH0
QNX had these kinds of numbers on a 486...
Is there a real reason you have to stay with this data acquisition board you're using already? Is it even a PCI card, or is it ISA (wouldn't be surprising at all in a Pentium 90 machine)? Can it even plug into a modern computer? What if the old board you have now breaks -- can it even be replaced? If you're going to make a major change, you might as well get fully up to date in the process.
To that end, have you thought about just calling up National Instruments and seeing what they have to offer? They specialize in exactly this type of product. They have a wide variety of data acquisition hardware and software, and they support a wide variety of operating systems and programming languages. It's possible they may even make a turnkey solution that already does what you need to do or can be programmed to do it easily.
From the license: "use of the Patented Process is permitted, without fee or royalty, when used by software licensed under the GPL." Mr. Stallman would have absolutely little or no problem with this patent, just as he has little or no problem with copyrights that are licensed freely.
Beware the difference between hard RT and soft RT applications/OSes.
RTLinux is a hardtime microkernel, running the whole Linux kernel as a low priority task. RTLinux' *own* tasks (or just interrupt handlers) are very limited, and have lots of restrictions communicating with the standard Linux kernel und userspace, which in itself does *not* run with realtime capabilities (I simplified a bit). The promises (latency) made by RTLinux are absolute, barring hardware faults, and are therefore suitable for high precision control applications, think nuclear, chemical production plant, mobile phone radio control, etc.
Audio/Video and Games are usually classified *soft realtime*. Nothing catastrophic happens at a missed deadline. Linux can be made to schedule certain tasks at (soft) realtime priority optimizing for low latency, instead of maximizing overall system throughput. There's nowhere the low latency or reliability of RTLinux, but it doesn't need to be, and A/V applications can use all the standard libraries and infrastructure of Linux (or Windows XP).
I got a 89 cent Atmel AVR microprocessor that has sub-microsecond interrupt response time, but I dunno if it has the bandwidth for video or even audio processing.
Tag lost or not installed.
"Serious question: why should the computer be up & running (and consuming electricity) when you are not using it? So you could show off your uptime-figures?"
It goes into power save mode if not using for 20 minutes. Saves switch/powersupply/harddrive ware&tare. And I like to work from home evenings/latenight/weekends over net.
a) Interrupts on the system (for the DAQ board as well as others) should be responsive to within 20uS. Futher experimentation, that we cannot currently do, would be possible with responsiveness under 10uS.
b) Don't have the specs on me, I just lobbed the questions out there before the post was pushed too far into the past. AFAIK, there's no driver for it except for DOS. There wasn't even one for Win 3.11. The documentation we have is minimal, so perhaps reverse engineering it is the way to go.
Yes, we could use other cards. The problem is that we don't currently have the funding for the changes.
Yes, revampng the entire system would be ideal!! We're so low on funding, ATM, that that isn't a real viable solution here though.
/.) Thanks! I'll be looking into it.
We (our lab) are a part of the Electrical Engineering dept. here. We have considered just redesigning/rebuilding everything ourselves, and may do just that. That would come sometime in the future, probably past my duration in the lab. (I just want to get my MS done, and get out.)
Yes, it is an ISA card. The PC itself isn't so much an issue though. IIRC, we've actually got a duplicate mobo in storage in case the current one fails.
dosemu... never came to mind. That's a great idea which I wouldn't have though of! (why I asked here on
Nice! Thanks much for that link. I'd not heard of, let alone looked at, COMEDI.
A cursory glance at the supported hardware doesn't show the device. We _may_ have the HW specs for ours, so this could (should) be something for us to investigate.
Thanks for the input, Kavli!
I think we're stuck in DOS mainly because that's the only working driver that was developed.
;) Thanks
As for why we use Borland... the original code was developed by my research prof, that was his perrogative at the time (over 10 years ago.) I've avoided making changes to it as much as possible because it is a spaghetti mess, and generally works. With a complete system revamp or change in OS, I'd think that a complete rewrite would be doable.
Getting the firmware from the vendor is indeed a problem; the main issue is that the manufacturer went bankrupt years ago (?) and I've been unable to track down where their old code might exist, if it even does.
Enjoy??
The reason we have to stay with the current board is mostly financial - we've currently no major source of funding needed to revamp the system.
It is indeed an ISA card. As somoene posted, there are still mobos out there with ISA slots, but we do have a backup mobo just in case ours horks.
We've looked at N.I. products, we just can't currently afford them from what I've seen.
I just want to thank people for giving me some direction on this, so... Thank You!
/. just gave the opportunity to ask you folks for some input.
On a personal note, I've been working in the lab for 5 years now as a grad student. That's five years (instead of two) for a M.S. in ElecEng. Sometimes I've had funding, other times I (and others here) have not been as fortunate.
The issue with the PC/Board/System has been around since I've been here. I've pushed for a system overhaul since my start. The post on
Personally, I've basically given up on seeing things change while I'm here. With the combo of the time I've been (stuck) here, financial difficulties, etc... I just want my degree and to get out of here (hopefully in Dec.) To that end, I'll just deal with the equipment as-is for a few more months. The ideas and directions that you all have pointed me towards will basically give my research prof and students who follow me some good ideas. At least I hope that's the case.
Thanks again, folks! Its really much appreciated.
Anyone who reads this and knows the way you write knows that it's you, Alex. No one misformats sentence syntax quite like APK2005+++SR9.
You tried pulling this same trick back on Ars and no one bought it then either.
Hey... what's OSY?
In fact, why don't you tell us all about this?
+++ATH0
If the vendor that supplied the board is now defunct, then you would have to reverse engineer the driver - which could take a lot of time and resources, depending on how much you know about the hardware and how complex the system is. The board is probably an ISA bus interface and you would be hard pressed to find a modern motherboard with ISA slots.
One of the posters above recommended National Instruments, their development suite is great for data acquisition - but it's gonna cost some bucks.
A lot of A/D hardware vendors offer good support for linux, writing drivers for linux is a lot easier than writing them for windows.
My suggestion would be to keep the system limping along until the A/D board dies. Money that "just isn't there" has a tendency to appear when a system someone needs goes to shit.
I'm always, always open to other options. If you have software to suggest, suggest it, I'll go and try it. I'm not real enamoured to spending lots of money on media production software.
The reason I made such a detailed post in the first place is every time on Slashdot I commit the heresy of saying an OSS solution isn't up to a commercial solution, I'm attacked as not knowing what I'm talking about. People then go and point out the same programs I've tried and so on.
I grow weary of people telling me that Linux is as good or better than Windows, then when I talk about what I need to switch, saying I need to make tons of compramises. Like with the orignal post that got me started, the implication seems to be that Linux is great for AV work, since Hollywood uses it and looks here's an advocacy site about it. Ok but here I'm being asked to make a sacrafice one way or another: Either I choose to sacrafice massive amount of money to get a super-high end solution, or I choose to sacrafice tons of ease of use and functionality to get a free one.
However my challenge is real: Show me apps that will do what I want. I'm honestly intrested to know. Someone else suggested Jahshaka. It's certian'y one that should be on that advocacy site as it's a much better designed editor than the one listed. Unfortunately, I found out that while it's better, it's still more of the same and totally unsuited for what I do.
That doesn't mean I don't want to hear options though, maybe you know of something I don't. I don't claim to know about all the software out there. I don't claim to know about even a small fraction. If you really do know an OSS video suite that plays on rougly the same level as the low-end PC/Mac ones, please tell me, I'll load it up tomorrow.
However the flip side is don't get mad if I tell you that, indeed, it's NOT an equivalant product and give you reasons why. Also don't suggest I should be willing to make massive compramises simply in the name of openness.
I use Firefox because it's honestly a better product than IE, not because it's OSS. I use FreeBSD for my webserver because I believe it's honestly a better web platform than Windows. I don't use OSS AV tools because they are worse solutions than commercial ones, much worse. It's not about ideaology, it's about usability and usefulness.
So please, enlighten me to these better Linux AV apps. This is an honest request. I apparantly lack the knowledge to find them, since I have tried, and what I've come up with has been unacceptable.
to disguise your writing style?
Why do you do this third-person "ROFLOMG APK SURE SHOWED YOU" thing? Perhaps it's because everyone sees that you are a raving lunatic and no real people will back you up, so you have to make people up?
I note you didn't actually address anything I said about RT systems, either.
(Also, I actually spent three years as a field service engineer for Fujifilm before returning to school to get my Ph.D. [got bored], but I'm sure your thirteen years of flipping registry entries and designing alarm clocks in Delphi is far superior to that)
It doesn't look like anyone thinks you slapped anyone else down, either. In fact just about everyone at WITPro seems to think you're a 50-amp power tool.
"APK manages to create the impression that MR just didn't know why this could be a problem, until he was rescued by APK's superior knowledge. But there's no actual evidence of any of this, it's just innuendo."
That seems to be your M.O. most of the time, doesn't it?
+++ATH0
I'm 26, dumbass.
And yes, I DO know more than you about real-time systems, especially with respect to real-time scheduling. What do YOU know about real-time scheduling, Alexander?
Also, anyone who was even remotely secure in their own abilities would not feel it necessary to engage in calling someone "boy," "beneath their notice," "master of profanity," (what the hell?) "easy meat," "greenie/noob/student," etc. etc.
You must be overcompensating for SOMETHING. I wonder what it is?
Also, I'll have published at least two technical reports by the end of the year, one on a security audit of a cooperative storage pool and the other on a real-time scheduling algorithm. The latter may be presented at a conference; we'll have to see how far we get with it.
I have to say I find it highly amusing that your sole metric of whether or not someone is successful in the field of computer science is whether or not they have created an artifact of software that people download from a consumer website.
+++ATH0
No, you mis-understood my original message.
As for why we use Borland... the original code was developed by my research prof, that was his perrogative at the time (over 10 years ago.) I've avoided making changes to it as much as possible because it is a spaghetti mess, and generally works. With a complete system revamp or change in OS, I'd think that a complete rewrite would be doable.
Borland turbo C/C++ code was popular during the 90's. The professors code is still portable to Linux/Win32 whatever. Its just that Windows/Linux etc. does not allow you to open the ports without permissions. Did you not read the link I provided in the original post?
You just need to author a quick device driver between the Linux kernel and your Borland code. In other words, change your inb/outb calls to read/write to a simple kernel driver that you can write yourself.
Do you not understand how a CPU interacts with the attached devices ? Just curious.
No flame intended.
Enjoy,
It's just the normal noises in here.
My reply to your lunacy is in the original thread.
+++ATH0
Hmm, well, would something like this fit your needs and your budget? I think these things are meant for robotics, and the sampling rate on the A/D is going to be a really low sampling rate (I think 65 Hz) and low resolution (around 10 bits), but that might be good enough for some purposes.
No, it unfortunately wouldn't. We need a DAQ that is 16-bit or better, with a sampling rate no less than 100 kHz. Oh, and it has to have two input channels.
That makes some sense to me, the intermediate quicky device driver between the kernel and the old Borland code. If I understand this right then, would this be the "easy" way to get around manually changing the code from the inb/outb calls into the linux-required reads/writes?
Correct! Fundamentally, I do not understand it, as it is something I've never studied. To me, a device driver is just some vague in-between code that allows the OS kernel to speak directly to hardware, somehow magically - a translation layer so that the kernel can "talk" to the device without knowing exactly what the hardware expects to "hear". ie. a kernel-to-hardware Babelfish.
No flame taken! Seriously, thanks for giving me a direction for at least learning a bit more how the low-level stuff operates. This is all new to me.
Hmm, well, these days there are boards that do that that are a dime a dozen. Namely, pro audio cards. The newest generation of cards does 192 kHz sampling rate at 24-bit resolution, and I've never seen a card that has fewer than two input channels. For example, just pulling something off the top of my head, the M-AUDIO Audiophile 192. The list price for this card is $200. Street price might be closer to $180. There are tons of other similar cards available, and some of them even have Linux drivers if that's a direction you are interested in going (and if you want to do the research).
The nice thing about these cards is that since they're pro, they even have differential inputs for common mode noise rejection, if you need that. Of course, the big down side is that whatever you have that's driving these inputs has to be able to drive something that looks like an audio input. I have no idea what kind of circuit you've got going in your lab, what kind of voltage range it has, what kind of impedence it expects, and all that.
Also, of course, these cards don't have a software framework that comes with them that's set up for experimentation. You're going to have to open the device and read the audio data out of it. That might be fine if all you care about is data collection and you aren't doing anything else on the computer (like analyzing the data and using it to control things) at the same time. But if your needs are more complex, then that's probably not the road you want to go down.
That's a really neat idea, AdrianMonk! I'll have to pass that suggestion around the lab, and see what other's thoughts are.
Yes, we would need differential inputs. We'd be able to design a new input circuit if needed, but we've plenty of lego-like parts that we could probably make that work quickly. Everything is matched to 50 Ohm right now.
We do do control, but not quite realtime, so that shouldn't be an issue.
The downside is that this would cover only maybe 50% of the research we do. I think we'd PREFER a DAQ that can handle up to 13 MHz, although that'd be rare. The soundcard idea is a good one though, for some stuff!
Thanks again!
I'm not part of some vast ars/osy conspiracy. I don't know them at all. I talked with them after seeing your somewhat different posts (this post is the first time I responded to you... I didn't know about Ars forums or Jeremy or anything at that point), googling about you, and finding they had similar sentiments. But before that post, I didn't know anything about you or them.
I don't mean to pester, sorry. It's just that I'm strangely compelled to try to figure you out, but annoyed by the fact that you view the world so differently.
Dude, that's not just a random song. 1) He knows how to actually play and sing, which is impressive enough, and 2) he spent enough time to do a decent recording about you. 98% of the people here couldn't do that, and if they could, wouldn't do it for some random person on the internet. Jeremy thinks you're "special", dude, admit it.
Heck, I spent $35 on background checks on you. Can't believe I did that, but whatever.
Any other pages I should remove?
Name me one person who's willing to read through any forum post that is several pages long. People will sometimes read through a whole New Yorker column, but won't do it for forum posts. You're right, you're free to post whatever you want. But there's no way other people are going to read the whole thing.
Oh, thank goodness for the holy mods. They never get things wrong. In fact, I definitely deserved every positive mod I've received, and it makes me deleriously happy every time I get one. All 435-440 times (I carefully keep count, you see).
You've got a point, I tend to be verbose (BUT, often with reason)!
No, really there is no good reason. If it's a good idea, it can be explained in a much shorter post, and it really doesn't take that much time/effort to express your ideas concisely.
If it's a really stupendously great idea that needs extensive writeup, then it doesn't deserve to be stuck deep inside a forum, it should be put on a webpage so people can Digg it. (that's a good suggestion actually... go and troll digg, it would make me happier if there were fewer trollish posts here on Slashdot)
But, like I said, mods aren't really something to base your self-worth on. Moderators have just as many failings as any other person. For instance, this comment didn't deserve +3, because it only takes 3 clicks from the main article to see the EULA, but half of the people are too lazy to do it.
There you go. If you want to do non-trollish karma whoring, that's one secret. Give them solid information, especially when it SEEMS hard to get the info, but half the time, it's super-easy, especially when you just post information you got off of wikipedia.
Hrm. I wonder why it is that 95% of people log in to comment, and yet don't fear harassment? Perhaps it's the content of your specific messages, and not the actions of any other person, that is the difference?
Your posts are hugely abnormally longer than anyone else's. Nobody replies to a two-sentence post with a 40-sentence post. If you really don't believe me, I can do the work required to calculate a histogram for you, but it really should be obvious without that.
As many as 10% of boys have ADD, it's not a major debilitating problem. You're free to complain about it if you really enjoy doing that, but since ADD's impact is fairly minimal, it's kind of pointless.
I'm not avoiding any questions. Check everyone's responses to you. Did they ever respond to all your points, or do they always skip things? Most likely they respond to the top parts and the bottom parts, if anything (psychology experiments show that we remember the first part and last part of a list the best).
If you're read my post, you won't find a promise anywhere. I specifically say "my perception is that the discussion goes downhill quickly if anything is said that you don't agree with". I'm extremely leery to discuss anything remotely technical, because technical things are 100% true or 100% false, but you don't seem to care. You still cling to an idea once someone challenges you on it, because you don't like being challenged. Even on these nontechnical issues, even once I show you a histogram of post length, you're still going to make it about me personally. With your personality and temper, it's really pretty tough to discuss things with you.
I've learned to ignore the background noise of the constant negative gibberish you write, and focus on the new stuff, but it's still very difficult to discuss things with you.
Constant insults, references to ADD, etc. These aren't part of a conducive, normal conversation. The only way anyone can have a normal conversation with you is to ignore this background noise. (this isn't just me talking... examine all your threads from the past... people might respond to this stuff when they first meet you, but quickly realize it's pointless, that you're not going to change, and they start only responding to the more coherent parts of your posts, if they continue talking at all.)
The reason I bring some of these things up about you, is because there are things about your posts that are clearly (in a statistical sense) very much outside the range of normal posts. Most aren't terminal, and can be accomodated for (but are things you might want to note). A few ARE terminal (like your post length, there's no way you can ever expect anyone to respond to several posts a day that are each several pages long), and those I'm suggesting you correct, so that we can actually have a conversation.
Though it's probably useless... no matter what, you're never going to want anyone to suggest that technical ideas you have might be slightly incorrect. That's one part of you that I haven't been able to figure out yet. You're obviously scientific-minded, and have some skill. Yet, you steadfastly want to never change your opinions once someone discusses alternative theories with you. I don't know how you've gained techincal skills, when you approach things, steadfastly thinking that everything you know is 100% correct. That doesn't seem conducive to gaining technical skills.
If you're NOT bothered by facts? When then, did you remove the page about you 'diagnosing yourself' with ADD then??
Because it's personal information. I also don't usually want my social security number, bank account numbers and PINs, etc. posted on the internet, even though they're facts.
I didn't diagnose myself with ADD. Multiple doctors have. I wasn't completely convinced that ADD fully explained the sound- and touch-sensitivity issues I have, but a kindergarten teacher who's a friend and who deals with ADD kids constantly, reassured me that the medical diagnosis was accurate.
Why are you trying to tell me how to write, what makes you the 'authority' here on THAT note? Please - show me the PhD in English you have, ok? Show us ALL that!
1) I'm not an authority. Simple, basic, statistics are. I'll get you the histogram in a day or two, depending on how boring work is today. 2) I'd like to converse with you, but it's very difficult, especially when you embed the questions you actually want answered deep inside a mass of text. 3) You'll be able to converse with other posters much more effictively also.
More to the point, I'm a bit of a social outcast myself. I'm becoming less so over time. I've recognized a lot of un-useful quirks in my behavior that were easy to change, and helped me fit in with others much more. I see a few things in your posts that, if changed slightly, would make you fit in with other people much better. I promise you that part of my feelings are benevolent (but don't promise that I will always be benevolent on the whole, because annoyance sometimes takes over).
You live with your parent(s). That's useful information for others to know.
I don't know if THAT's the truth, or not, OR how you could do THAT without my authorization... but I don't appreciate that either.
Of course it's the truth. I have no need to spin an increasingly bizarre alternate versions of reality. On this page, click on "view details", and you can see the various kinds of reports that anyone can buy. For the criminal background check, I ordered from someone else because they were cheaper.
I don't live with my parents, nor do I have any criminal background, so there's no need for you to spend money on that (though I do have two major vehicle accidents [1] [2]). My address isn't too hard to figure out, since I have various domains registered.
You're free to put any info about me up on your website, I suppose. But most people don't care about me. On the other hand, I have quite a few people stopping by my APK page, mostly by way of various Google searches.
In terms of your pot/kettle/black comment, yes, I agree that we're somewhat alike. As I said, that's most of the reason that I'm still talking to you and haven't grown completely bored yet.
Well, after your attempts to make up a lawyer, I don't know whether to believe you that you have a job. But it would be interesting to know if your job(s) are going well for you.