Re:OpenPIC = standard kneejerk response (sorry)
on
Quake3 to go SMP
·
· Score: 1
AFAIK:
Intel implements the PIC on P6's on the CPU core. Previously on socket7 the interrupt controller was integrated into the chipset. (and before PIC's got integrated they were a seperate chip).
OpenPIC specifies an external PIC, so as long as a CPU can work with an external PIC, then that CPU is SMP capable with openpic.
So if the K6 works now with the PIC in your Via/intel/ALi chipset, there's no reason it shouldn't work with an OpenPIC compliant PIC. The K6 doesn't need to care much that the PIC is also interrupting a second/third/fourth CPU.
the K6-III would make a great SMP chip i think. The problem with Socket7 SMP was always the shared L2 cache. But with k6-III you have an even better cache structure than P6 SMP, ie fast, chip specific L2 cache, plus a large global cache - P6 SMP lacks a global L3 cache.
just a shame no super7 chipset maker wants to build OpenPIc into their chipset.
There are Intel HX socket 7 boards that can do SMP with intel chips.
As for Super7, according to Via's website, the(M)VP3 supports SMP - presumably Intel's MP standard, but no board maker has ever implemented it.
The K6 supports SMP aswell, or rather it is OpenPIC compliant. But there are no socket7 boards that implement it. OpenPIC is cross platform however, and is used on PowerPC SMP boards. Also, Digital Equipment was another developer of OpenPIC, so it's possible that they implemented it somewhere as well.
(what kind of PIC standard does the Alpha 21164 adhere to - anyone know?)
Actually I believe most Alpha's run either DEC/Tru64 Unix or linux.
Certainly the vast majority of Alpha machines that DEC/CPQ sell are sold with DEC/Tru64 licences. The figure I heard (from a very reliable source) was 85%. And that's just refering to workstations. I imagine the percentage for servers is even more heavily biased to Unix.
the reasoning is simple: the de facto graphics standard is X. the unix console only does text. As long as the kernel can recover the framebuffer everybody's happy.
why put code into the kernel to make the console graphics capable when the unix-portable graphical layer is X?
eg the DEC 21143 network is used on Base2, BaseT and BaseFx cards. same chip, different transceivers. The 21143 takes care of most the ethernet framing side of things, and the transceiver takes care of communicating the bits across the media - be it fibre, copper..
so i guess this transceiver is pretty much tied to BaseT.
(although it's not very clear from the article whether the chip is just a receiver or capable of higher level ethernet 802 stuff).
no, the idea behind UNIX is to keep things simple.
There is nothing wrong with allowing a trusted programme access to hardware, with the caveat that you can recover from any mistakes it might make - achievable with linux-framebuffer and a supported card.
Also, if people start to write app's to things like GGI then we end up with linux-specific programmes. not nice.
cause with unix you leave as much as possible in user space. and up to now it's worked fine, where we ran a trusted server process which could access the graphics card.
in future there might need to be a minimal bit of kernel support to get 3d graphics working, ie to support interrupts and copying textures across AGP to the video card.
GGI as an API is dead. it's too linux-x86 centric. OpenGL/X is portable.
firewire is what: 200 or 400Mb/s, scsi is currently at 80MB/s with LVD.
scsi has a sizeable lead.
Re:255 SCSI devices on a chain using LUNs?
on
Firewire Harddrives
·
· Score: 1
Has it been mentioned that SCSI "dumbs down" to the slowest device on the chain?
total arse-wash.
if you have a fast and a fast-20 (ultra) device on a bus with a fast-20 capable controller, then data transfer will be at fast for the fast device, and fast-20 for the fast-20 device.
The only problem is with LVD (ultra-2) it's is not *electrically* compatible with the older scsi revisions. And so *has* to revert to standard scsi signalling if there is a standard scsi device on the bus.
depends where you are. I'm in Ireland and just a bought a Samsung 533MHz 21164a @ GBP £149 and a Samsung UX board @ GBP £452 from Compusys in the UK. I got a midi case, motherboard, cpu and 128mb of memory for a total of about GBP £890 ex VAT. which is pretty good. ($/£ = roughly 1.5).
Have a look on www.alphalinux.org, there's links to vendors like dginc, who can probably put a nice system together for about $1500.
KDE and gnome switched to a common ORB architecture?
just imagine how cool linux would be if it had two competing "cool" desktop enviroments - but apps from one could still seamlessly integrate into the other enviroment.
eg gnome-panel apps could plug into kpanel and vice versa...
if only.
- paul: who uses gnome, kde and openlook apps all under windowmaker.:)
you can get 533MHz 21164a's for dirt cheap from samsung dealers. (eg ~$200).
You can get a motherboard with onboard uw scsi, ethernet and 2MB L3 cache for the price of a high-end P11 board.
That's 533MHz, 8+8KB L1 cache@cpu clock, 96KB L2 @cpu clock and 2MB L3 @66mhz - and beats the pants off *any* intel chip at floating point. All at the same price, maybe less, than the latest intel stuff.
better still - it'll clock to 600, maybe even 667. anybody considering doing 3d rendering should get an alpha rather than intel.
AFAIK even intel doesn't have a test implemenation, so i doubt any amd/via K7 chipset would.
i think you should go back and read the article!
i meant that it says both 133 and 200mhz as the fsb for the K7 system. which is not quite right: 200mhz ev6 bus is plausible. 133mhz SDRAM is plausible - but it says RDRAM@600Mhz!!
would an acer engineer make those kind of mistakes? sounds like a kiddy who pulled jargon of various sites.
Alpha's are gonna be cheaper than K-63's by mid-summer.
they already are!!
I just a bought a Samsung 21164A 533MHz for £149 from a Samsung dealer. The cheapest i can get a K6-3 for is about £250!!.. 600MHz Alpha's are about £480, comparable to a P11 500 or a P111.
The 533MHz way outperforms the K6, and a relatively recent 533MHz will clock to 600 no problem.
That's nice, and the makers of "The Matrix" should have waited for the new compilers or written them themselves?
even though ecgs isn't as optimised as DU cc, Alpha binaries it creates will still be 1.5x+ faster than a same generation P11.
"The Matrix" is already a reality, in business you just can't wait.
and when was the alpha cluster used for titanic a reality? when was the avalon cluster a reality?
Perhaps the performance gain isn't "measly" but it just can NOT compete price/preformance ratio
rubbish. you can buy 533MHz Alpha's for the price of a P11 300MHz. You can buy 600MHz alpha's for less than the price of a P111-500. Both of them kick Pentium11's into park when it comes to floating point. a 533MHz alpha has nearly double the floating point power of a p11-450.
Sure alpha is faster and really cool, but when people are concerned about price and performance.
An Alpha 533MHz and motherboard with onboard network and scsi costs approx £600. (~$900) which is comparable to the cost of a p111 500 and motherboard. plus most 533mhz alphas will clock to at least 600mhz reliably (i'm told).
the only excuse for going with a high-end p11 setup instead of alpha is ignorance.
you can't beat cheap intel hardware for clustering, get over it.
you clearly havn't checked out prices. go to the alphalinux site and follow the links to the vendors, and ask them for quotes. I think you'll be surprised.
vms is actually pretty good. granted it's a bit strange if you're used to unix, but people who actually use VMS say it's more user-friendly than unix, and are very fond of it.
the nicest thing about it is the way it *never* crashes. spoke to an eng at a vms site, and he hasn't seen a crash in the 3 years he's been there .
been using it for a good while now. it works well, it's backwards compatible. i like the way ls/dev now shows me only the devices for which drivers are loaded. i like the way i don't have to remember which scsi device/dev/sdb is, especially when i've hot added/removed something.
just wish it could be rolled into 2.2... would make things a lot easier.
Slashdot Mirror
AFAIK:
Intel implements the PIC on P6's on the CPU core. Previously on socket7 the interrupt controller was integrated into the chipset. (and before PIC's got integrated they were a seperate chip).
OpenPIC specifies an external PIC, so as long as a CPU can work with an external PIC, then that CPU is SMP capable with openpic.
So if the K6 works now with the PIC in your Via/intel/ALi chipset, there's no reason it shouldn't work with an OpenPIC compliant PIC. The K6 doesn't need to care much that the PIC is also interrupting a second/third/fourth CPU.
the K6-III would make a great SMP chip i think. The problem with Socket7 SMP was always the shared L2 cache. But with k6-III you have an even better cache structure than P6 SMP, ie fast, chip specific L2 cache, plus a large global cache - P6 SMP lacks a global L3 cache.
just a shame no super7 chipset maker wants to build OpenPIc into their chipset.
ah well...
There are Intel HX socket 7 boards that can do SMP with intel chips.
As for Super7, according to Via's website, the(M)VP3 supports SMP - presumably Intel's MP standard, but no board maker has ever implemented it.
The K6 supports SMP aswell, or rather it is OpenPIC compliant. But there are no socket7 boards that implement it. OpenPIC is cross platform however, and is used on PowerPC SMP boards. Also, Digital Equipment was another developer of OpenPIC, so it's possible that they implemented it somewhere as well.
(what kind of PIC standard does the Alpha 21164 adhere to - anyone know?)
Actually I believe most Alpha's run either DEC/Tru64 Unix or linux.
Certainly the vast majority of Alpha machines that DEC/CPQ sell are sold with DEC/Tru64 licences. The figure I heard (from a very reliable source) was 85%. And that's just refering to workstations. I imagine the percentage for servers is even more heavily biased to Unix.
the reasoning is simple: the de facto graphics standard is X. the unix console only does text. As long as the kernel can recover the framebuffer everybody's happy.
why put code into the kernel to make the console graphics capable when the unix-portable graphical layer is X?
it works, it's portable - why change it?
not really. the transceiver is media specific.
eg the DEC 21143 network is used on Base2, BaseT and BaseFx cards. same chip, different transceivers. The 21143 takes care of most the ethernet framing side of things, and the transceiver takes care of communicating the bits across the media - be it fibre, copper..
so i guess this transceiver is pretty much tied to BaseT.
(although it's not very clear from the article whether the chip is just a receiver or capable of higher level ethernet 802 stuff).
no, the idea behind UNIX is to keep things simple.
There is nothing wrong with allowing a trusted programme access to hardware, with the caveat that you can recover from any mistakes it might make - achievable with linux-framebuffer and a supported card.
Also, if people start to write app's to things like GGI then we end up with linux-specific programmes. not nice.
cause with unix you leave as much as possible in user space. and up to now it's worked fine, where we ran a trusted server process which could access the graphics card.
in future there might need to be a minimal bit of kernel support to get 3d graphics working, ie to support interrupts and copying textures across AGP to the video card.
GGI as an API is dead. it's too linux-x86 centric. OpenGL/X is portable.
and how is firewire than scsi??
firewire is what: 200 or 400Mb/s, scsi is currently at 80MB/s with LVD.
scsi has a sizeable lead.
Has it been mentioned that SCSI "dumbs down" to the slowest device on the chain?
total arse-wash.
if you have a fast and a fast-20 (ultra) device on a bus with a fast-20 capable controller, then data transfer will be at fast for the fast device, and fast-20 for the fast-20 device.
The only problem is with LVD (ultra-2) it's is not *electrically* compatible with the older scsi revisions. And so *has* to revert to standard scsi signalling if there is a standard scsi device on the bus.
Don't post bullshit.
SCSI needs unique IDs for every device on the chain. Firewire negotiates.
Ever heard of SCAM?
I've got 3 uw IBM's and according to the jumpers they're all on 0. But with SCAM you can set the ID for each drive in the bios... cool..
depends where you are. I'm in Ireland and just a bought a Samsung 533MHz 21164a @ GBP £149 and a Samsung UX board @ GBP £452 from Compusys in the UK. I got a midi case, motherboard, cpu and 128mb of memory for a total of about GBP £890 ex VAT. which is pretty good. ($/£ = roughly 1.5).
Have a look on www.alphalinux.org, there's links to vendors like dginc, who can probably put a nice system together for about $1500.
KDE and gnome switched to a common ORB architecture?
:)
just imagine how cool linux would be if it had two competing "cool" desktop enviroments - but apps from one could still seamlessly integrate into the other enviroment.
eg gnome-panel apps could plug into kpanel and vice versa...
if only.
- paul: who uses gnome, kde and openlook apps all under windowmaker.
you can get 533MHz 21164a's for dirt cheap from samsung dealers. (eg ~$200).
You can get a motherboard with onboard uw scsi, ethernet and 2MB L3 cache for the price of a high-end P11 board.
That's 533MHz, 8+8KB L1 cache@cpu clock, 96KB L2 @cpu clock and 2MB L3 @66mhz - and beats the pants off *any* intel chip at floating point. All at the same price, maybe less, than the latest intel stuff.
better still - it'll clock to 600, maybe even 667.
anybody considering doing 3d rendering should get an alpha rather than intel.
AFAIK even intel doesn't have a test implemenation, so i doubt any amd/via K7 chipset would.
i think you should go back and read the article!
i meant that it says both 133 and 200mhz as the fsb for the K7 system. which is not quite right: 200mhz ev6 bus is plausible. 133mhz SDRAM is plausible - but it says RDRAM@600Mhz!!
would an acer engineer make those kind of mistakes? sounds like a kiddy who pulled jargon of various sites.
This has already been discredited.
Look at it: it talks about USB2.0 (not ratified).
600MHz rdram doesn't exist.
one minute it says 133mhz fsb, next it says 200mhz.
it's a fake.
Alpha's are gonna be cheaper than K-63's by mid-summer.
they already are!!
I just a bought a Samsung 21164A 533MHz for £149 from a Samsung dealer. The cheapest i can get a K6-3 for is about £250!!.. 600MHz Alpha's are about £480, comparable to a P11 500 or a P111.
The 533MHz way outperforms the K6, and a relatively recent 533MHz will clock to 600 no problem.
Alpha - you'd be nuts to get anything else!
(PS: $/£ = ~1.5/1)
both login and telnet can insert the kernel version automatically. (as well as time/date, nr. of users, etc..)
read the issue, login and telnetd man pages.
there's a pic of the developers at work on the page. a little thumbnail that's linked. i thought it'd link to a blow-up.. but it doesn't... :(
i was hoping to see the linux development enviroment that they're supposed to be using, some other time i gues..
That's nice, and the makers of "The Matrix" should have waited for the new compilers or written them themselves?
even though ecgs isn't as optimised as DU cc, Alpha binaries it creates will still be 1.5x+ faster than a same generation P11.
"The Matrix" is already a reality, in business you just can't wait.
and when was the alpha cluster used for titanic a reality? when was the avalon cluster a reality?
Perhaps the performance gain isn't "measly" but it just can NOT compete price/preformance ratio
rubbish. you can buy 533MHz Alpha's for the price of a P11 300MHz. You can buy 600MHz alpha's
for less than the price of a P111-500. Both of them kick Pentium11's into park when it comes to floating point. a 533MHz alpha has nearly double the floating point power of a p11-450.
Sure alpha is faster and really cool, but when people are concerned about price and performance.
An Alpha 533MHz and motherboard with onboard network and scsi costs approx £600. (~$900) which is comparable to the cost of a p111 500 and motherboard. plus most 533mhz alphas will clock to at least 600mhz reliably (i'm told).
the only excuse for going with a high-end p11 setup instead of alpha is ignorance.
you can't beat cheap intel hardware for clustering, get over it.
you clearly havn't checked out prices. go to the alphalinux site and follow the links to the vendors, and ask them for quotes. I think you'll be surprised.
nah, IRIX is BSD flavoured...
i've seen that one....
:)
and they had the cheek to phone up and ask us to fix the printer under guarantee!!!
the mess a transparency makes when it goes through a printer fuser is pretty cool..
vms is actually pretty good. granted it's a bit strange if you're used to unix, but people who actually use VMS say it's more user-friendly than unix, and are very fond of it.
the nicest thing about it is the way it *never* crashes. spoke to an eng at a vms site, and he hasn't seen a crash in the 3 years he's been there .
tesla cox??
i'd love to see the raid patches integrated into the lvm patches.
plus i wish T'So would GPL his resize2fs programme.
swapping/adding disks and repartitioning would then be incredibly painless.
concur. devfs is excellent.
/dev now shows me only the devices for which drivers are loaded. i like the way i don't have to remember which scsi device /dev/sdb is, especially when i've hot added/removed something.
been using it for a good while now. it works well, it's backwards compatible. i like the way ls
just wish it could be rolled into 2.2... would make things a lot easier.