> via USB and see how it stands up. But the real question is what
> kind of delay, latency, and jitter will there be, getting that raw
> I/Q data from the USB interface up to the consuming application?
How is your proposal of zero-copy going to help latency? IIRC we have
some real-time thingy,
> Eliminating as much of the copy in/out WRT the kernel cannot but
> help, especially when you're doing SDR decoding near the radios
> using low-powered compute hardware (think Pies and the like).
Does this include demodulation on the pi? cause even when i dumped the
pi i was given for that
I was responding to lyndon's comment on certain "experiments" that
should have to be done here, 2 messages up.
But what he described sounded exactly like the zero-copying stuff that
linux is trying to shove into everything.
I have not made any statement about non-linux systems, and I'm not
even
On Tue, Oct 9, 2018 at 7:24 PM hiro <23h...@gmail.com> wrote:
> from what i see in linux people have been more than just exploring it,
> they've gone absolutely nuts. it makes everything complex, not just
> the fast path.
>
To whom are you responding? Your email is devoid of context, so it is
cinap_len...@felloff.net writes:
> why? the *HOST CONTROLLER* schedules the data transfers.
I *DON'T KNOW*. It's just observed behaviour.
> a! we'r talking about some crappy raspi here... probably with all
> caches disabled... never mind.
Hah. An Rpi tips over with 1200 baud USB serial.
> To address Hiro's comments, I have no benchmarks on Plan 9, because
> the SDR code I run does not exist there. But I do have experience
> with running SDR on Linux and FreeBSD with hardware like the HackRF
> One. That hardware can easily saturate a USB2 interface/driver on
> both of those
cinap_len...@felloff.net writes:
> > The big one is USB. disk/radio->kernel->user-space-usbd->kernel->applicati
> on.
> > Four copies.
>
> that sounds wrong.
>
> usbd is not involved in the data transfer.
You're right, I was wrong about 'usbd'. In the bits of testing
I've done with this, 'usbd'
On Tue, 9 Oct 2018 at 23:00, Ethan Gardener wrote:
>
> Fascinating thread, but I think you're off by a decade with the 16-bit
> address bus comment, unless you're not actually talking about Plan 9. The
> 8086 and 8088 were introduced with 20-bit addressing in 1978 and 1979
> respectively. The
he has ignored my questions about measurement, so i'm sure he hasn't
On 10/9/18, cinap_len...@felloff.net wrote:
> also, i wonder how much is the actual copy overhead you claim is the issue.
> maybe the impact for copying is more dominated by the memory allocator used
> for allocb(). have you
also, i wonder how much is the actual copy overhead you claim is the issue.
maybe the impact for copying is more dominated by the memory allocator used
for allocb(). have you measured?
--
cinap
> The big one is USB. disk/radio->kernel->user-space-usbd->kernel->application.
> Four copies.
that sounds wrong.
usbd is not involved in the data transfer. it mainly is just responsible to
enumerating devices and instantiating drivers and registering the endpoints
in devusb. after that you
hiro writes:
> from what i see in linux people have been more than just exploring it,
> they've gone absolutely nuts. it makes everything complex, not just
> the fast path.
And those are the Linux folks doing thier thing. The reading I'm
doing right now is related to the pessimizations page
also, if all you care about is throughput, i don't see how those 4
copies you identified makes a difference. especially with something
slow like USB.
from what i see in linux people have been more than just exploring it,
they've gone absolutely nuts. it makes everything complex, not just
the fast path.
Bakul Shah writes:
And funny you should mention this!
> Some of this process/memory management can be delegated to
> user code as well.
At $DAYJOB we would really like to have application process control
over the kernel scheduler, as this seems to be the only realistic
way to avoid the (kernel)
hiro writes:
> > Dealing with the security issues isn't trivial
> what security issues?
Passing protocol buffer like objects around user space, that might
affect how the kernel talks to hardware. E.g. IPsec offload into
hardware. You don't want user-space messing with that sort of
context,
hiro writes:
> Huh? What exactly do you mean? Can you describe the scenario and the
> measurements you made?
The big one is USB. disk/radio->kernel->user-space-usbd->kernel->application.
Four copies.
I would like to start playing with software defined radio on Plan
9, but that amount of data
On Tue, 9 Oct 2018 10:50:08 -0700
Bakul Shah wrote:
> Exactly! No point in being scared by labels! I am really
> only talking about distilling plan9 further. At least as a
> thought experiment.
>
> Isn’t it more fun to discuss this than all the “heavy
> negativity”? :-)
It's much better with
> E.g. right now Plan 9 suffers from a *lot* of data copying between
> the kernel and processes, and between processes themselves.
Huh? What exactly do you mean? Can you describe the scenario and the
measurements you made?
> If we could eliminate most of that copying, things would get a lot
> On Oct 9, 2018, at 2:45 AM, Ethan Gardener wrote:
>
> One day, Uriel met a man who explained very
> convincingly that the Plan 9 kernel is a microkernel.
> On another day, Uriel met a man who explained very
> convincingly that the Plan 9 kernel is a macrokernel.
> Uriel was enlightened.
Bakul Shah writes:
> One thing I have mused about is recasting plan9 as a
> microkernel and pushing out a lot of its kernel code into user
> mode code. It is already half way there -- it is basically a
> mux for 9p calls, low level device drivers, VM support & some
> process related code.
> From what I recall, PDP11 hardware memory management was based on
> segmentation rather than paging (64K divided into 16 variable sized
> segments), and Unix did swapping rather than paging (a process is either
> completely in memory or completely on disk). It does relocation and
completely in
> I think it would be terrible, because I got frustrated enough trying to run a
> 4e CPU server with graphics on a 2GB x86. I kept running out of image
> memory! The trouble was the draw device in 4th edition stores images in the
> same "image memory" the kernel loads programs into, and the
On Tue, Oct 9, 2018, at 4:08 AM, Digby R.S. Tarvin wrote:
> I thought there might have been a chance of an early attempt to target the
> x86 because of its ubiquity and low cost - which could be useful for a
> networked operating system. And those were 16 bit address constrained in the
> early
On Tue, Oct 9, 2018, at 4:28 AM, Lucio De Re wrote:
> On 10/9/18, Bakul Shah wrote:
> > One thing I have mused about is recasting plan9 as a
> > microkernel and pushing out a lot of its kernel code into user
> > mode code.
> >
> There are religious reasons not to go there
I'm trying to forget
we already have a lot of user filesystems. feel free to add other useful ones.
26 matches
Mail list logo
