linux as a minicomputer ?
Sorry if this isn't the place for this question, but it's something that
came up in general office talk today.
Many many moons ago, the GGI project promised us the ability to buy a
four-processor box, four PCI video cards, four USB mice & keyboards, and let four people use that machine at once, with benefits all around.
This would be wonderful for most people (leaving aside someone doing a
'make -j4' on the kernel, while the three others are playing Wolfenstein) in offices and other shared environments.
Are there any plans to bring this sort of functionality to Linux 2.6 ? As
I remember, some of the problems were that the GGI code was never going to get into Linux proper, and enumeration of multiple keyboards and mice, but I would have thought that was there a need, these problems would have been fixed by now.
Kate
Signature · 4 lines
_______________________________________ John Looney Chief Scientist a n t e f a c t o t: +353 1 8586004 www.antefacto.com f: +353 1 8586014
Quoted 6 lines · * John P. Looney ([email protected]) wrote:
Sorry if this isn't the place for this question, but it's something that
came up in general office talk today.Many many moons ago, the GGI project promised us the ability to buy a
four-processor box, four PCI video cards, four USB mice & keyboards, and let four people use that machine at once, with benefits all around.
<snip>
Quoted 5 lines
Are there any plans to bring this sort of functionality to Linux 2.6 ? As
I remember, some of the problems were that the GGI code was never going to get into Linux proper, and enumeration of multiple keyboards and mice, but I would have thought that was there a need, these problems would have been fixed by now.
I'm not sure, but I don't think any code is needed if you run X. Bung four USB mice, four USB keyboards in and four video cards. Write a separate X config for each one specifying which PCI card should be used and which mouse/keyboard device should be used. Now start an X server for each one.
(Fun should form in the efforts to figure out which mouse is associated with which keyboard and with which video output).
Dave
---------------- Have a happy GNU millennium! ----------------------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM, SPARC and HP-PA | In Hex / \ _________________________|_____ http://www.treblig.org |_______/
Quoted 16 lines · Dr. David Alan Gilbert
Quoted 6 lines · * John P. Looney ([email protected]) wrote:
Sorry if this isn't the place for this question, but it's something that
came up in general office talk today.Many many moons ago, the GGI project promised us the ability to buy a
four-processor box, four PCI video cards, four USB mice & keyboards, and let four people use that machine at once, with benefits all around.<snip>
Quoted 5 lines
Are there any plans to bring this sort of functionality to Linux 2.6 ? As
I remember, some of the problems were that the GGI code was never going to get into Linux proper, and enumeration of multiple keyboards and mice, but I would have thought that was there a need, these problems would have been fixed by now.
Quoted 5 lines
I'm not sure, but I don't think any code is needed if you run X. Bung four USB mice, four USB keyboards in and four video cards. Write a separate X config for each one specifying which PCI card should be used and which mouse/keyboard device should be used. Now start an X server for each one.
Doesn't work unfortunately. The separate Xservers stomp on each others toes in the process. It works if you use fbcon (thus no acceleration, no 3d), USB, and hack the X servers not to switch consoles, and take keyboard input from /dev/input/event devices. But that's still far from the desired state of things.
Quoted 2 lines
(Fun should form in the efforts to figure out which mouse is associated with which keyboard and with which video output).
Signature · 2 lines
Vojtech Pavlik SuSE Labs
Quoted 23 lines · Vojtech Pavlik
Quoted 16 lines · Dr. David Alan Gilbert
Quoted 6 lines · * John P. Looney ([email protected]) wrote:
Sorry if this isn't the place for this question, but it's something that
came up in general office talk today.Many many moons ago, the GGI project promised us the ability to buy a
four-processor box, four PCI video cards, four USB mice & keyboards, and let four people use that machine at once, with benefits all around.<snip>
Quoted 5 lines
Are there any plans to bring this sort of functionality to Linux 2.6 ? As
I remember, some of the problems were that the GGI code was never going to get into Linux proper, and enumeration of multiple keyboards and mice, but I would have thought that was there a need, these problems would have been fixed by now.Quoted 5 lines
I'm not sure, but I don't think any code is needed if you run X. Bung four USB mice, four USB keyboards in and four video cards. Write a separate X config for each one specifying which PCI card should be used and which mouse/keyboard device should be used. Now start an X server for each one.
Quoted 5 lines
Doesn't work unfortunately. The separate Xservers stomp on each others toes in the process. It works if you use fbcon (thus no acceleration, no 3d), USB, and hack the X servers not to switch consoles, and take keyboard input from
/dev/input/eventdevices. But that's still far from the desired state of things.
why would they step on eachother's toes? You tell each one to goto a separate vc and give each a separate identifier :2 vt8 :3 vt9 etc. If each one is using a separate video card, then they should all be able to run accelerated (no dri) and be fine.
Quoted 3 lines
Quoted 2 lines
(Fun should form in the efforts to figure out which mouse is associated with which keyboard and with which video output).
Quoted 7 lines · * Vojtech Pavlik ([email protected]) wrote:
Doesn't work unfortunately. The separate Xservers stomp on each others toes in the process. It works if you use fbcon (thus no acceleration, no 3d), USB, and hack the X servers not to switch consoles, and take keyboard input from
/dev/input/eventdevices. But that's still far from the desired state of things.
Oh how annoying - where do they get knotted up? I'd presumed this was the whole point of the busid spec in the config file.
Dave
---------------- Have a happy GNU millennium! ----------------------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM, SPARC and HP-PA | In Hex / \ _________________________|_____ http://www.treblig.org |_______/
Quoted 5 lines · Rene Rebe
On: Thu, 11 Apr 2002 17:49:42 +0000,
Quoted 3 lines · John P. Looney
On Thu, Apr 11, 2002 at 07:13:39PM +0200, Vojtech Pavlik mentioned:
Quoted 2 lines
Quoted 2 lines
I'd presumed this was
the whole point of the busid spec in the config file.
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
No, it's for running one Xserver on multiple displays at once only. Sad, ain't it?
Very sad. Nice to know it's not really the kernel's fault.
It IS the kernel's fault, because only one VT can be active. The kernel VT stuff needs to be redesigned to hadle multiple VT at the same time ...
Yes and no. You shouldn't need VTs to run Xservers at all.
Signature · 2 lines
Vojtech Pavlik SuSE Labs
Quoted 5 lines · Vojtech Pavlik
Quoted 3 lines
It IS the kernel's fault, because only one VT can be active. The kernel VT stuff needs to be redesigned to hadle multiple VT at the same time ...
Yes and no. You shouldn't need VTs to run Xservers at all.
Still a kernel problem, what if all the users want to run vgacon/fbcon instead of X? One VT per physical interface is what we need, rather than "per machine".
Helge Hafting
Quoted 11 lines · Helge Hafting
Quoted 5 lines · Vojtech Pavlik
Quoted 3 lines
It IS the kernel's fault, because only one VT can be active. The kernel VT stuff needs to be redesigned to hadle multiple VT at the same time ...
Yes and no. You shouldn't need VTs to run Xservers at all.
Still a kernel problem, what if all the users want to run vgacon/fbcon instead of X? One VT per physical interface is what we need, rather than "per machine".
Yes. James Simmons has this work almost done.
Signature · 2 lines
Vojtech Pavlik SuSE Labs
Quoted 6 lines
Quoted 3 lines
3d), USB, and hack the X servers not to switch consoles, and take keyboard input from
/dev/input/eventdevices. But that's still far from the desired state of things.Oh how annoying - where do they get knotted up? I'd presumed this was the whole point of the busid spec in the config file.
It depends whether there are overlapping resources and the like. You can make it work but its less trivial than it seems if you have cards that have to be mapped into the VGA space to do certain operations
Quoted 29 lines · Ed Sweetman
Quoted 23 lines · Vojtech Pavlik
Quoted 16 lines · Dr. David Alan Gilbert
Quoted 6 lines · * John P. Looney ([email protected]) wrote:
Sorry if this isn't the place for this question, but it's something that
came up in general office talk today.Many many moons ago, the GGI project promised us the ability to buy a
four-processor box, four PCI video cards, four USB mice & keyboards, and let four people use that machine at once, with benefits all around.<snip>
Quoted 5 lines
Are there any plans to bring this sort of functionality to Linux 2.6 ? As
I remember, some of the problems were that the GGI code was never going to get into Linux proper, and enumeration of multiple keyboards and mice, but I would have thought that was there a need, these problems would have been fixed by now.Quoted 5 lines
I'm not sure, but I don't think any code is needed if you run X. Bung four USB mice, four USB keyboards in and four video cards. Write a separate X config for each one specifying which PCI card should be used and which mouse/keyboard device should be used. Now start an X server for each one.
Quoted 5 lines
Doesn't work unfortunately. The separate Xservers stomp on each others toes in the process. It works if you use fbcon (thus no acceleration, no 3d), USB, and hack the X servers not to switch consoles, and take keyboard input from
/dev/input/eventdevices. But that's still far from the desired state of things.
Quoted 4 lines
why would they step on eachother's toes? You tell each one to goto a separate vc and give each a separate identifier :2 vt8 :3 vt9 etc. If each one is using a separate video card, then they should all be able to run accelerated (no dri) and be fine.
1) Only one VT can be active at a time. Even with multiple cards. Thus only one X server will be active at a time, others will show a blank screen.
2) If you hack out the VT switching out of X, then still each X server will disable all PCI resources for other video cards, because it believes it owns the system. This will freeze all other active X servers.
Signature · 2 lines
Vojtech Pavlik SuSE Labs
Quoted 8 lines · Dr. David Alan Gilbert
Quoted 6 lines
Doesn't work unfortunately. The separate Xservers stomp on each others toes in the process. It works if you use fbcon (thus no acceleration, no 3d), USB, and hack the X servers not to switch consoles, and take keyboard input from
/dev/input/eventdevices. But that's still far from the desired state of things.Oh how annoying - where do they get knotted up?
See my other mail.
Quoted 2 lines
I'd presumed this was
the whole point of the busid spec in the config file.
No, it's for running one Xserver on multiple displays at once only.
Sad, ain't it?
Signature · 2 lines
Vojtech Pavlik SuSE Labs
On Thu, Apr 11, 2002 at 07:13:39PM +0200, Vojtech Pavlik mentioned:
Quoted 4 lines
Quoted 2 lines
I'd presumed this was
the whole point of the busid spec in the config file.No, it's for running one Xserver on multiple displays at once only. Sad, ain't it?
Very sad. Nice to know it's not really the kernel's fault.
Is it possible to say "Any mice plugged in to this port is/dev/input/mouse3" etc. so that if someone plugged out your mouse, plugged in another into a different port, and you plugged yours back in, that they wouldn't renumberate ?
Kate
Signature · 4 lines
_______________________________________ John Looney Chief Scientist a n t e f a c t o t: +353 1 8586004 www.antefacto.com f: +353 1 8586014
On: Thu, 11 Apr 2002 17:49:42 +0000,
Quoted 7 lines · John P. Looney
On Thu, Apr 11, 2002 at 07:13:39PM +0200, Vojtech Pavlik mentioned:
Quoted 4 lines
Quoted 2 lines
I'd presumed this was
the whole point of the busid spec in the config file.No, it's for running one Xserver on multiple displays at once only. Sad, ain't it?
Very sad. Nice to know it's not really the kernel's fault.
It IS the kernel's fault, because only one VT can be active. The kernel VT stuff needs to be redesigned to hadle multiple VT at the same time ...
Quoted 6 lines
Is it possible to say "Any mice plugged in to this port is
/dev/input/mouse3" etc. so that if someone plugged out your mouse, plugged in another into a different port, and you plugged yours back in, that they wouldn't renumberate ?Kate
k33p h4ck1n6
René
Signature · 10 lines
René Rebe (Registered Linux user: #248718 <http://counter.li.org>) eMail: [email protected] [email protected] Homepage: http://drocklinux.dyndns.org/rene/ Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms.
Quoted 9 lines
Quoted 5 lines
Quoted 3 lines
No, it's for running one Xserver on multiple displays at once only. Sad, ain't it?
Very sad. Nice to know it's not really the kernel's fault.
It IS the kernel's fault, becauslle only one VT can be active. The kernel VT stuff needs to be redesigned to hadle multiple VT at the same time ...
Correct. The current VT system assumes only one active VT at a time.
Also the VT system has lots and lots of global variables which make it non re-entry. Go examples of dumbness are when running mdacon and vgacon when you blanks both displays blank. This is bad. Also you can VC switch from a vga VC to a mda VC but it doesn't quite work.
I already have reworked the console system to fix the many bugs and I
have already placed some of it into the dave jones tree. I haven't removed the global fg_console since it would break a few drivers. This is why I have been pushing people to port over there keyboard drivers to the input api. I'm also pushing the new fbdev api for the same reason. This way I can change the console system without break lots of drivers.
For example is the fg_console variable. At present the following
drivers use it and it should be removed.
atyfb_base.caty128fb.cradeonfb.c
By porting to the new fbdev api the fg_console can be removed.
The following keyboard drivers use fg_console.
sunkbd.cstreamable.cmac_keyb.c
We already have a Mac input driver so mac_keyb.c could go away. We also have a sunkbd input driver as well. It this case it is a matter of writing a proper serio layer driver for the input layer. Streamable needs to ported to the input api layer. Several over files use fg_console but they are not low level drivers so they easly can be fixed.
All of these changes are in the dave jones tree but I hope to start pushing these changes to Linus.
Quoted 6 lines
Quoted 5 lines
Quoted 3 lines
I'd presumed this was
the whole point of the busid spec in the config file.No, it's for running one Xserver on multiple displays at once only. Sad, ain't it?
Quoted 6 lines
Very sad. Nice to know it's not really the kernel's fault.
Is it possible to say "Any mice plugged in to this port is
/dev/input/mouse3" etc. so that if someone plugged out your mouse, plugged in another into a different port, and you plugged yours back in, that they wouldn't renumberate ?
Enable Hotplug :-) The input layer supports it!!
Quoted 6 lines · John P. Looney
On Thu, Apr 11, 2002 at 07:13:39PM +0200, Vojtech Pavlik mentioned:
Quoted 4 lines
Quoted 2 lines
I'd presumed this was
the whole point of the busid spec in the config file.No, it's for running one Xserver on multiple displays at once only. Sad, ain't it?
Quoted 6 lines
Very sad. Nice to know it's not really the kernel's fault.
Is it possible to say "Any mice plugged in to this port is
/dev/input/mouse3" etc. so that if someone plugged out your mouse, plugged in another into a different port, and you plugged yours back in, that they wouldn't renumberate ?
No, that is not possible. However, on plugging the mouse, /sbin/hotplug will be called with appropriate arguments to allow to take any action needed (symlinking, sending a signal, whatever) to make the mouse keep working. Also a list of existing devices is available under /proc/bus/input/devices for applications to look at and reconfigure in case of a hotplug event.
Signature · 2 lines
Vojtech Pavlik SuSE Labs
Followup to: <[email protected]> By author: "John P. Looney" <[email protected]> In newsgroup: linux.dev.kernel
Quoted 5 lines
Many many moons ago, the GGI project promised us the ability to buy a
four-processor box, four PCI video cards, four USB mice & keyboards, and let four people use that machine at once, with benefits all around.
"Benefits all around?" Such a machine would be slower and more expensive than four single processor boxes, so what's the point?
This is fundamentally the problem with these kinds of schemes -- they get outcompeted on price and availability by the massmarket items. This is part of the very attraction of Linux -- it's running Unix on stock, cheap, hardware.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Quoted 8 lines
Quoted 5 lines
Many many moons ago, the GGI project promised us the ability to buy a
four-processor box, four PCI video cards, four USB mice & keyboards, and let four people use that machine at once, with benefits all around."Benefits all around?" Such a machine would be slower and more expensive than four single processor boxes, so what's the point?
Not with the right hardware combinations. The four processors is over kill. I have a multi-desktop system that is dual and it is plenty of power. With a regular machine just put in two matrox g450 cards and enable dual head support. Attach 3 extra USB keyboards and 3 USB mice and you are ready to go. With purpore kernel support of course. So the cost is no longer a issue.
Quoted 9 lines · James Simmons
Quoted 2 lines
"Benefits all around?" Such a machine would be slower and more expensive than four single processor boxes, so what's the point?
Not with the right hardware combinations. The four processors is over kill. I have a multi-desktop system that is dual and it is plenty of power. With a regular machine just put in two matrox g450 cards and enable dual head support. Attach 3 extra USB keyboards and 3 USB mice and you are ready to go. With purpore kernel support of course. So the cost is no longer a issue.
Almost exactly what I want, except I'll go for one g450 and two screens only. Administrating one home machine is fun, two less so. Only one box heathing the room. Only one box taking up space. Less cabling.
Two persons using a dual is better than two people with two UP computers, because the power user may use more than one cpu.
Helge Hafting
Quoted 2 lines
"Benefits all around?" Such a machine would be slower and more expensive than four single processor boxes, so what's the point?
A lot more manageable and for many setups a lot of terminals in one box actually makes a lot of sense
Quoted 4 lines
This is fundamentally the problem with these kinds of schemes -- they get outcompeted on price and availability by the massmarket items. This is part of the very attraction of Linux -- it's running Unix on stock, cheap, hardware.
The hardware is now massmarket - otherwise I'd agree wholeheartedly. Video cards are cheap, USB2.0 cards have 4 root bridges per card.
Quoted 9 lines · Alan Cox
Quoted 5 lines
This is fundamentally the problem with these kinds of schemes -- they get outcompeted on price and availability by the massmarket items. This is part of the very attraction of Linux -- it's running Unix on stock, cheap, hardware.
The hardware is now massmarket - otherwise I'd agree wholeheartedly. Video cards are cheap, USB2.0 cards have 4 root bridges per card.
Oh yes, but the *expensive* part of the machine -- the multiprocessor box -- isn't.
Also, when using massmarket systems of more than 2 or 3 monitors you start having cabling problems. VGA connectors aren't impedance matched and cause nasty reflections at high resolutions, so they don't extend well. I guess digital video is coming, but is not yet mass market.
-hpa
Quoted 2 lines
Oh yes, but the *expensive* part of the machine -- the multiprocessor box -- isn't.
If you need SMP (frequently doubtful) its a price, but dual celeron and dual duron are cheap if you buy them from sensible vendors.
Quoted 4 lines
Also, when using massmarket systems of more than 2 or 3 monitors you start having cabling problems. VGA connectors aren't impedance matched and cause nasty reflections at high resolutions, so they don't extend well. I guess digital video is coming, but is not yet mass market.
Indeed and most of it is not specced for long distances. It will also no doubt be held up even more now the encryption on the wire wants to be augmented by the newer watermarking stuff so the monitor won't show movies without authorization
Alan
Quoted 5 lines · Alan Cox
Quoted 1 line
Oh yes, but the *expensive* part of the machine -- the multiprocessor box -- isn't.
If you need SMP (frequently doubtful) its a price, but dual celeron and dual duron are cheap if you buy them from sensible vendors.
Quoted 7 lines
Quoted 1 line
Also, when using massmarket systems of more than 2 or 3 monitors you start having cabling problems. VGA connectors aren't impedance matched and cause nasty reflections at high resolutions, so they don't extend well. I guess digital video is coming, but is not yet mass market.
Indeed and most of it is not specced for long distances. It will also no doubt be held up even more now the encryption on the wire wants to be augmented by the newer watermarking stuff so the monitor won't show movies without authorization
If you're talking about things like setting up multiheaded UP and dual-processor machines for, say, an undergraduate lab in a university, then I think you're probably on the right track -- *especially* if the alternative would be using X-terminals (gack!!!) to leech the CPU power anyway.
Otherwise, I think that's probably the main "minicomputeresque" form of Linux usage -- remote X display.
-hpa
Quoted 5 lines · Alan Cox
Quoted 2 lines
Oh yes, but the *expensive* part of the machine -- the multiprocessor box -- isn't.
If you need SMP (frequently doubtful) its a price, but dual celeron and dual duron are cheap if you buy them from sensible vendors.
I guess dual Doron is okay if you are really trying to build a super
cheap system, but dual Celeron? The last dual Celeron m/b I saw was the BP6, and I have a bunch of them in various places. Is that the board you're remembering? It uses CPUs no longer available.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 3 lines
cheap system, but dual Celeron? The last dual Celeron m/b I saw was the BP6, and I have a bunch of them in various places. Is that the board you're remembering? It uses CPUs no longer available.
There are much newer dual Celeron boards. Maybe they just don't sell them in the USA any more ?
Quoted 6 lines · Alan Cox
Quoted 3 lines
cheap system, but dual Celeron? The last dual Celeron m/b I saw was the BP6, and I have a bunch of them in various places. Is that the board you're remembering? It uses CPUs no longer available.
There are much newer dual Celeron boards. Maybe they just don't sell them in the USA any more ?
eeeh, after 533, starting with the celeron A intel basically succeeded in breaking smp on celerons. And they also switched to using borked p3's for celerons ( 256k cache vs 128k ) if the rumors are true :).
There were some ppl doing realy nasty voltage mods but nothing conclusive ever came of that. The last thing I heard was that asus succeeded in making a dual p4, but I dont expect much from that corner.
So you're stuck with p3 or xeon, going the amd route might be smarter if you want something affordable.
Signature · 4 lines
Sten Spans "What does one do with ones money, when there is no more empty rackspace ?"
OK, clearing aside the deep technical arguments about lengths of coax and what you can do with a couple of celerons, it seems obvious to me that for at least some menial jobs a box with multiple separate screens is useful. (Think two or three secretarys sitting next to each other with a PC in the middle, low processor needs, short leads).
Dave
---------------- Have a happy GNU millennium! ----------------------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM, SPARC and HP-PA | In Hex / \ _________________________|_____ http://www.treblig.org |_______/
Quoted 5 lines · Dr. David Alan Gilbert
OK, clearing aside the deep technical arguments about lengths of coax and what you can do with a couple of celerons, it seems obvious to me that for at least some menial jobs a box with multiple separate screens is useful. (Think two or three secretarys sitting next to each other with a PC in the middle, low processor needs, short leads).
Actually, it's not just about simple component cost. There are other considerations, especially in a business environment. I actually did a paper for my technical writing class a year ago and found the best solution was cheap terminals connected to a good, single-processor server. Target environment for the study was a 10-workstation medical services company here in Omaha. SMP didn't turn out to be the most cost effective solution, much to my surprise.
Key question is how much does it cost if data is compromised or lost, and how much does it cost to ensure that bad things don't happen.
Followup to: <20020414165056.GJ16692@gallifrey> By author: "Dr. David Alan Gilbert" <[email protected]> In newsgroup: linux.dev.kernel
Quoted 7 lines
OK, clearing aside the deep technical arguments about lengths of coax and what you can do with a couple of celerons, it seems obvious to me that for at least some menial jobs a box with multiple separate screens is useful. (Think two or three secretarys sitting next to each other with a PC in the middle, low processor needs, short leads).
Agreed. This is somewhat different than the "50 processors for 50 users" scenario, but sharing a single- or dual-processor machine should be quite feasible for some applications.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Quoted 6 lines · Alan Cox
Quoted 3 lines
cheap system, but dual Celeron? The last dual Celeron m/b I saw was the BP6, and I have a bunch of them in various places. Is that the board you're remembering? It uses CPUs no longer available.
There are much newer dual Celeron boards. Maybe they just don't sell them in the USA any more ?
You can get a dual athlon motherboard down at fry's for about $180, cash and carry. (I was there the day before yesterday, they had tyan tiger, tyan thunder, and some kind of Asus. I believe the $180 one was the tyan tiger...)
Add 512k DDR 2100 SDRAM (I believe the newspaper said it was on sale for around $110), a 160 gig maxtor ide drive (~$200 after mail-in rebate), throw it in a case...
Trust me, two 1.4 ghz athlons is PLENTY of CPU power. That's just about enough CPU power to compress mp4 video in realtime. (We've got one here doing just that, although we haven't tried feeding a live video signal into it, I so dunno how much buffering it would neet to avoid dropping frames, or what kind of latency spikes we're talking about...)
In terms of use as a workstation... 2800 mhz divided by 7 people is 400 mhz each. Not that it really quite works that way, but if you think giving them a 400 mhz system of their own is reasonable (minus L1 cache contention, plus DDR SDRAM/faster FSB, and the three execution cores in an athlon...)
The killer is that if one person drives the machine into swap, performance melts down for everybody. THAT is what makes the idea of a multi-headed linux box as a many-way shared workstation seem a lot less workable to me. (I'll admit swap behavior sucks a lot less than it used to, but is this an endorsement? There's no attempt at all to make swapping fair with multiple users on a box. Maybe rmap will help here...)
Rob
Quoted 3 lines
(I'll admit swap behavior sucks a lot less than it used to, but is this an endorsement? There's no attempt at all to make swapping fair with multiple users on a box. Maybe rmap will help here...)
The rmap VM has the needed infrastructure and can already enforce per process rss limits. Once it can enforce some kind of per user rss limits you get what is needed.
Quoted 3 lines · Rob Landley
The killer is that if one person drives the machine into swap, performance melts down for everybody. THAT is what makes the idea of a multi-headed linux box as a many-way shared workstation seem a lot less workable to me.
No problem. This is precisely what "ulimit" is for - prevent single users from grabbing too much resources on a multiuser machine. Distributions default to not use it because most machines are single-user,
this however is the occation where you need it. Of course you can afford
more RAM for the 4-user machine, and shared memory for kernel and executable
code helps too...
Helge Hafting
Quoted 11 lines · Stephen Samuel
It's stell cheaper to get 1~1.5G for 4 users than 512M for each of them, to avoid them spiking into swap space. Total RAM overhead is likely to be a bit less (shared memory), and memory or CPU usage spikes are easier to eat with a faster machine with a bit less ram than the total shared between 4 users.
If a user 'spikes'' for a long period of time, than THAT ammount of ram should be considered the baseline for that user. In any case, It's still likely to be cheaper to buy the RAM needed to keep 4 users happy in one box than to keep them all happy in separate boxes.
It also makes sense to stick a cheap three or four disk IDE RAID in the box and get some approximation of redundant data storage. (If you're sharing everything but the user directories anyway, you can get away with devoting 1/4 the disk space to a parity disk without really losing out in bang for the buck terms. AND you get more speed out of it (especially if you're distributing swap space in paralell).)
You can even stick in a spare IDE controller in a PCI slot so each drive gets to be a master on its own cable, to double the bandwidth again... (Sticking a RAID in individual workstations, on the other hand, is probably expensive overkill, and actually quadrupling the amount of maintenance since hard drives are one of the main moving parts of the box. Distributing your swap space will still crash the box when a drive dies, it just means your system and data partitions should be easily recoverable when you reboot with a new drive in there. We're not talking six nines of uptime for any box with only one power supply anyway (ANOTHER moving part :). Although a UPS makes economic sense for a shared box as well. (That that it could power four monitors, but maybe four LCDs? Or at least save your data and shut down cleanly. Swsup?)
A single 100baseT card for four users isn't going to be much of a bottleneck (you can stream 70 simultaneous ~DVD quality mpeg4 video streams through ONE of those cards), and you could save a lot of trouble on wiring too...
Sticking four users on a shared box at the intersection of four cubicles seems quite doable to me. (Or one box per four four students in a university computer lab environment.) If you're administering workstations for 100 people, it might not actually cut the workload by 1/4, but it still sounds like a heck of an improvement.
Still needs rmap to enforce even remotely fair per-user swap behavior, though... :)
Rob
Quoted 7 lines · H. Peter Anvin
Quoted 6 lines · Alan Cox
Quoted 5 lines
This is fundamentally the problem with these kinds of schemes -- they get outcompeted on price and availability by the massmarket items. This is part of the very attraction of Linux -- it's running Unix on stock, cheap, hardware.
Quoted 6 lines
Quoted 3 lines
The hardware is now massmarket - otherwise I'd agree wholeheartedly. Video cards are cheap, USB2.0 cards have 4 root bridges per card.
Oh yes, but the *expensive* part of the machine -- the multiprocessor box -- isn't.
Why bother with multiple CPUs? A single processor Athalon can handle several web kiosk users.
Quoted 5 lines
Also, when using massmarket systems of more than 2 or 3 monitors you start having cabling problems. VGA connectors aren't impedance matched and cause nasty reflections at high resolutions, so they don't extend well. I guess digital video is coming, but is not yet mass market.
Actually, there is some impedance matching. I've seen monitors with hi/lo impedance switches. And I've used 15 m long high-quality VGA cables. The result has been pretty good.
Regards, Richard.... Permanent: [email protected] Current: [email protected]
Quoted 5 lines · Richard Gooch
Actually, there is some impedance matching. I've seen monitors with hi/lo impedance switches. And I've used 15 m long high-quality VGA cables. The result has been pretty good.
The best I've seen is to use Sun D-sub coax or plain coax inputs on the monitors that have them. Those are impedance matched and can be extended without problem.
-hpa
Quoted 10 lines · H. Peter Anvin
Quoted 5 lines · Richard Gooch
Actually, there is some impedance matching. I've seen monitors with hi/lo impedance switches. And I've used 15 m long high-quality VGA cables. The result has been pretty good.
The best I've seen is to use Sun D-sub coax or plain coax inputs on the monitors that have them. Those are impedance matched and can be extended without problem.
Sure, coax inputs are the best. But there are still problems. Even expensive coax has higher attenuation at higher frequencies, so the longer the cable, the more fuzziness you get. Also, there are differential delay effects between the R, G and B components. You don't want the pixel components to arrive at different times. So there's a length limitation there as well.
But even though coax is better, VGA isn't that bad. 15 m gets you quite a lot of terminals in a web kiosk (or undergrad computer lab).
BTW: I agree that X terminals suck. Even worse are SunRays. Ug!
Regards, Richard.... Permanent: [email protected] Current: [email protected]
Quoted 19 lines · On 2002.04.13 Richard Gooch wrote:
Quoted 10 lines · H. Peter Anvin
Quoted 5 lines · Richard Gooch
Actually, there is some impedance matching. I've seen monitors with hi/lo impedance switches. And I've used 15 m long high-quality VGA cables. The result has been pretty good.
The best I've seen is to use Sun D-sub coax or plain coax inputs on the monitors that have them. Those are impedance matched and can be extended without problem.
Sure, coax inputs are the best. But there are still problems. Even expensive coax has higher attenuation at higher frequencies, so the longer the cable, the more fuzziness you get. Also, there are differential delay effects between the R, G and B components. You don't want the pixel components to arrive at different times. So there's a length limitation there as well.
Quoted 5 lines
But even though coax is better, VGA isn't that bad. 15 m gets you quite a lot of terminals in a web kiosk (or undergrad computer lab).
BTW: I agree that X terminals suck. Even worse are SunRays. Ug!
We have built a 'pseudo-CAVE' for presentations, and have six vgas feeding sony projectors with cabling between 15 and 20m, running at 1024x768@32. Quality is ok.
The problem is finding good PCI vga cards, even finding any, good or bad. Now they are TNT-M64. I'm also aware that SiS has some, but nothing special. But, to use it as terminals, they could be ok.
And coax is not so good. Even with expensive cable, the bounces of the signal made me see double like drunk. Video did not worked right until we got _golden_ connectors and soldered with silver. Believe me you could even put more mony on the cables that on the box.
Physics is funny...
Signature · 4 lines
J.A. Magallon # Let the source be with you... mailto:[email protected] Mandrake Linux release 8.3 (Cooker) for i586 Linux werewolf 2.4.19-pre6-jam1 #1 SMP Sun Apr 7 00:50:05 CEST 2002 i686
Quoted 31 lines · J. A. Magallon
Quoted 19 lines · On 2002.04.13 Richard Gooch wrote:
Quoted 10 lines · H. Peter Anvin
Quoted 5 lines · Richard Gooch
Actually, there is some impedance matching. I've seen monitors with hi/lo impedance switches. And I've used 15 m long high-quality VGA cables. The result has been pretty good.
The best I've seen is to use Sun D-sub coax or plain coax inputs on the monitors that have them. Those are impedance matched and can be extended without problem.
Sure, coax inputs are the best. But there are still problems. Even expensive coax has higher attenuation at higher frequencies, so the longer the cable, the more fuzziness you get. Also, there are differential delay effects between the R, G and B components. You don't want the pixel components to arrive at different times. So there's a length limitation there as well.
Quoted 5 lines
But even though coax is better, VGA isn't that bad. 15 m gets you quite a lot of terminals in a web kiosk (or undergrad computer lab).
BTW: I agree that X terminals suck. Even worse are SunRays. Ug!
We have built a 'pseudo-CAVE' for presentations, and have six vgas feeding sony projectors with cabling between 15 and 20m, running at 1024x768@32. Quality is ok.
Quoted 8 lines
The problem is finding good PCI vga cards, even finding any, good or bad. Now they are TNT-M64. I'm also aware that SiS has some, but nothing special. But, to use it as terminals, they could be ok.
And coax is not so good. Even with expensive cable, the bounces of the signal made me see double like drunk. Video did not worked right until we got _golden_ connectors and soldered with silver. Believe me you could even put more mony on the cables that on the box.
Are you sure your monitors had properly matched terminators?
Regards, Richard.... Permanent: [email protected] Current: [email protected]
Re: ux as a minicomputer ?
In reply to Alan CoxQuoted 14 lines · H. Peter Anvin
Quoted 9 lines · Alan Cox
Quoted 5 lines
This is fundamentally the problem with these kinds of schemes -- they get outcompeted on price and availability by the massmarket items. This is part of the very attraction of Linux -- it's running Unix on stock, cheap, hardware.
The hardware is now massmarket - otherwise I'd agree wholeheartedly. Video cards are cheap, USB2.0 cards have 4 root bridges per card.
Oh yes, but the *expensive* part of the machine -- the multiprocessor box -- isn't.
Quoted 7 lines
Also, when using massmarket systems of more than 2 or 3 monitors you start having cabling problems. VGA connectors aren't impedance matched and cause nasty reflections at high resolutions, so they don't extend well. I guess digital video is coming, but is not yet mass market.
-hpa
A single 1000Mhz+ CPU is overkill for most desktop users.
Most medium to large workplaces are vast cubicle farms. Put one box at the intersection of 4 cubes...bingo 2meter VGA cables reach fine and you get 1/4th the maintenance, 1/4 the network drops, etc. This would even be advantagious for two desks side-by-side or back-to-back.
Signature · 5 lines
________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: [email protected] Remember Cernan and Schmitt
Quoted 9 lines · Helge Hafting
Quoted 4 lines
2) If you hack out the VT switching out of X, then still each X server will disable all PCI resources for other video cards, because it believes it owns the system. This will freeze all other active X servers.
Do X somehow _depend_ on disabling other cards or is this another thing that could be #ifdefed out? Assuming, of course that the resources don't overlap in any unhealthy way.
They do. Almost always, there is the legacy VGA i/o space, which is needed to initialize the secondary card(s) by BIOS ran in vm86 space.
After #ifdefing the disabling out, the Xservers crashed reproducibly.
Signature · 2 lines
Vojtech Pavlik SuSE Labs