Frank Brickle wrote:
Larry Loen wrote:
FlexRadio - Eric wrote:
I don't think there will be any significant performance hit due to
using
XML.
Here we are, living in a regime where we can barely make CW paddling
work as it is, and we want to burden our slowest path with this?
It would be more of a worry if the problem with CW were CPU load. It
isn't.
Of course. It's all about latency. But, you reduce the general load
and that helps latency. Even if it is at the margins. A CPU that is
idle more often will service an interrupt faster than one that is busier.
It isn't just CW either. In fact, my comments there were a touch
harsher there than I intended. I think the CW pathway, even the
parallel port-based one, is a triumph. But, I don't want to see it
burdened any more than necessary because it isn't perfect and cannot be.
Windows is not a real time environment and neither is a typical Linux box.
Moreover, there are all sorts of other little glitches. The programming
is very cleverly done. Most of them simply result in lost screen
updates. But, there are other gliches that happen. I'd like as few of
these as possible, please. These happen even at 35 per cent utilization
on my P IV 2.4 GHz machine. If it happens there, it will certainly
happen on lesser boxes.
Data representations, I've found, are far more immortal than code.
Indeed. That's why the update command structure for the DSP under
Linux has been the way it is for something approaching two years.
If that's what's on offer, is there a spec I can read? Or a code module
perhaps?
Right now the overhead associated with a single update command to the
Linux DSP is a little under 3usec on a 1.2GHz machine. That number can
already be trimmed by batching the updates. There are also three other
critical spots in the update code that can be improved merely by
changing the associated algorithms -- no change in the protocol -- but
which have not been necessary yet. For example, the actual command
dispatch uses a linear table lookup. Dumb but simple. If the command
set grew much more, an obvious step is to replace the table lookup
with a perfect hash. This is a detail. Knuth: "Premature optimization"
etc. etc.
I'm already suffering, in the Windows box anyway, from something that
appears to be a marvel of genius, but which does not appear to have any
extra margin and seems to have many sundry latency problems at far under
100 per cent utilization. I would not have commented else, at least in
regards to the "upper path".
The Linux DSP is perhaps encouraging, but do we know we can count on the
same tradeoffs with the Windows version, which many of us use exclusively?
Compare that 3usec with the ~1msec delay associated with executing a
*single* hardware command. That delay is imposed by the hardware.
There's a lot of room between 1kHz and 333kHz before starting to get
worried. In any practical sense you could already stream update
commands over FireWire.
No doubt true, but you're asking me to believe the theory over what I so
far actually experience with the equivalent of this whole XML thing
bypassed. I'm already seeing various difficulties. You'll forgive me
if I wonder if this analysis isn't a bit too comforting. If it were so
easy, I'd be having a totally smooth experience today. I'm not.
But even then, in most uses I see, XML data flow does not dominate
execution in the way this well might...
There are advantages to being able to exploit both DOM and SAX models.
But in any case I don't think anybody is proposing to base the lowest
levels of execution on SAX callbacks. The idea all along has been to
provide a translation layer (which therefore is amenable to either DOM
or SAX) producing command streams at the simpler lower protocol level.
Then I'm not clear on why we're bothering with the XML wrapper. If the
command streams do the real work, why not just send and receive those?
What else are we getting for our cycles with other stuff before that
happens?
Furthermore it's been clear for at least two years that there is a
tradeoff between control rates and human perceptual limits. When it
comes to scrolling frequency, there is a ~20ms limit on how fast you
can even control your muscles on the mousewheel, playing against a
~10ms threshold on how fast your ear can actually detect transient
changes. There is *no point* in changing gross controls faster than
that. Therefore the idea has been to apply, just as emacs does when
updating a text window, a dynamic program to the control stream, on
the fly, to optimize the data actually sent to the executing code and
devices. The command structure can consume data a lot faster than you
can control it. The job will be to thin the stream, not speed it up.
This implicitly assumes nothing else is going on. But, right now I have
XCHAT running to get my DX spotting and my mail code going so I can type
this letter. I have MixW2 running because I want the log function (but
it does have a waterfall it's producing for me that I sometimes find
useful). Of course I shouldn't have [EMAIL PROTECTED] or such things running,
and I don't, but what I have running right now is actually going to be
pretty typical. I do notice that when I do things like open an
attachment or maybe move a window or at random other times that odd
things happen to the SDR.
I think I'm being reasonably prudent. But, we can't quite assume a
dedicated environment, either. Not if many, as I do, have the rig on
all evening. Competition from other applications will mean the odd bit
of unexpected latency. Our only escape is to control our consumption to
leave as much margin as possible. Or, so I would have thought.
All I have to do to turn off the SDR audio is simply move this window
(the one containing this e-mail) all around the screen. The audio shuts
down. Maybe that makes your argument more than mine, who knows. All I
know, it is all too easy, far short of 100 per cent CPU, to lose
function on the radio as it stands. So, I look askance at arguments
that tell me I don't have to worry about CPU being consumed. Even
something as simple as preemption on a modern processor is not free.
The cache has to be refetched every time. In modern computers, that's
a lot more cycles than meets the eye.
The overhead gobbled up in parsing an XML control stream is lost in
the noise. There is no foreseeable argument against XML that actually
applies to this situation.
Presuming the lower box in the diagram is always a big time Windows or
Linux PC, perhaps. What if it is an embedded device whose clock speed
may well be lower to reduce power consumption?
I'm really sold on this SDR concept. I never want to deal with any
other kind of radio.
But, it needs to be lighter in every respect someday. Or, that's my
dream. I love my SDR 1000, but I'd like to dispense with the sound card
and its shaky cables. DXpeditioning with that is not as much fun as it
could be. I'd like to take something QRPing up the trail somewhere or
to the boundary waters to set up at night in camp. One that I can hook
a minimal lapt to or even maybe a PDA like an iPAQ. I'm told the
receiver, as it sits, consumes too much power for that to really work
for that (someone correct me if that's wrong). To me, that bottom
diagram has to be able to be ruthlessly simplified on the hardware side
of it. That will mean, quite likely, processor technology with no added
cycles in order to be kind to things like battery life and circuit board
space.
Sorry, I'm not caught up to your argument yet. Not with my non-glitch
free experience without this even in the path today.
What you have so far described still has XML as overkill, forgiven under
the assumption that we have CPU to burn. If we're just controling the
knobs and latches, then it's more than needs to be there and the benefit
is unclear. If there is, on the other hand, function on offer that
needs it, then we may well be "pricing" ourselves out of later boxes
(whether done by Flex or Tony or Phil or someone else) that has a simple
embedded controller that has no serious ability to take on a DOM or SOX
level infrastructure because it doesn't even have DOS levels of
functionality present and a host of other limits in terms of function
and memory. In that case, I would suggest we need an added interface
description that is the CAT-on-USB-serial-cable version on down,
exposed. That way, the upper (now middle) layers you suggest need XML
could be optionally absorbed by the PC and the simple control flow still
moves down to some very simple hardware in ways that are well understood
and well-proven.
If effect, we'd have three layers in the diagram, with the middle one
absorbable by either the computer for the upper or lower layers. Or,
maybe in a networked environment, all three.
Moreover, if there really could be an augmented CAT interface, a lot of
3rd party software might be usable, if not ideal, pretty much out of the
box if the connection was neither USB or firewire, but ordinary RS-232
(or USB that translates to same). That's still an existing interface
even if it does readmit audio wires into the discussion. Yet, for a lot
of folks, that's an important need. For that exact application, the XML
is just added overhead. And, we have lots of people doing that one
right now.
Larry WO0Z
- Re: [Flexradio] Comments on API Larry Loen
-
