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
--
_______________________________________
John Looney Chief Scientist
a n t e f a c t o t: +353 1 8586004
http://www.antefacto.com f: +353 1 8586014
* 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>
> 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 |_______/
On Thu, Apr 11, 2002 at 05:43:31PM +0100, Dr. David Alan Gilbert wrote:
> * 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>
>
> > 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.
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.
> (Fun should form in the efforts to figure out which mouse is associated
> with which keyboard and with which video output).
--
Vojtech Pavlik
SuSE Labs
* 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/event devices. 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 |_______/
On Thu, 2002-04-11 at 12:49, Vojtech Pavlik wrote:
> On Thu, Apr 11, 2002 at 05:43:31PM +0100, Dr. David Alan Gilbert wrote:
> > * 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>
> >
> > > 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.
>
> 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.
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.
> > (Fun should form in the efforts to figure out which mouse is associated
> > with which keyboard and with which video output).
>
On Thu, Apr 11, 2002 at 01:07:44PM -0400, Ed Sweetman wrote:
> On Thu, 2002-04-11 at 12:49, Vojtech Pavlik wrote:
> > On Thu, Apr 11, 2002 at 05:43:31PM +0100, Dr. David Alan Gilbert wrote:
> > > * 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>
> > >
> > > > 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.
> >
> > 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.
> 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.
--
Vojtech Pavlik
SuSE Labs
On Thu, Apr 11, 2002 at 06:09:10PM +0100, Dr. David Alan Gilbert 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/event devices. But that's still far from
> > the desired state of things.
> >
>
> Oh how annoying - where do they get knotted up?
See my other mail.
> 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?
--
Vojtech Pavlik
SuSE Labs
On Thu, Apr 11, 2002 at 07:13:39PM +0200, Vojtech Pavlik mentioned:
> > 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
--
_______________________________________
John Looney Chief Scientist
a n t e f a c t o t: +353 1 8586004
http://www.antefacto.com f: +353 1 8586014
> > > 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 ?
Enable Hotplug :-) The input layer supports it!!
On: Thu, 11 Apr 2002 17:49:42 +0000,
"John P. Looney" <[email protected]> wrote:
> On Thu, Apr 11, 2002 at 07:13:39PM +0200, Vojtech Pavlik mentioned:
> > > 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 ...
> 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?
--
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.
> > > 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.c
aty128fb.c
radeonfb.c
By porting to the new fbdev api the fg_console can be removed.
The following keyboard drivers use fg_console.
sunkbd.c
streamable.c
mac_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.
On Thu, Apr 11, 2002 at 07:59:21PM +0200, Rene Rebe wrote:
> On: Thu, 11 Apr 2002 17:49:42 +0000,
> "John P. Looney" <[email protected]> wrote:
> > On Thu, Apr 11, 2002 at 07:13:39PM +0200, Vojtech Pavlik mentioned:
> > > > 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 ...
Yes and no. You shouldn't need VTs to run Xservers at all.
--
Vojtech Pavlik
SuSE Labs
On Thu, Apr 11, 2002 at 05:49:42PM +0000, John P. Looney wrote:
> On Thu, Apr 11, 2002 at 07:13:39PM +0200, Vojtech Pavlik mentioned:
> > > 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 ?
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.
--
Vojtech Pavlik
SuSE Labs
Followup to: <[email protected]>
By author: "John P. Looney" <[email protected]>
In newsgroup: linux.dev.kernel
>
> 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
--
<[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]>
> > 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.
James Simmons wrote:
> > "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
Vojtech Pavlik wrote:
> > 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
On Fri, Apr 12, 2002 at 09:43:46AM +0200, Helge Hafting wrote:
> > 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.
--
Vojtech Pavlik
SuSE Labs
On Fri, Apr 12, 2002 at 09:41:26AM +0200, Helge Hafting wrote:
> Vojtech Pavlik wrote:
>
> > > 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.
--
Vojtech Pavlik
SuSE Labs
> > 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.
>
> 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
> "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
> 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.
Alan Cox wrote:
>
>>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
> 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.
> 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
Alan Cox wrote:
>>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.
>
>>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
H. Peter Anvin writes:
> Alan Cox wrote:
> >
> >>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.
Why bother with multiple CPUs? A single processor Athalon can handle
several web kiosk users.
> 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]
Richard Gooch wrote:
>
> 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
H. Peter Anvin writes:
> Richard Gooch wrote:
> >
> > 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]
On 2002.04.13 Richard Gooch wrote:
>H. Peter Anvin writes:
>> Richard Gooch wrote:
>> >
>> > 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!
>
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...
--
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
J. A. Magallon writes:
>
> On 2002.04.13 Richard Gooch wrote:
> >H. Peter Anvin writes:
> >> Richard Gooch wrote:
> >> >
> >> > 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!
> >
>
> 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.
Are you sure your monitors had properly matched terminators?
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
On Sat, Apr 13, 2002 at 12:29:23PM -0700, H. Peter Anvin wrote:
> Alan Cox wrote:
> >
> >>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
>
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.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt
On Sat, 13 Apr 2002, Alan Cox wrote:
> > 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.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
> 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 ?
On Sun, 14 Apr 2002, Alan Cox wrote:
> > 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.
--
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 |_______/
Followup to: <20020414165056.GJ16692@gallifrey>
By author: "Dr. David Alan Gilbert" <[email protected]>
In newsgroup: linux.dev.kernel
>
> 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
--
<[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]>
On Sunday 14 April 2002 09:45 am, Alan Cox wrote:
> > 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
Rob Landley wrote:
> 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
> (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.
On Sun, 14 Apr 2002, Dr. David Alan Gilbert wrote:
> 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.
On Monday 15 April 2002 06:20 pm, Stephen Samuel wrote:
>
> 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