Re: [9fans] jumpy usb mouse on 9pi
This happens to me sporadically on ThinkPad T400. I can fix it by rebooting. -- Aram Hăvărneanu
Re: [9fans] jumpy usb mouse on 9pi
> moving the > mouse causes the cursor to jump erratically around the screen, almost > exclusively in the vertical direction, along with rio registering button > presses even though I'm not pressing any. This happens when the usb keyboard/mouse driver misinterprets the HID protocol description in the device configuration. Incidentally this is not specific to 9pi -- Plan 9 uses the same usb device drivers on all platforms. Try forcing the mouse to use the simpler boot protocol, by appending 'kbargs=-b' to the command line in cmdline.txt (on dos partition).
[9fans] small VFD display
Hi, I want to drive a small (180x32 pixel) VFD display from plan9. It talks i2c and can be driven as a text or graphics device. One irritation is it aligns bitmap bytes verticaly. i.e. the display's memory map appears to be a tradational 32x180 pixel display. I am going to talk to this from a raspberry pi. I see several options: resurect a small graphics library I wrote in the last milenimum, this knows about the weird layout but only supports rather nasty fonts and very simple windowing. talk text only to the display - again rather nasty fonts. draw the images in a plan9 window under rio. A seperate process which reads /dev/wsys/n/window, transforms it and sends it to the VFD. I would also need a backing buffer in VFD layout so only the changed bytes are sent. Is there another way? Could I run the plan9 graphics subsystem in a stand alone app rather than involving the kernel? I think I can but are there any examples of this? Though this sounds nice, is it worth the hassle of doing this? Any opinions? -Steve
Re: [9fans] small VFD display
On 6 May 2015 at 11:52, Steve Simon wrote: > Could I run the plan9 graphics subsystem in a stand alone app rather > than involving the kernel? > I think I can but are there any examples of this? wsys: https://bitbucket.org/yiyus/devwsys-prev/ It runs in unix. If you have a way to control your screen from some linux in the raspberry, it should not be too difficult to make it work as a cons or win device. > Though this sounds nice, is it worth the hassle of doing this? Probably not, but it might be funny. -- - yiyus || JGL .
Re: [9fans] small VFD display
> wsys: https://bitbucket.org/yiyus/devwsys-prev/ Mmm, not sure this is what I want. I want the Pi to run plan9, and run a seccond display (the vfd) on plan9 completely in user space. It is an interesting project. Personally I still harbour a wish to get a cpu server running on windows - probably using named pipes instead of /srv. Then I should be able to run "cpu -h dosbox -c catclock". Again, its not very useful but would be fun. More useful might be replacing some bits of windows dlls or linux shared libs such that chrome is misdirected into rendering on a remote plan9 box (without the overhead of X11, vnc, or remote desktop). Thats is a lot more work and I will probably never manage it. I an toying with the idea of using a raspberry pi2 running Windows 10 as a cheap, low power "browser co-processor". -Steve
Re: [9fans] small VFD display
Thinking out loud: Most VFD's that I've dealt with were largely text displays - normally you'd see an 8051 or similar driving a mess of shift registers. Essentially, one would jam an ascii byte over GPIO and toggle a latch to update the display. I'm assuming it will be somewhat similar for this display, even though it supports bitmaps. With that in mind, I'd be tempted to write this completely in userspace, likely as an fs that overlays /dev/draw. It might be more hassle than it's worth, but it would be rather fun to run the fs and fire up games/catclock as a PoC. Cheers, Steve On Wed, May 6, 2015 at 4:52 AM, Steve Simon wrote: > Hi, > > I want to drive a small (180x32 pixel) VFD display from plan9. > It talks i2c and can be driven as a text or graphics device. > One irritation is it aligns bitmap bytes verticaly. i.e. the display's > memory map appears to be a tradational 32x180 pixel display. > > I am going to talk to this from a raspberry pi. > > I see several options: > > resurect a small graphics library I wrote in the last milenimum, > this > knows about the weird layout but only supports rather nasty fonts > and > very simple windowing. > > talk text only to the display - again rather nasty fonts. > > draw the images in a plan9 window under rio. A seperate process > which reads /dev/wsys/n/window, transforms it and sends it to the > VFD. > I would also need a backing buffer in VFD layout so only the > changed > bytes are sent. > > Is there another way? > > Could I run the plan9 graphics subsystem in a stand alone app rather > than involving the kernel? > I think I can but are there any examples of this? > Though this sounds nice, is it worth the hassle of doing this? > > Any opinions? > > -Steve > >
Re: [9fans] fossil+venti performance question
Just to be sure, I tried again, and the issue is not related to the lock change on 2013-09-19. However, now I'm sure the issue was caused by a kernel change in 2013. There is no problem when running a kernel from early 2013. -- David du Colombier
Re: [9fans] fossil+venti performance question
On 6 May 2015 at 21:55, David du Colombier <0in...@gmail.com> wrote: > However, now I'm sure the issue was caused by a kernel > change in 2013. > > There is no problem when running a kernel from early 2013. > Welly, welly, welly, well. That is interesting.
Re: [9fans] fossil+venti performance question
I got it! The regression was caused by the NewReno TCP change on 2013-01-24. https://github.com/0intro/plan9/commit/e8406a2f44 -- David du Colombier
Re: [9fans] fossil+venti performance question
Since the problem only happen when Fossil or vacfs are running on the same machine as Venti, I suppose this is somewhat related to how TCP behaves with the loopback. -- David du Colombier
Re: [9fans] fossil+venti performance question
On 6 May 2015 at 22:28, David du Colombier <0in...@gmail.com> wrote: > Since the problem only happen when Fossil or vacfs are running > on the same machine as Venti, I suppose this is somewhat related > to how TCP behaves with the loopback. > Interesting. That would explain the clock-like delays. Possibly it's nearly zero RTT in initial exchanges and then when venti has to do some work, things time out. You'd think it would only lead to needless retransmissions not increased latency but perhaps some calculation doesn't work properly with tiny values, causing one side to back off incorrectly.
Re: [9fans] fossil+venti performance question
Definitely interesting, and explains why I've never seen the regression (I switched to a dedicated venti server a couple of years ago). Were these the changes that erik submitted? ISTR him working on reno bits somewhere around there... On Wed, May 6, 2015 at 4:28 PM, David du Colombier <0in...@gmail.com> wrote: > Since the problem only happen when Fossil or vacfs are running > on the same machine as Venti, I suppose this is somewhat related > to how TCP behaves with the loopback. > > -- > David du Colombier > >
Re: [9fans] fossil+venti performance question
On 6 May 2015 at 23:35, Steven Stallion wrote: > Were these the changes that erik submitted? I don't think so. Someone else submitted a different set of tcp changes independently much earlier.
Re: [9fans] fossil+venti performance question
On Wed May 6 15:30:24 PDT 2015, charles.fors...@gmail.com wrote: > On 6 May 2015 at 22:28, David du Colombier <0in...@gmail.com> wrote: > > > Since the problem only happen when Fossil or vacfs are running > > on the same machine as Venti, I suppose this is somewhat related > > to how TCP behaves with the loopback. > > > > Interesting. That would explain the clock-like delays. > Possibly it's nearly zero RTT in initial exchanges and then when venti has > to do some work, > things time out. You'd think it would only lead to needless retransmissions > not increased latency > but perhaps some calculation doesn't work properly with tiny values, > causing one side to back off > incorrectly. i don't think that's possible. NOW is defined as MACHP(0)->ticks, so this is a pretty course timer that can't go backwards on intel processors. this limits the timer's resolution to HZ, which on 9atom is 1000, and 100 on pretty much anything else. further limiting the resolution is the tcp retransmit timers which according to presotto are /* bounded twixt 0.3 and 64 seconds */ so i really doubt the retransmit timers are resending anything. if someone has a system that isn't working right, please post /net/tcp//^(local remote status) i'd like to have a look. quoting steve stallion ,,, > > Definitely interesting, and explains why I've never seen the regression (I > > switched to a dedicated venti server a couple of years ago). Were these the > > changes that erik submitted? ISTR him working on reno bits somewhere around > > there... > > I don't think so. Someone else submitted a different set of tcp changes > independently much earlier. just for the record, the earlier changes were an incorrect partial implementation of reno. i implemented newreno from the specs and added corrected window scaling and removed the problem of window slamming. we spent a month going over cases from 50µs to 100ms rtt latency and showed that we got near the theoretical max for all those cases. (big thanks to bruce wong for putting up with early, buggy versions.) during the investigation of this i found that loopback *is* slow for reasons i don't completely understand. part of this was the terrible scheduler. as part of the gsoc work, we were able to make the nix scheduler not howlingly terrible for 1-8 cpus. this improvement depends on the goodness of mcs locks. i developed a version of this, but ended up using charles' much cleaner version. there remain big problems with the tcp and ip stack. it's really slow. i can't get >400MB/s on ethernet. it seems that the 3-way interaction between tcp:tx, tcp:rx and the user-space queues is the issue. queue locking is very wasteful as well. i have some student code that addresses part of the latter problem, but it smells to me like ip/tcp.c's direct calls between tx and rx are the real issue. - erik
Re: [9fans] fossil+venti performance question
On Wed May 6 14:28:03 PDT 2015, 0in...@gmail.com wrote: > I got it! > > The regression was caused by the NewReno TCP > change on 2013-01-24. > > https://github.com/0intro/plan9/commit/e8406a2f44 if you have proof, i'd be interested in reproduction of the issue from the original source, or perhaps just nix. let me know if i can help. - erik
Re: [9fans] fossil+venti performance question
On Tue May 5 15:54:45 PDT 2015, ara...@mgk.ro wrote: > It's pretty interesting that at least three people all got exactly > 150kB/s on vastly different machines, both real and virtual. Maybe the > number comes from some tick frequency? i might suggest altering HZ and seeing if there is a throughput change in the same ratio. - erik
Re: [9fans] fossil+venti performance question
> NOW is defined as MACHP(0)->ticks, so this is a pretty course timer > that can't go backwards on intel processors. this limits the timer's > resolution to HZ, > which on 9atom is 1000, and 100 on pretty much anything else. further > limiting the > resolution is the tcp retransmit timers which according to presotto are > /* bounded twixt 0.3 and 64 seconds */ > so i really doubt the retransmit timers are resending anything. if someone > has a system that isn't working right, please post > /net/tcp//^(local remote status) > i'd like to have a look. The Venti listenner: cpu% cat /net/tcp/2/local ::!17034 cpu% cat /net/tcp/2/remote ::!0 cpu% cat /net/tcp/2/status Listen qin 0 qout 0 rq 0.0 srtt 4000 mdev 0 sst 65535 cwin 1460 swin 0>>0 rwin 65535>>0 qscale 0 timer.start 10 timer.count 0 rerecv 0 katimer.start 2400 katimer.count 0 The TCP connection from Fossil to Venti on the loopback: cpu% cat /net/tcp/3/local 127.0.0.1!57796 cpu% cat /net/tcp/3/remote 127.0.0.1!17034 cpu% cat /net/tcp/3/status Established qin 0 qout 0 rq 0.0 srtt 80 mdev 40 sst 1048560 cwin 258192 swin 1048560>>4 rwin 1048560>>4 qscale 4 timer.start 10 timer.count 10 rerecv 0 katimer.start 2400 katimer.count 427 -- David du Colombier
