Re: [9fans] Barrelfish
Add into that the datarate of full 10 bit uncompressed 1920x1080/60i HD is 932Mbit so your 1Ghz clockspeed might not be fast enough to play it :) Not sure I agree, I think its worse than that: 1920pixels * 1080lines * 30 frames/sec * 20bits/sample in YUV = 1.244Gbps Also, if you want to encode live material you have bigger problems. encoders have pipeline delay but this must be limited, usually to a few hundred millisecods. This means you can only decompose the stream into a few frames which you can run on seperate cpus. Spatial decomposition of the frames helps too but this is much more difficult to do well - i.e. to ensure you cannot see the joins. -Steve
Re: [9fans] ape/psh can't exec in 9vx
On Oct 19, 11:50Â am, r...@swtch.com (Russ Cox) wrote: /bin/sh: uname: cannot execute - Access denied I believe that if you build a new binary from the sources instead of using the pre-compiled binary, this bug is fixed. The binaries are lagging behind the actual source code. Yes, doing the both things have helped.
[9fans] jpg image too big
the problem is indeed drawterm related, but it's not dt's fault. the problem is that devdraw/loadimage.c needs to load at least 1 scan line at a time. unfortunately, iounit for drawterm ends up being 8k, so display-bufsize=8k. the problem is that each scan line is over 9k in my case. i haven't looked yet to see if the kernel can deal with partial lines, or what could be done about the too-small iounit. but it would seem to me that something has to give. - erik
Re: [9fans] Venti over DHT
Russ Cox wrote: Hi, There was no real code to speak of. It was a draft of a draft. I did some calculations of block-level commonality using a few trivial programs that hashed each block of every file in a tree, but you could recreate that in 100 lines of C or shell script. We never stored any blocks in the DHT. I've also done some bits of works in that area (nothing usable yet ;-o), but with different requirements: * storage near to the user (at least local mirrors) * equal data should get equal score (even w/ encryption) * automatic removal of stale blocks - garbage collection * efficient also on small data blocks Especially the distributed GC together w/ encryption turned out not be quite trivial ;-o On the one hand we need things like timestamps, on the other hand we need to trace the tree structures w/o decryption. So I added several block types: eg. blob (payload data) and inode (holding the tree). blobs are encrypted w/ their score, thus reading takes scores (outer for retrieval, inner for decryption). inodes have an public area, listing just the outer scores and an encrypted one holding the inner scores. The tree formed by inodes doesn't necessarily has to be fully balanced, so incremental writes with special heuristics for preventing unncessary writes are possible. If someone likes to hear more about this, just let me know :) cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: i...@metux.de skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [9fans] jpg image too big
On Tue, Oct 20, 2009 at 5:04 AM, erik quanstrom quans...@quanstro.net wrote: the problem is that devdraw/loadimage.c needs to load at least 1 scan line at a time. unfortunately, iounit for drawterm ends up being 8k, so display-bufsize=8k. the problem is that each scan line is over 9k in my case. i haven't looked yet to see if the kernel can deal with partial lines, or what could be done about the too-small iounit. but it would seem to me that something has to give. you can handle this in loadimage by turning a single call with too much data per scan line into multiple calls, each delivering a fraction of a scan line (there is a rectangle argument that says what subsection of the image is being loaded). russ
Re: [9fans] jpg image too big
i haven't looked yet to see if the kernel can deal with partial lines, or what could be done about the too-small iounit. but it would seem to me that something has to give. you can handle this in loadimage by turning a single call with too much data per scan line into multiple calls, each delivering a fraction of a scan line (there is a rectangle argument that says what subsection of the image is being loaded). oh, great. i just didn't know if that was legal. is it also possible to lock the display and send more than iounit's data? - erik
Re: [9fans] jpg image too big
oh, great. i just didn't know if that was legal. is it also possible to lock the display and send more than iounit's data? devdraw expects the messages to be delivered whole in each write, so you'd have to introduce a buffer to hold partial messages or be able to process partial writes. much easier to tweak loadimage. even easier would be to tweak drawterm so that it ends up with a larger iounit. i'm pretty sure devdraw's iounit is bigger and also that we bumped up the block size in cpu (looks like 64 kB) for exactly this reason. russ
Re: [9fans] jpg image too big
even easier would be to tweak drawterm so that it ends up with a larger iounit. i'm pretty sure devdraw's iounit is bigger and also that we bumped up the block size in cpu (looks like 64 kB) for exactly this reason. good point. can we just make i/o unit anything we wish? maybe it's old 9p hangover, but i have this nagging feeling about network-dependant limits. in looking at the code, it might be a lot more efficent for loadimage to count pixels rather than lines (being careful with the slop at the end, of course). the slop is Dy(r)-1 pixels, which is considerable for a camera shot. maybe it's not worth the pain? - erik
Re: [9fans] jpg image too big
good point. can we just make i/o unit anything we wish? no, because it affects the size of buffer that gets allocated to hold 9p messages. the kernel is free to limit the iounit too. in looking at the code, it might be a lot more efficent for loadimage to count pixels rather than lines (being careful with the slop at the end, of course). the slop is Dy(r)-1 pixels, which is considerable for a camera shot. maybe it's not worth the pain? it's not. fix iounit.
[9fans] usb disk error
i don't recall getting these before. this seems
like new behavior. i got 4 of these when downloading
4gb of pictures from a sd card. never in
the same place twice. sb600 ohci controller.
disk... reset: device is detached
it seems that umsrecover - umsreset - usbcmd and
if(usbcmd(ums-dev, r, Umsreset, 0, 0, nil, 0) 0){
fprint(2, disk: reset: %r\n);
i don't see exactly where it is, but could this be
a timeout issue? that's the main difference i see
between now and the previous time. turning on
debugging might not help. there's just too much
of it. sometimes it's many gb of transfer before
an error.
- erik
Re: [9fans] usb disk error
erik quanstrom wrote:
i don't recall getting these before. this seems
like new behavior. i got 4 of these when downloading
4gb of pictures from a sd card. never in
the same place twice. sb600 ohci controller.
disk... reset: device is detached
it seems that umsrecover - umsreset - usbcmd and
if(usbcmd(ums-dev, r, Umsreset, 0, 0, nil, 0) 0){
fprint(2, disk: reset: %r\n);
i don't see exactly where it is, but could this be
a timeout issue? that's the main difference i see
between now and the previous time. turning on
debugging might not help. there's just too much
of it. sometimes it's many gb of transfer before
an error.
- erik
If a new problem, it 'should' be a hardware issue. Bits, as you know as well as
anyone, do not really 'rot'.
Wots the ambient temperature, device temp, planar temp and surface
cleanliness/humidity at the area of the driving silicon and on any
sockets/conectors?
And if clean, cool, and well-connected, do the PS rail and signals look clean on
a 'scope?
Bill
[9fans] anyone in?
Anyone in yet? -- Object-oriented design is the roman numerals of computing -- Rob Pike
[9fans] fossil in Plan 9 from User Space
I'm wondering if/when fossil might become part of plan9port. I found only a thread from 2007 mentioning that it had not been ported. It is of particular interest to me because I'm preparing various machines (which are not supported by Plan 9) to manage data on dedicated disks. My thought was to use Plan 9 from User Space, under BSD or Linux as necessary (defending upon hardware support), and fossil to provide a consistent interface to these dedicated disks, and to ensure portability (in case the disks were moved to new platform; to avoid migrating the data to a new file system).
Re: [9fans] fossil in Plan 9 from User Space
-9fans, +plan9port-dev On Tue, Oct 20, 2009 at 4:53 PM, Albert Skye mistl...@yahoo.co.uk wrote: I'm wondering if/when fossil might become part of plan9port. I found only a thread from 2007 mentioning that it had not been ported. It is of particular interest to me because I'm preparing various machines (which are not supported by Plan 9) to manage data on dedicated disks. My thought was to use Plan 9 from User Space, under BSD or Linux as necessary (defending upon hardware support), and fossil to provide a consistent interface to these dedicated disks, and to ensure portability (in case the disks were moved to new platform; to avoid migrating the data to a new file system).
Re: [9fans] anyone in?
We are in. Holiday Inn Express. On Wed, Oct 21, 2009 at 1:13 AM, John Floren slawmas...@gmail.com wrote: Anyone in yet? -- Object-oriented design is the roman numerals of computing -- Rob Pike
Re: [9fans] usb disk error
Can you get the error with the old version of the code?
Nothing really changed, the disk should be asking for timeouts IIRC.
On Tue, Oct 20, 2009 at 9:33 PM, erik quanstrom quans...@quanstro.net wrote:
i don't recall getting these before. this seems
like new behavior. i got 4 of these when downloading
4gb of pictures from a sd card. never in
the same place twice. sb600 ohci controller.
disk... reset: device is detached
it seems that umsrecover - umsreset - usbcmd and
if(usbcmd(ums-dev, r, Umsreset, 0, 0, nil, 0) 0){
fprint(2, disk: reset: %r\n);
i don't see exactly where it is, but could this be
a timeout issue? that's the main difference i see
between now and the previous time. turning on
debugging might not help. there's just too much
of it. sometimes it's many gb of transfer before
an error.
- erik
Re: [9fans] usb disk error
Can you get the error with the old version of the code? nope. - erik
Re: [9fans] anyone in?
I'm here, anyone doing breakfast? Where to go? ron
Re: [9fans] anyone in?
On Tue Oct 20 23:51:46 EDT 2009, rminn...@gmail.com wrote: I'm here, anyone doing breakfast? Where to go? ron what time? i can do ~9:00 i think. how about it's east to the 5-way intersection pm broad and down the hill to the se (oak st) http://www.eatatmamasboy.com/pages/base.php - erik
Re: [9fans] anyone in?
I think we converged on 8am at this thing on college? ron
Re: [9fans] anyone in?
The Grill is on the west side of the first block of college ave. 0xbc iPhone email On Oct 21, 2009, at 12:16 AM, ron minnich rminn...@gmail.com wrote: I think we converged on 8am at this thing on college? ron
Re: [9fans] anyone in?
So, floren and I are meeting in the holiday in lobby at 0730 and then will go find grill. I will bring laptop and will happily demo TVX and burn sticks for anyone who cares. Also bringing sheevaplug. ron
Re: [9fans] anyone in?
SOP for some workshops in the evening for me is to find a lobby with tables couches beer hardware (we supply that) tolerant hotel staff who don't threaten to throw you out at 2 am for not renting a conference room (as happened in Hamburg one year) and having a hack session. don't know if anyone else is interested but we can see. ron
