On 10/8/18, Digby R.S. Tarvin wrote:
>
> So the question is... is plan9 still lean and mean enough to fit onto a
> machine with a 64K address space? Doing a port would certainly provide
> plenty of opportunity to tinker with the lights and switches on front
> panel, and if it the port was initiall
A native Inferno port would certainly be a lot easier, but I think you
might be a bit pessimistic about would can fit into a 64K address space
machine. The 11/70 certainly managed to run a very respectable V7 Unix
supporting 20-30 simultaneous active users in its day, and I wouldn't have
thought pl
saving every bit of memory has costs in coding, the pressure wasn't as
strong any more.
the earned flexibility can be used for more elegant design.
On 2018-10-08T05:38:07+0200, Lucio De Re wrote:
> You really must be thinking of Inferno, native, running in a host with
> 1MiB of memory. 64KiB isn't enough for anything other than maybe CPM.
> Even MPM won't cut it, I don't think.
There were serveral UNIX 6th Edition-based "Mini Unix" variants
f
On 2018-10-08T15:29:02+1100, Digby R.S. Tarvin wrote:
> A native Inferno port would certainly be a lot easier, but I think you
> might be a bit pessimistic about would can fit into a 64K address space
> machine. The 11/70 certainly managed to run a very respectable V7 Unix
> supporting 20-30 simult
I quite agree - the PDP 11/70 was quite a high end 16 bit machine, but it
was the machine that I was talking about and the one I would most like to
revisit (although I wouldn't turn down an 11/40 if somebody offered me a
working one). I don't think I would contemplate putting Plan9 on a machine
wit
Ideally, anyway.
On Mon, 8 Oct 2018 at 11:20, hiro <23h...@gmail.com> wrote:
> saving every bit of memory has costs in coding, the pressure wasn't as
> strong any more.
> the earned flexibility can be used for more elegant design.
>
>
i should have said could, not can :)
Does anyone know what platform Plan9 was initially implemented on? My guess
is that there is no reason in principle that it could not fit comfortably
into the constraints of a PDP11/70, but if the initial implementation was
done targeting a machine with significantly more resources, it would be
eas
On Mon, Oct 8, 2018 at 6:25 PM Digby R.S. Tarvin wrote:
> Does anyone know what platform Plan9 was initially implemented on?
>
My understanding is that the earliest experiments involved a VAX, but
development quickly shifted to MIPS and 68020-based machines (the "gnot"
was, IIRC, a 68020-based c
On Mon, 08 Oct 2018 19:03:49 -0400 Dan Cross wrote:
>
> plan9 is breathtakingly elegant, but this is in no small part because as a
> research system it had the luxury of simply ignoring many thorny problems
> that would have marred that beauty but that the developers chose not to
> tackle. Some of
On Mon, Oct 8, 2018, 17:15 Bakul Shah wrote:
> On Mon, 08 Oct 2018 19:03:49 -0400 Dan Cross wrote:
> >
> > plan9 is breathtakingly elegant, but this is in no small part because as
> a
> > research system it had the luxury of simply ignoring many thorny problems
> > that would have marred that be
On Tue, 9 Oct 2018 at 10:07, Dan Cross wrote:
> My guess is that there is no reason in principle that it could not fit
>> comfortably into the constraints of a PDP11/70, but if the initial
>> implementation was done targeting a machine with significantly more
>> resources, it would be easy to mak
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. It is already half way there -- it is basically a
> mux for 9p calls, low level device drivers, VM support & some
> process related
we already have a lot of user filesystems. feel free to add other useful ones.
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
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 d
> 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 38
> 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
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.
Somewh
> 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.
Exac
> 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 faste
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 pa
On Tue, 09 Oct 2018 10:45:37 -0700 Lyndon Nerenberg wrote:
Lyndon Nerenberg writes:
> 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
>
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 co
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, but
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)
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.
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.
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 flipp
> 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 acce
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
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 mea
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 I
On Tue, Oct 9, 2018 at 5:28 PM hiro <23h...@gmail.com> wrote:
> > 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?
The current plan9 architecture relies heavily on copying data wi
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'
> 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 opera
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.
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 not
with meltdown/Spectre mitigations in place, I would like to see evidence that flip is faster than copy.- Erik
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 say
> 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 purpos
> 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, mi
I have been able to copy 1 GiB/s to userspace from an nvme device. I should think a radio should be no problem.- Erik
On Oct 9, 2018, at 3:06 PM, erik quanstrom wrote:
>
> with meltdown/Spectre mitigations in place, I would like to see evidence that
> flip is faster than copy.
If your system is well balanced, you should be able to
stream data as fast as memory allows[1]. In such a system
copying things N times
zero copy is also the source of the dreaded 'D' state.- Erik
Il giorno mar 9 ott 2018 alle ore 05:33 Lucio De Re
ha scritto:
>
> 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. It is already half way there -- it is basically a
> > m
I don't know which other ARM board you tried, but I have always found
terrible I/O performance of the Pi to be a bigger problem that the ARM
speed. The USB2 interface is really slow, and there arn't really many
other (documented) alternative options. The Ethernet goes through the same
slow USB int
I agree, if you have a choice avoid rpi by all costs.
Even if the software side of that other board was less pleasent at least it
worked with my mouse and keyboard!! :)
As I said I was looking at 2Mbit/s stuff, which is nothing, even over USB.
But my point is that even though this number is low, t
On Tue, Oct 9, 2018, at 11:22 PM, Digby R.S. Tarvin wrote:
>
>
> 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
On Tue, Oct 9, 2018, at 8:14 PM, Lyndon Nerenberg wrote:
> 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 star
people come down very hard on the pi.
here are my times for building the pi kernel. i rebuilt it a few times to push
data into any caches available.
pi3+ with a high-ish spec sd card: 23 secs
dual intel atom 1.8Ghz with an SSD: 9 secs
the pi is slower, but not 10 times slower.
However it does
> > with meltdown/Spectre mitigations in place, I would like to see evidence
> > that flip is faster than copy.
>
> If your system is well balanced, you should be able to
> stream data as fast as memory allows[1]. In such a system
> copying things N times will reduce throughput by similar
> facto
oh! you wrote a nvme driver TOO? where can i find it?
maybe we can share some knowledge. especially regarding
some quirks. i dont own hardware myself, so i wrote it
using an emulator over a weekend and tested it on a
work machine afterwork.
http://code.9front.org/hg/plan9front/log/9df9ef969856/sy
> But the reason I want this is to reduce latency to the first
> access, especially for very large files. With read() I have
> to wait until the read completes. With mmap() processing can
> start much earlier and can be interleaved with background
> data fetch or prefetch. With read() a lot more re
Well, I think 'avoid at all costs' is a bit strong.
The Raspberry Pi is a good little platform for the right applications, so
long as you are aware of its limitations. I use one as my 'always on' home
server to give me access files when travelling (the networking is slow by
LAN standards, but ok
As the guy who wrote the majority of the code that pushed those 1M 4K
random IOPS erik mentioned, this thread annoys the shit out of me. You
don't get an award for writing a driver. In fact, it's probably better
not to be known at all considering the bloody murder one has to commit
to marry hardwar
hahahahahahahaha
--
cinap
On Wed, Oct 10, 2018 at 04:54:22PM -0500, Steven Stallion wrote:
> As the guy
might be worth keeping in mind the current most common use case for nvme
is laptop storage and not building jet engines in coraid's basement
so the nvme driver that cinap wrote works on my thinkpad today and is
about
Posted August 15th, 2013: https://9p.io/sources/contrib/stallion/src/sdmpt2.c
Corresponding announcement:
https://groups.google.com/forum/#!topic/comp.os.plan9/134-YyYnfbQ
On Wed, Oct 10, 2018 at 5:31 PM Kurt H Maier wrote:
>
> On Wed, Oct 10, 2018 at 04:54:22PM -0500, Steven Stallion wrote:
> > A
On Wed, 10 Oct 2018 at 21:40, Ethan Gardener wrote:
> >
> > Not sure I would agree with that. The 20 bit addressing of the 8086 and
> 8088 did not change their 16 bit nature. They were still 16 bit program
> counter, with segmentation to provide access to a larger memory - similar
> in principle
For operations that matter in this context (read, write), there can be
multiple outstanding tags. A while back rsc implemented fcp, partly to
prove this point.
On Wed, Oct 10, 2018 at 2:54 PM Steven Stallion wrote:
> As the guy who wrote the majority of the code that pushed those 1M 4K
> random
Interesting - was this ever generalized? It's been several years since
I last looked, but I seem to recall that unless you went out of your
way to write your own 9P implementation, you were limited to a single
tag.
On Wed, Oct 10, 2018 at 7:51 PM Skip Tavakkolian
wrote:
>
> For operations that mat
> Posted August 15th, 2013:
> https://9p.io/sources/contrib/stallion/src/sdmpt2.c Corresponding
> announcement:
> https://groups.google.com/forum/#!topic/comp.os.plan9/134-YyYnfbQ
This is not a NVMe driver.
--
Aram Hăvărneanu
hiro writes:
> Does this include demodulation on the pi?
Yes. At least to a certain extent. The idea is to get from the
high-birate I/Q data so something more amenable to transmission
over an RS-422 (or -485) serial drop.
One example is for an AIS transceiver on a boat. By putting the
radio a
> I have been able to copy 1 GiB/s to userspace from an nvme device. I should
> think a radio should be no problem.
The problem is when you have multiple decoder blocks implemented
as individual processes (i.e. the GNU radio model). Once you have
everything debugged, you can put it into a single
On Thu, Oct 11, 2018 at 10:54:22AM -0700, Lyndon Nerenberg wrote:
>
> Since when did curiosity become a capital crime? Oh, wait, that
> was January 20, 2017. My bad.
Turns out it's not, so you can climb down off your cross. It's just
that it helps to be a little clearer about your meaning, tha
Digby R.S. Tarvin writes:
> Agreed, but the PDP11/70 was not constrained to 64KB memory either.
> I do recall the MS-DOS small/large/medium etc models that used the
> segmentation in various ways to mitigate the limitations of being a 16 bit
> computer. Similar techniques were possible on the PDP
> One example is for an AIS transceiver on a boat. By putting the
> radio and decoder at the top of the mast, the backhaul can be a
> cat-3 twisted pair cable, rather than a much heavier coax run from
> the antenna at the top of the mast to the receiver below decks.
Yeah, I've been sending 3Mbit
> through the kernel. Not so much for the speed aspect, but to free
> up CPU cycles that can be devoted to actual SDR work.
those 2x25kHz channels would hardly need many cycles. rather it's just
a matter of selecting the right CPU that can actually do the FFT with
some software floating point imp
i meant without having to resort to some soft fp.
On 10/11/18, hiro <23h...@gmail.com> wrote:
>> through the kernel. Not so much for the speed aspect, but to free
>> up CPU cycles that can be devoted to actual SDR work.
>
> those 2x25kHz channels would hardly need many cycles. rather it's just
>
We also have CPU extensions that can help make fast FFT, because it's
such a generic problem, and in the worst case you can use fpgas,
asics, in any case dedicated hardware.
I was able to use dump1090 (same author as redis) to get ADSB data reliably
on RPi/Linux a while back.
On Thu, Oct 11, 2018, 10:54 AM Lyndon Nerenberg wrote:
> > I have been able to copy 1 GiB/s to userspace from an nvme device. I
> should
> > think a radio should be no problem.
>
> The problem
hiro writes:
> But given the alternatives available back then, even the armv5 in the
> kirkwood, which was cheaper even before the rpi became popular, did
> the same job more stably, which is why i would never actually
> recommend the pi. And there are even more alternatives now.
I get that. But
> I was able to use dump1090 (same author as redis) to get ADSB data reliably
> on RPi/Linux a while back.
I have a pair of Flightbox ADS-B receivers I am using as references.
While mostly reliable, they can and do stutter along with the rest
of the alternatives on occasion.
--lyndon
I assumed you were using an RTL2832U (rtlsdr library).
On Thu, Oct 11, 2018, 12:40 PM Lyndon Nerenberg wrote:
> > I was able to use dump1090 (same author as redis) to get ADSB data
> reliably
> > on RPi/Linux a while back.
>
> I have a pair of Flightbox ADS-B receivers I am using as references.
Skip Tavakkolian writes:
> I assumed you were using an RTL2832U (rtlsdr library).
I'm pretty sure they all do, under the hood.
> need to prove it can be done with the usual
> suspects (GNU radio, on the Pi -- the native fft libraries seem fast
> enought to make this viable).
be assured i've demodulated 25khz signals in real-time and it's a walk
in the park, as long as your revision has the neon stuff i mentioned,
otherwis
>> I assumed you were using an RTL2832U (rtlsdr library).
>
> I'm pretty sure they all do, under the hood.
>
>
don't you need sending ability, too for AIS?
hiro writes:
> don't you need sending ability, too for AIS?
No, a receive-only setup is very useful on a small boat. Where I
would like to go with this is to take the decoded AIS data as input
for "ARPA" style collision plots. I'm interested in the big boats
sailing through the straight. They
Oh yes, I read Eldon Halls book on that quite a few years ago. Meetings
held to discuss competing potential uses for a word of memory that had
become free.
That one would be a challenging Plan9 port..
On Fri, 12 Oct 2018 at 05:13, Lyndon Nerenberg wrote:
> Digby R.S. Tarvin writes:
>
> > Agreed
Digby R.S. Tarvin writes:
> Oh yes, I read Eldon Halls book on that quite a few years ago. Meetings
> held to discuss competing potential uses for a word of memory that had
> become free.
> That one would be a challenging Plan9 port..
And yet Plan9 was not there to save the day. Such a pity.
I'm not going to argue with someone who has got his hands dirty by actually
doing this but I don't really get this about the tyranny of 9p. Isn't the
point of the tag field to identify the request? What is stopping the client
from issuing multiple requests and match the replies based on the tag? Fr
there's no tyranny involved.
a client that is fine with the *responses* coming in reordered could
remember the tag obviously and do whatever you imagine.
the problem is potential reordering of the messages in the kernel
before responding, even if the 9p transport has guaranteed ordering.
On 10/1
OK, that makes sense. So it would not stop a client from for example first
read an index block in a B-tree, wait for the result, and then issue read
operations for all the data blocks in parallel. That's exactly the same as
any asynchronous disk subsystem I am acquainted with. Reordering is the
nor
also read what has been written before about fcp. and read the source of fcp.
On 10/14/18, Ole-Hjalmar Kristensen wrote:
> OK, that makes sense. So it would not stop a client from for example first
> read an index block in a B-tree, wait for the result, and then issue read
> operations for all th
Il giorno dom 14 ott 2018 alle ore 19:39 Ole-Hjalmar Kristensen
ha scritto:
>
> OK, that makes sense. So it would not stop a client from for example first
> read an index block in a B-tree, wait for the result, and then issue read
> operations for all the data blocks in parallel.
If the client
87 matches
Mail list logo
