I’m not sure how far ahead. I notify every 4 frames (40 millisec). That’s about a half a megabyte of data. The value of the semaphore at the end was 0, which means all the data had been sent to the disk driver - i.e. the reader had written the 4 frames before the next 4 showed up. I understand that writes are delayed in QNX. (I was measuring some incredibly high disk transfer rates before I came to realize this.)
I don’t see how more buffers helps debugging, unless you are going to buffer enough to hold all the frames generated while you are single stepping…
I’m not talking about using debugger. I’m talking about thinks like printf, debug file, slog, trace, etc. Thinks that I turn on while debugging and turn off in release version.
You can control whether writes are delayed or not (by various mechanisms).
You will be clobbered by filesystem activity from other processes precisely for the reasons cited earlier. You said that you are using a WD caviar. You don’t state which model, but from what I can find on the web it looks as if you can expect a worst case seek of 30ms. So, if you are double buffering you’re hosed if a seek occurs. Of course, preventing a seek is not difficult if you control the raw device and never seek.
The remaining question is whether you treat the hard-drive itself as a circlular buffer. If you do then you need to account for a worst case seek in your buffering (as the head returns from the last cylinder to the first cylinder).
Assuming the circular stream on-disk option; if you equip your system with 2 hard-drives (one for general filesystem) and one for streaming video. Then you:
a) run two instances of devb-eide (one for each controller).
b) start the instance of devb-eide that controls the "streaming" drive specifying the following arguments:
"devb-eide eide pci={pci_idx},priority={priority},nobios blk auto=none,nora,cache={2*frame-size*num-frames-buffered},ncache=0,postpone=0"
c) implement a buffer sufficient to hold {drives-worst-case-latency*frames-per-ms}Then you can have the write side of your streamer process open /dev/hd1 and write like mad until the end of the drive and then seek back to the front (while the buffer fills, and then repeat). Of course, you’ll have to have enough excess throughput to the disk to amortize the frames buffered while the seek to the front was happening before you get to the end of the disk again otherwise your disk just isn’t fast enough for the job.
Assuming that the priorities of your video streaming system are higher than anything else in the system, you’ll be able to compile Open Office on the “general” drive while your “streaming” drive proceeds without a hiccup (that’s a real-time system).
The best part of this design, is that you know it works, you know exactly why it works; you know when it will fail and precisely under what conditions it will fail. The next best part is that if someone pulls the plug (euphamism for some aviation related incident - this is an a/c right?), you are guaranteed to have the maximum usable data on the disk (absolute minimal buffering).
By making the buffering the absolute minimum necessary to accomplish the job, if the system runs for an hour, it’ll run forever (barring hardware failure, or a bug in the code).
ps: many people seem to think that the final statement "barring ... a bug in the code" is some sort of an excuse to have a design that is inherently incorrect (the psychology seems to be, well since I am almost certain to have a bug in my code, then my design might as well be defective to). There is nothing further from the truth. If the design is inherently correct, then the implementation tends to be less buggy.Sure; putting a few well considered TraceEvents() in, and compensating with a little extra buffering is certainly not a bad idea.
You did say this was avionic stuff. Then you might consider somethink like M-System mSSd UATA: (m-systems.com/site/en-US/Pro … _Guide.htm)
These babies can do 45Mbytes sustained write, and close to 0 seek time
However you might hit the 5 000 000 write/erase cycle limits. Let’s says it’s a 10Gig HD, you write roughtly 10Mbytes a seconds. That means in 16 minutes you fill the HD. So 16 minutes times 5M = 158years if I do the math right. I think 5 000 000 write/erase cycles is not an issue.
These are expensive though. I know someone who payes around 600$ for the slower 2G model.
To add to Rennies’ comment on the design. I think it’s of the outmost importany in an real-time system to know as much as possible about what is REALLY going on. Assumptions are evil. I have yet to so people NOT surprise at what their system is really doing when they start looking at it with profilers… There are so much software out there that work not by design but by luck
- Mario
There’s a lot to reply to out here, and thanks for all the input to everybody. Im many ways this is probably a typical project, the sponsor wants features that were never a part of the original specs and he wants it now without buying any new hardware (after all, it’s only some software changes). We do have additional drives available to us, unfortunately they are SATA drives, so if QNX ever has SATA support we will be all set. We had arranged to purchase a DSP controlled SATA system for our instrument but the vendor failed to deliver on time so we had to fall back to the system IDE for data storage. As per avionics, the instrument is used in an airplane, but is is not part of any aircraft system, it just looks out the bottom of the plane at the ground. We have flown many types of these in various aircraft and have had no problems using standard disk drives. This is the first time in over 10 years that it seems necessary to bypass the file system to achieve the desired performance, we did that on an old sparc ultra1 Solaris system back in the 90’s.
So true.
Interesting “Designer surprised when he uses the System Profiler anecdote”…
One of my colleagues was showing a developer how to use the System Profiler to analyse their system. When they brought up the profiler and opened a “CPU usage” view they noticed that the timer interrupt was consuming 5% of the CPU!
Needless to say this was shocking (as in the “three phases of denial” level of shocking).
Further investigation showed an enormous chain of handlers to the timer IRQ. It turned out, that the build process was building every executable with application profiling on (and the system was in the neighbourhood of a hundred processes) which, since the app profiler is a statistical profiler, causes the instrumented process to attach a sampling handler into the timer chain.
Morale of the story: don’t ship until you analyse the final shipping image with the system profiler (spend a few days, just analysing the traces) and are convinced that it is behaving exactly as you expect it to.
If the majority of testers/developers did this we might be approaching the point at which we can refer to ourselves as engineers (without having to cross our fingers while saying it).