<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> James P. Kinney III wrote: <blockquote cite="mid1173070320.18688.280.camel@merlin.localnetsolutions.com" type="cite"> <pre wrap="">On Sun, 2007-03-04 at 22:41 -0500, "Terrell Prudé Jr." wrote: </pre> <blockquote type="cite"> <pre wrap="">Try upgrading your video card. The problem that you're discussing has nothing to do with CPU, but rather is a video card speed issue. I replaced an ancient S3 Trio64 with a Matrox Millenium G400, and my issues with slow video playback went away. The thin client is a Pentium II-300MHz. My server is a dual Athlon MP 1.2GHz with 2GB DRAM. Now, unless you're trying to run a LTSP *server* on a Pentium II-300MHz or something else ridiculous like that, CPU ain't your problem, dude. </pre> </blockquote> <pre wrap=""> Upgrading the video card is not an option since these are brand new HP T5125 thin clients and I deployed 2200 of them. The process of viewing video clips using thin clients requires that the server do the heavy lifting, not the client. For the same reason than 3D-accelerated graphics won't work in a thin -client setup, neither will using the graphics card to do the video decompression. </pre> </blockquote> That sounds like a video driver issue, actually. I have 3D accelerated video working just fine on my thin clients. But I've also got a video chipset that is very well supported by X11. This is a big factor; I tried a modern nVidia card in that same thin client, and things got D-A-W-G slow. You're partly right; the client's CPU doesn't do any heavy lifting. But the client's *video board* does in certain cases. <blockquote cite="mid1173070320.18688.280.camel@merlin.localnetsolutions.com" type="cite"> <pre wrap=""> The servers - all 24 application/boot servers - are dual CPU/dual core Opteron 1.8GHz w/ 8 GB RAM and 6 Gb NICs with 4 bonded for data pipe to the thin clients are all connected with 1000BT networking down to the gig switch in each classroom. The clients are the only thing running slower. </pre> <pre wrap=""> I have an average of 90 clients per server. In actuality, I have one with 123 clients and a couple with 110. </pre> </blockquote> My God...are all of these 90 clients/server streaming video simultaneously?? On my dual Athlon 1.2GHz, I show a 640x480 MPEG4 session taking up 21% of one CPU (no frame drops). So, I think I could reasonably get away with 8--maybe 9, but that's pushing it--sessions at that resolution using both of my CPU's. Another MPEG4 clip at 320x240 used up 7% (the HOSEF clip on K12LTSP from last year), so I could do a lot more--maybe 13 per CPU, or 26 total simultaneous--at that resolution. Your network bandwidth does seem to be fine if your bonding four Gig-E NICs; at 45Mbps per session, you can get away with 88 simultaneous streams of that size before the network becomes a bottleneck. That assumes that nothing else is crossing that pipe at the same time, of course (thick clients using the K12LTSP server as a router, etc.). So, for streaming locally from the K12LTSP server, and assuming that there are no errors (faulty cable, dirty connection, etc.), the LTSP LAN looks fine. If you're not streaming locally, i. e. you're doing it from the Internet, then have you made sure that you have a sufficiently large pipe to the Internet for however many sessions that you're streaming at once? We ran into that problem with United Streaming and had to install "cache" servers. Each of our "cache" servers goes and downloads the videos from United Streaming at night, storing them on their (very large) RAID 5 arrays. Then, when our teachers want to play United Streaming videos in class, they get redirected via policy routing to our cache server bank, thus saving our Internet pipe. <blockquote cite="mid1173070320.18688.280.camel@merlin.localnetsolutions.com" type="cite"> <blockquote type="cite"> <pre wrap="">Please stop the FUD and ask questions before you go spouting off erroneous conclusions, </pre> </blockquote> <pre wrap=""> Not to sound like I'm biting your head off for the FUD statement, but I have tested this and found that it simply isn't a workable process to use thin clients _reliably_ to watch video clips. The synch between sound and video gets off pretty quick depending on server load, the video is halting and pixilated. I have not been replying much for the past 6 months on this list as I've been a bit busy installing those 220 clients and 24 servers here in Atlanta. </pre> </blockquote> That is great that you're installing all those, and I wish that my own district would be open-minded enough to try it. We could use some Atlanta common-sense in that way here where I live. But I must re-interate: I've gotten video to work just fine on LTSP clients, and it wasn't that hard. If you've got 90 clients/server streaming video simultaneously, try breaking that up some among more servers. That's a heavy load, even with two dual-core Opterons per server. --TP </body> </html>