**** BEGIN LOGGING AT Sun May 19 02:59:58 2013
May 19 03:25:26 <ashes> hello
May 19 03:25:50 <ashes> my arm system's gpu is poorly supported by nvidia. can i play videos and firefox on another machine, and display it in a remote x11 window, or does that still use the arm gpu the same?
May 19 03:29:41 <raster> don't even bother
May 19 03:30:02 <raster> u wil be transferring pixels over the network in uncompressed full framebuffer formats
May 19 03:30:12 <raster> (xshmputimage pixel blobs)
May 19 03:30:20 <raster> if u are super-lucky it may xfer yuv
May 19 03:30:33 <raster> but then it'lll be using your arm's gfx unit to convert yuv-
May 19 03:30:40 <raster> but then it'lll be using your arm's gfx unit to convert yuv-->rgb + scale
May 19 03:31:01 <raster> (xv)
May 19 03:31:35 <raster> chances are it wont use xv as in a browser it has to composite video into the document tree so its converting and scaling to rgb space.
May 19 03:31:52 <raster> as such the nvidia drivers for tegra3 at least are a bit poor
May 19 03:32:06 <raster> they dont do vsync, they dont do buffer swaps (they do dumb copies)
May 19 03:32:10 <raster> for gl anyway
May 19 03:32:31 <raster> so performance-wise you probably lose something like 20-50% of your performance AND you get ugly tearing
May 19 03:32:43 <raster> on local rendering with gl
May 19 03:32:54 <ashes> it's a tegra2
May 19 03:32:57 <raster> remote display is not a world you even want too touch with a barge pole
May 19 03:33:10 <raster> i dont know about tegra2 - but i believe its the same drive3rs for 2 and 3
May 19 03:33:13 <ashes> i already do it
May 19 03:33:19 <ashes> with better systems
May 19 03:33:33 <raster> u dont want to do remote display even with better systems
May 19 03:33:34 <ashes> but nothing with crazy graphics
May 19 03:33:44 <ashes> i dont know if i ever tried mplayer remotely
May 19 03:34:16 <raster> the bandwidth of a netwo9rk is somethnig like 1/1000th of that of a local display
May 19 03:34:25 <raster> i am assuming probably wifi connectivity
May 19 03:34:34 <ashes> no, gigabit switch
May 19 03:34:36 <raster> you also have latency out the wazoo
May 19 03:34:56 <ashes> this arm and other system would be connected with a crossover cable
May 19 03:35:16 <raster>  remote dispay is not something you want to do.. ever.. voluntarily.. unless you have no choice
May 19 03:35:22 <raster> and you never do it if u care about performance
May 19 03:35:23 <raster> ever
May 19 03:35:47 <ashes> my main use for remote x11 is to use handbrake for video editing. the handbrake application doesn't do many frames per second
May 19 03:36:01 <raster> again - don't
May 19 03:36:24 <raster> but it'
May 19 03:36:27 <raster> s your time and effort
May 19 03:36:33 <raster> do what you like with it
May 19 03:36:52 <ashes> in my little experience, remote x11 works just fine for what i have used it for
May 19 03:37:09 <ashes> anyway. my original question
May 19 03:37:37 <raster> i've been doing gfx for pushing on 30 years. written toolkits, apps and wm's for x11/linux for 17 years. this is my simple advice.
May 19 03:37:47 <raster> \don't do remote display unless u can totally avoid it.
May 19 03:38:29 <raster> results all depend on HOWit displays
May 19 03:38:40 <raster> and that varies from app to app and toolkit to toolkit
May 19 03:38:50 <raster> and depends on the capabilities of the xserver
May 19 03:39:52 <raster> fewer and fewer apps/toolkits use regular emote rendering and more and more are pixel pushing or using gl. gl remote is not an option for u due ti it being egl/gles2
May 19 03:40:17 <raster> well not unless u wish to write an extension for it and do all the plumbing too
May 19 03:41:10 <raster> and even then xfer of data (verticieis, textures etc.) will b e raw, and slow over a network cmpared to locally - literally 1000th the speed
May 19 03:41:27 <raster> 1//1000th
May 19 03:42:01 <ashes> with the systems i already do remote x11 with, it's with a 28mB/s ssh connection
May 19 03:42:20 <raster> u're talking an arm systeem
May 19 03:42:24 <ashes> yes
May 19 03:42:28 <ashes> which would be slower
May 19 03:42:34 <ashes> i wouldn't use x11
May 19 03:42:36 <ashes> uh
May 19 03:42:37 <ashes> shh
May 19 03:42:39 <ashes> ssh
May 19 03:42:48 <raster> that will have to expend likely 50% of its dpu resources in JUST handlign the ssh decryption
May 19 03:42:49 <ashes> although the tegra2 is a quad core
May 19 03:43:00 <raster> u will not have a lot left over at that bandwidth
May 19 03:43:11 <raster> no
May 19 03:43:16 <raster> its 2 core
May 19 03:43:16 <ashes> could use telnet
May 19 03:43:25 <ashes> ok, dual core
May 19 03:43:27 <lilstevie> tegra2 is dual core
May 19 03:43:35 <lilstevie> 2 very weak cores
May 19 03:43:38 <raster> u'll likely peg a cpu core on ssh
May 19 03:43:41 <lilstevie> by arm standards
May 19 03:43:47 <lilstevie> raster, don't be silly
May 19 03:43:49 <raster> *IF* u can even maintain that bw
May 19 03:43:52 <lilstevie> arm isn't that terrible
May 19 03:44:09 <raster> lilstevie: it is in my experience.
May 19 03:44:13 <lilstevie> I use ssh all the time both server and client on my tf201
May 19 03:44:29 <raster> if you want it to run an ssh connection sustaining 300mbit
May 19 03:44:36 <lilstevie> and it is nowhere near that bad
May 19 03:44:43 <raster> THEN u have to add protocol decode, memcpy's
May 19 03:45:07 <ashes> ok. to somewhat change the topic, what use can i get from a trimslice, with a tegra2, 1GB memory, and 500GB storage (other than a nas, because i already have a better one)?
May 19 03:45:36 <lilstevie> ashes, well I use mine as a builder
May 19 03:45:51 <lilstevie> for kernels
May 19 03:46:14 <ashes> yes, ok. what else?
May 19 03:47:24 <lilstevie> thats all I do with it
May 19 03:47:31 <lilstevie> trimslice is getting fairly old these days
May 19 03:47:56 <ashes> my idea was to give it to my 6 year old nephew as a desktop, but he will expect to play movies and youtube with it
May 19 03:48:04 <raster> lilstevie: tesxgre3. 1.2ghz. sshd consumes about 40% cpu of 1 core to keep an scp at 2.8mb/sec
May 19 03:48:08 <raster> right here now.
May 19 03:48:10 <raster> doing it
May 19 03:48:26 <ashes> raster: use arcfour
May 19 03:48:26 <raster> ashes is talking of wantingh to systain 28mb/s
May 19 03:48:38 <raster> sustain
May 19 03:48:41 <raster> thats 10x
May 19 03:48:52 <raster> u wont evben systain it
May 19 03:49:02 <raster> damnit
May 19 03:49:04 <raster> damn cat
May 19 03:49:06 <raster> tegra3
May 19 03:49:09 <raster> 1.2ghz
May 19 03:49:20 <lilstevie> good luck sustaining that rate in general on the trimslice though
May 19 03:49:42 <lilstevie> even though it is a gigabit card, I do find it cannot sustain that kind of speed
May 19 03:49:52 <raster> yup
May 19 03:49:54 <ashes> raster: scp -o Ciphers arcfour
May 19 03:49:55 <raster> thats what i said
May 19 03:50:03 <raster> it'll peg a core at 100% cpu
May 19 03:50:04 <ashes> and forget ssh
May 19 03:50:09 <ashes> i can use telnet
May 19 03:50:51 <lilstevie> raster, it isn't so much the core, I don't think the pci-e bus is fast enough to support the rates of a gigabit card
May 19 03:50:52 <raster> ashes:  even with that it runs about 25% cpui
May 19 03:50:56 <raster> for 3mb/sec
May 19 03:51:00 <raster> again
May 19 03:51:10 <raster> at 10 TIMES that badnwdith.. there is simply not enough compute
May 19 03:51:18 <lilstevie> raster, also in your config how is the network attached
May 19 03:51:22 <ashes> telnet would be dramatically faster
May 19 03:51:30 <raster> lilstevie:  this is wifi - thus the low rates
May 19 03:51:36 <raster> i am not caring about that end of things
May 19 03:51:51 <lilstevie> raster, well that is probably putting a little bit of strain on the cpu too
May 19 03:51:52 <lilstevie> :p
May 19 03:51:59 <raster> the cpu  overheadalone of sshd will peg your bandwidth
May 19 03:52:03 <raster> sure
May 19 03:52:33 <ashes> or rsh
May 19 03:52:38 <raster> my point is for remote display you have several thigns that will kill the ui
May 19 03:52:58 <raster> 1. network devide3 handling itself (packet handling and at least 1 or 2 memcpy's there)
May 19 03:53:02 <lilstevie> eh, remote display is problematic on x86 in the best of conditions
May 19 03:53:04 <raster> then more memcpy's within the xserver
May 19 03:53:25 <raster> vs only a single memcpy locally for local display
May 19 03:53:44 <raster> add to that the bandwidth bottleneck of the networi deevice
May 19 03:54:01 <raster> remember memcpy bandwdith will clock in at the magnitudes of 500-1500mb/se
May 19 03:54:13 <raster> at least on something tegra2-land
May 19 03:54:16 <raster> or tegra3
May 19 03:54:39 <raster> your gitibit card will drop you to 100mb/s
May 19 03:54:41 <raster> gitbit
May 19 03:54:44 <raster> gigabit
May 19 03:54:50 <raster> thats IN THEORY.. if u can systain it
May 19 03:55:14 <raster> add do that sshd bottlenecking your connection maybe to 10mb/sec on the best of days
May 19 03:55:27 <raster> and soaking up a whole core on its own\
May 19 03:55:39 <raster> add in the protocol handling by xserver, memcpy's etc.
May 19 03:55:40 <ashes> you may very well know exactly what you're talking about, but i'll try it to see for myself
May 19 03:56:09 <raster> you are now looking at just pure bandwidth-wise like 1-2mb/sec of effective bw
May 19 03:56:15 <ashes> because i want to get some use out of it
May 19 03:56:19 <raster> now throw in latencies more like 1-2ms
May 19 03:56:54 <raster> whrere local latencies (round trips) are more in the 1/100th or less of that...
May 19 03:57:35 <raster> unless your app is so insanely trivial where the overheads just barely make the effects visible... it'll be nasty to do remote x11 display however you look at it
May 19 03:57:51 <raster> the model that works is high level control protocol
May 19 03:57:54 <raster> with local display
May 19 03:58:17 <raster> the problem comes when you simply cant avoid xferring large gobs of data around as part of the display
May 19 03:59:16 <raster> it's then that you play tricks in downgrading the data quality (eg downscaling by 2x2 or 4x4 nd using local gpu+interpolation to upscale again) to retain interactivity
May 19 03:59:32 <raster> and you are only xferring some susbet of the frame data across the network
May 19 04:05:51 <raster> xzzzzz``````
**** ENDING LOGGING AT Mon May 20 02:59:59 2013