The collected works of ramq - Page 2

I'd definitly can't call the O300 "cheap" (when we're talking about PeeCees) and AFAIK I've seen such things in other ("expensive") manufacturers too. When I opened up the O300 I got the same impression as hamei and I agree with you.
:O3200: :Fuel: :Indy: :O3x02L:
Done!

Do we have a funding option for Nekoware drones?

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
4 Giggers in each slot, times 8 slots equals a whole lot of RAM!
:O3200: :Fuel: :Indy: :O3x02L:
All of this f**** iPod Touch, I am now addicted to apples.
Yes, I'm a newbie when it comes to Macs in general, but all this glass+aluminum goodness simply does it for me.

So... I'm aiming for the newest iMac and particularly the 27" model. (I love large desktops)
But, there's an option between the better and "best" gfxcards and ofcourse there's the dual-core "Core2 Duo" processor versus the quad-core "Core i5" processor.
For whatever reason I find it nearly too expensive to go for the i5-model, but upgrading the dual-core model with the better ATI-card leaves only a small money gap for going all-in to the i5.

Thoughts? Comments?
:O3200: :Fuel: :Indy: :O3x02L:
Yes, I'm aware of the rescent "issues" regarding the 27" and so far it seems that Apples official statement is the gfx-cards to blame for all the flickering. The cracked screens is another issue not related to the ATI boards, of course. ;)
:O3200: :Fuel: :Indy: :O3x02L:
Hi, and welcome to the club.
I see you haven't typed in your location yet, so we can't say for sure if there's forum friends close to you or in the same country.
:O3200: :Fuel: :Indy: :O3x02L:
Uppsala? Well, välkommen till SGI-klubben. ;)
:O3200: :Fuel: :Indy: :O3x02L:
There's more - Tesla, deBug, bjornl, Pontus and sgtprobe too. I've probably missed someone.
Pontus, btw, is also from Uppsala.
:O3200: :Fuel: :Indy: :O3x02L:
I've replaced all but the PCI-fan (didn't make much noise) and the Power Supply fan - which sounds like a jet taking off after just a few minutes of runtime.

What fan did you replace the PSU fan with? Model? Manufacturer?
(Did you have to circumvent enviromental monitoring or did it work anyway?)
:O3200: :Fuel: :Indy: :O3x02L:
Wow, two racks? Impressive.
Anyone got any specs whatsoever out of these old workhorses?
:O3200: :Fuel: :Indy: :O3x02L:
Well, count me in for one, that's for sure!

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
As defined as two seperate systems, you'd need another MMSC to make a complete third machine. However, I'm not sure you need one if you only have one compute module in one chassis.
:O3200: :Fuel: :Indy: :O3x02L:
Well, you have to make absolute sure that you've set the "console=g" variable in SRM through serial console until you can find anything on the screen.

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
You know, I was thinking of that right this very evening and thought I should pop in and pop the question.
Good thing you found it already and bad thing I didn't thought of that in the first place.

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
The ES40 emulator is quite funky, and it really works too.
I'd love an IRIX-port thought... =)

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
I've contributed some power figures on the Origin350 and NUMAlink module already:

http://www.nekochan.net/wiki/Origin_350
http://www.nekochan.net/wiki/NUMAlink_router
:O3200: :Fuel: :Indy: :O3x02L:
Sorry for waking an old thread, but I kind of miss the Prism in this series?

_________________
:O3000: :Fuel: :Indy: :O3x0: :O3x02L:
Last weekend I recieved a new little gem which I bought for my collection - a Prism deskside workstation. It's in a very nice condition and the only thing that seems to show its age is the L1 controller display which has a few shaded characters on it. Otherwise than that it's in 100% working condition.
I know, I know. These are not MIPS, but atleast it's SGI and have an interesting design approach to the system itself. It's basicly an Altix but with graphics, much like the difference between the Origin and Onyx line of MIPS hardware. As some might know the ATI-cards in this beast lacks proper (bugfree) drivers, so I guess the system was a downer for some users back in the days.

Attachment:
File comment: SGI Prism
IMG_6912.JPG
IMG_6912.JPG [ 3.79 MiB | Viewed 306 times ]


It's currently fitted with two Qlogic 2200F/66 FC HBA:s, a standard SGI GbE adapter and two ATI FireGL X3 graphics cards. It came with a slimline DVD-drive and two 160GB SATA-drives, which uses the very same "Intel-sleds" that the Origin350 uses. It's currently loaded with SGI's own Linux called "SGI Advanced Linux Environment", version 3 SP6. It looks to be RedHat-derived so anyone familiar with RedHat or CentOS would feel comfortable running it.

The power consumption was a little bit surprising, consider the small system dimensions and it's not all that noisy, even though I could count 10 fans in there. (Or was it 12?)

20W with only L1 running (standby)
380W idle at boot prompt (on)
410W with both CPUs pegged (on)

Since it's that power hungry, it won't be running 24/7 and will probably only serve as a fun project than anything else. It's rather speedy and feels "modern" by any means, apart from SGI's ancient operating system. My next mission will be to rip out the FC-cards and the extra GbE card to serve a better use in my MIPS hardware.

Since Linux lacks a proper "hinv" I'll just post a 'dmesg' and a simple 'cat /proc/cpuinfo':

Code:
Linux version 2.4.21-sgi306r6 ([email protected]) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-24)) #1 SMP Sat Jun 18 14:43:35 PDT 2005
EFI v1.10 by INTEL: SALsystab=0x3002a08d90 ACPI 2.0=0x3002a09580 HCDP=0x35efea1110
CPU 0: mapping PAL code [0x1000000-0x2000000) into [0xe000000001000000-0xe000000002000000)
ACPI: RSDP (v002    SGI                     ) @ 0x0000003002a09580
ACPI: XSDT (v001    SGI  XSDTSN2 00001.00001) @ 0x0000003002a0bb20
ACPI: MADT (v001    SGI  APICSN2 00001.00001) @ 0x0000003002a09620
ACPI: SRAT (v001    SGI  SRATSN2 00001.00001) @ 0x0000003002a09680
ACPI: SLIT (v001    SGI  SLITSN2 00001.00001) @ 0x0000003002a09710
ACPI: FADT (v003    SGI  FACPSN2 00003.00001) @ 0x0000003002a097a0
SRAT revision 0
SLIT localities 1x1
Number of logical nodes in system = 1
Number of memory chunks in system = 1
SAL v3.02: oem=SGI, product=SN2
SAL: entry: pal_proc=0x1fff800, sal_proc=0x1fffc00
SAL: Platform features ITC_Drift
SAL: AP wakeup using external interrupt vector 0x12
ACPI: Local APIC address 0xc0000000fee00000
ACPI: LSAPIC (acpi_id[0x00] lsapic_id[0x00] lsapic_eid[0x00] enabled)
ACPI: LSAPIC (acpi_id[0x01] lsapic_id[0x01] lsapic_eid[0x00] enabled)
ACPI: Error parsing MADT - no IOAPIC entries
register_intr: No IOSAPIC for GSI 0x34
GSI 0x34(low,level) -> CPU 0x0000 vector 48
2 CPUs available, 2 CPUs total
SGI SAL version 5.03
SGI: Replaced alt_dtlb_miss handler.
CPU 0: sapicid 0, nasid 0, subnode 0, slice 0, cnode 0
Increasing MCA rendezvous timeout from 20000 to 49000 milliseconds
MCA related initialization done
Virtual mem_map starts at 0xa0007fffaf180000
Kernel command line: BOOT_IMAGE=dev000:EFI\sgi\vmlinuz-2.4.21-sgi306r6 root=/dev/hda3 ro
FPSWA interface at 0x35efe70010, revision 1.18
CPU 0: base freq=200.000MHz, ITC ratio=16/2, ITC freq=1600.000MHz
Console: colour VGA+ 80x25
Calibrating delay loop... 2392.40 BogoMIPS
Memory: 16045776k/16152480k available (7462k code, 106704k reserved, 5613k data, 1296k init)
kdb version 4.3 by Keith Owens, Scott Lurndal. Copyright SGI, All Rights Reserved
Dentry cache hash table entries: 1048576 (order: 10, 16777216 bytes)
Inode cache hash table entries: 1048576 (order: 10, 16777216 bytes)
Mount cache hash table entries: 1024 (order: 0, 16384 bytes)
Buffer-cache hash table entries: 1048576 (order: 9, 8388608 bytes)
Page-cache hash table entries: 1048576 (order: 10, 16777216 bytes)
SNARE Audit capability is initialising
POSIX conformance testing by UNIFIX
Boot processor id 0x0/0x0
SMP: starting up secondaries.
CPU 1: mapping PAL code [0x1000000-0x2000000) into [0xe000000001000000-0xe000000002000000)
CPU 1: sapicid 100, nasid 0, subnode 0, slice 2, cnode 0
CPU 1: base freq=200.000MHz, ITC ratio=16/2, ITC freq=1600.000MHz
Calibrating delay loop... 2144.32 BogoMIPS
CPU1: CPU has booted.
Before bogomips.
Total of 2 processors activated (4536.72 BogoMIPS).
Starting migration thread for cpu 0
smp_num_cpus: 2.
Starting migration thread for cpu 1
ACPI: Subsystem revision 20020517
PCI: Using SAL to access configuration space
ACPI-0108: *** Error: Acpi_load_tables: Could not load namespace: AE_BAD_PARAMETER
ACPI-0117: *** Error: Acpi_load_tables: Could not load tables: AE_BAD_PARAMETER
ACPI: Unable to load the System Description Tables
tioca_pci_init:  SN_SAL_PIOW_ADDR_REGION range 0xc000004023000000 - 0xc000004023000fff
tioca_pci_init:  SN_SAL_PIOW_ADDR_REGION range 0xc00000c023000000 - 0xc00000c023000fff
/proc/sgi_sn/hwperf: using 0K for heap.
PCI: Probing PCI hardware
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
perfmon: version 1.100 IRQ 238
perfmon: 16 PMCs, 18 PMDs, 4 counters (47 bits)
PAL Information Facility v0.5
EFI Variables Facility v0.06 2002-Dec-10
Total HugeTLB memory allocated 0 pages, pagesize 262144kB
PCI: Found IRQ 56 for device 01:01.0
Registering PAGG support for (name=job)
Starting kswapd
Starting oom_killer
aio_setup: num_physpages = 252382
aio_setup: sizeof(struct page) = 96
Hugetlbfs mounted.
devfs: v1.12c (20020818) Richard Gooch ([email protected])
devfs: boot_options: 0x1
Installing knfsd (copyright (C) 1996 [email protected]).
SGI XFS 1.3.5 with ACLs, realtime, large block/inode numbers, dmapi support, no debug enabled
SGI XFS Quota Management subsystem
pty: 2048 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ DETECT_IRQ SERIAL_PCI enabled
sn_serial: sn_sal_module_init
SGI SN IOC4 Serial driver version:1.2 revision:2005-03-18
SGI SN IOC4 Serial driver : number of active ports 4
IOC4 serial driver port 0 irq = 56
IOC4 serial driver port 1 irq = 56
IOC4 serial driver port 2 irq = 56
IOC4 serial driver port 3 irq = 56
SGI SN IOC3 Serial driver version:1.2
SGI SN IOC3 Serial driver : number of active ports 0
SGI Fetchop Device Driver: v1.04
SGI Cached Device Driver: v1.04
SGI Uncached Device Driver: v1.04
IA-PC Multimedia Timer: v1.0, 20 MHz
EFI Time Services Driver v0.4
RAMDISK driver initialized: 256 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
tg3.c:v2.2 (August 24, 2003)
PCI: Found IRQ 58 for device 01:04.0
eth0: Tigon3 [partno(030-1771-000) rev 0105 PHY(5701)] (PCI device:01:04.0:66MHz:64-bit) 10/100/1000BaseT Ethernet 08:00:69:14:02:c4
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 15403M
sgi_tioca_gart_init ...
ca_soft = 0xe0000035edc48700
ca_soft = 0xe0000035edc48500
agpgart: AGP aperture(s) are 1024M @ 0x80000000
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PCI: Found IRQ 57 for device 01:03.0
Vitesse VSC7174: Serial ATA controller in DPA mode at PCI slot 01:03.0
vsc7174_ide_setup_pci_device(Vitesse VSC7174): SATA Device absent for Channel 1
ide0: BM-DMA at 0xc00000c010304464-0xc00000c0103044ff
ide_dma_vsc7174 : ide0 : dmatable_cpu 0xe0000035eca48000 | dma 0x40010000
vsc7174_ide_setup_pci_device(Vitesse VSC7174): SATA Device absent for Channel 3
vsc7174_ide_setup_pci_device(Vitesse VSC7174): SATA Device absent for Channel 4
hda: WDC WD1600ADFD-75NLR1, ATA DISK drive
ide1: ports already in use, skipping probe
ide2: ports already in use, skipping probe
ide3: ports already in use, skipping probe
ide4: ports already in use, skipping probe
ide5: ports already in use, skipping probe
global_restore_flags: 10084a6010 (e000000004d930a0)
ide0 at 0xc00000c010304400-0xc00000c010304407,0xc00000c010304428 on irq 57
hda: attached ide-disk driver.
hda: host protected area => 1
hda: setmax_ext LBA 176330412941088, native  312500000
hda: 312500000 sectors (160000 MB) w/16384KiB Cache, CHS=19452/255/63, SATA DMA
Partition check:
/dev/ide/host0/bus2/target0/lun0: p1 p2 p3
PCI: Found IRQ 56 for device 01:01.0
xscsi/ide:SGI IOC4 BaseIO Card Detected : Firmware Rev 83
/dev/sra: DVD-ROM drive, Speed 4224 kBps, 256kB Cache
Uniform CD-ROM driver Revision: 3.12
pci_request_legacy_resource: 0 1000 -> c000004023000000
pci_request_legacy_resource: a0000 affff -> c0000040280a0000
pci_request_legacy_resource: 0 1000 -> c00000c023000000
pci_request_legacy_resource: a0000 affff -> c00000c0280a0000
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: raid1 personality registered as nr 3
md: raid5 personality registered as nr 4
raid5: measuring checksumming speed
8regs     :  3194.880 MB/sec
8regs_prefetch:  3014.656 MB/sec
32regs    :  4030.464 MB/sec
32regs_prefetch:  3670.016 MB/sec
ia64      :  3424.256 MB/sec
raid5: using function: 32regs (4030.464 MB/sec)
md: multipath personality registered as nr 7
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
LVM version 1.0.5+(22/07/2002)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Initializing Cryptographic API
NET4: Linux TCP/IP 1.0 for NET4.0
IP: routing cache hash table of 262144 buckets, 4096Kbytes
TCP: Hash tables configured (established 2097152 bind 65536)
Linux IP multicast router 0.06 plus PIM-SM
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
FAT: bogus cluster size 19
FAT: bogus cluster size 19
XFS mounting filesystem ide0(3,3)
Starting XFS recovery on filesystem: ide0(3,3) (dev: ide0(3,3))
Ending XFS recovery on filesystem: ide0(3,3) (dev: ide0(3,3))
VFS: Mounted root (xfs filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 1296kB freed
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
PCI: Found IRQ 59 for device d0:02.0
usb-ohci.c: USB OHCI at membase 0xc00000c010400000, IRQ 59
usb-ohci.c: usb-d0:02.0, NEC Corporation USB
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 3 ports detected
PCI: Found IRQ 60 for device d0:02.1
usb-ohci.c: USB OHCI at membase 0xc00000c010401000, IRQ 60
usb-ohci.c: usb-d0:02.1, NEC Corporation USB (#2)
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
usb.c: registered new driver hiddev
usb.c: registered new driver hid
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <[email protected]>
hid-core.c: USB HID support drivers
mice: PS/2 mouse device common for all mice
hub.c: new USB device d0:02.0-1, assigned address 2
input0: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb1:2.0
hub.c: new USB device d0:02.1-1, assigned address 2
input1: USB HID v1.10 Keyboard [NOVATEK USB Keyboard] on usb2:2.0
input2,hiddev0: USB HID v1.10 Pointer [NOVATEK USB Keyboard] on usb2:2.1
UST Manager: v1.0
Registering PAGG support for (name=numatools)
SGI Numatools: numatools v0.99
pci03.02.0: Firmware version: 2.2.6: TP.
pci03.02.0: Response in of 40964 is invalid, rereading.
pci03.02.0: Response in of 40964 is invalid, ignoring.
pci03.02.0: Response in of 40964 is invalid, rereading.
pci03.02.0: Response in of 40964 is invalid, ignoring.
pci03.02.0: Response in of 40964 is invalid, rereading.
pci03.02.0: Response in of 40964 is invalid, ignoring.
pci04.02.0: Firmware version: 2.2.6: TP.
pci04.02.0: Response in of 32788 is invalid, rereading.
pci04.02.0: Response in of 32788 is invalid, ignoring.
pci04.02.0: Response in of 32788 is invalid, rereading.
pci04.02.0: Response in of 32788 is invalid, ignoring.
pci04.02.0: Response in of 32788 is invalid, rereading.
pci04.02.0: Response in of 32788 is invalid, ignoring.
Adding Swap: 16779856k swap-space (priority -1)
SCSI subsystem driver Revision: 1.00
Registering PAGG support for (name=xpmem)
SGI XPMEM kernel module v1.5 loaded
ip_tables: (C) 2000-2002 Netfilter core team
ip_tables: (C) 2000-2002 Netfilter core team
Registering PAGG support for (name=arsess)
ip_tables: (C) 2000-2002 Netfilter core team
ip_tables: (C) 2000-2002 Netfilter core team
tg3: eth0: Link is up at 100 Mbps, full duplex.
tg3: eth0: Flow control is on for TX and on for RX.


Code:
processor  : 0
vendor     : GenuineIntel
arch       : IA-64
family     : Itanium 2
model      : 2
revision   : 1
archrev    : 0
features   : branchlong
cpu number : 0
cpu regs   : 4
cpu MHz    : 1600.000000
itc MHz    : 1600.000000
BogoMIPS   : 2390.75

processor  : 1
vendor     : GenuineIntel
arch       : IA-64
family     : Itanium 2
model      : 2
revision   : 1
archrev    : 0
features   : branchlong
cpu number : 0
cpu regs   : 4
cpu MHz    : 1600.000000
itc MHz    : 1600.000000
BogoMIPS   : 2143.28

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
Sybrfreq & bplaa.yai: Yes, that's correct in both senses. The kernel was compiled by someone inside SGI (It's SGI's official CDs!) and the machine came from a SGI office.
SGI Stockholm closed down their office about a month ago and this was just one cool bit that was rescued. (Have a full box with CDs and give-aways to sort through, plus some spare parts for Origin hardware) Very much thanks to Pontus for giving it a lift to my place. ;)

And yes Hamei , I've already made a point about it in another thread and you replied about it . :D

Recondas: As for the L1 story I have to fix my L2 emulator software on a laptop to make this happen. There's probably some cool things in there to see, so I'll get back once I've got something to report.

Indyman007: And it is cute, how cute a IA64 workstation can be anyway. I still need to find something cool to do with it other than booting it up and typing "finger" and "df -h" on it. It's fast as any modern box, but it's nowhere justified to run SETI@Home on it.

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
Ryan Fox wrote:
Y'know Installing Ubuntu Linux/Red hat on this should be cool. Heh but still a very very useful and capable workstation. I wonder if you can upgrade the CPUs on this thing using standard options available on the market?

Well, for one thing, IA64 CPUs are waaay different than any other PeeCee-ish items out there. I wouldn't even dare call it anything x86-relative and for those who know the battles of the Itanium-history, the different CPU options is rather limited. There's plenty to read here .
I believe it's Madison CPUs in this box.

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
recondas wrote:
Some photos of the interior would be nice too - I don't think I've ever seen any.

That would be a trivial issue. I'll see what I can dig up in the next couple of days.

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
Titox wrote:
Being a linux computer with AGP graphics cards, maybe you can install two nVidia Quadro with the nVidia driver. I did in my pc and the driver is embedded in a script which needs some libraries and compilers to build itself in the destination system. It needs some kernel sources to compile also.

Well, first of all I need to score a couple of AGP cards and then hope there's sufficient drivers around for this to work. The kernel is ancient (in terms of Linux) as it is right now, so first act would be to get the most rescent linux distribution there is out there to run on this thing.
Remember, this is an SGI-ified machine and is a bit different hardware-wise than just the CPUs. Remember, all those Craylink-goodies still apply on this thing as it does on the Altix, so kernel support for various hardware bits must be present in the kernel somehow. There's more than just the CPU-support...

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
eMGee wrote:
Would VMS run on it? Or would that be pretty much limited to the Integrity systems? Due to the lack of SRM and so on (I only have ran VMS on AXP, so I wouldn't know...)

To put it short: no.
I think the main reason for VMS or HP-UX won't run on it is simply that I don't it has the proper chipset for those OS'es. HP-UX and VMS were tailored to run on specific HP Integrity machines and (I think) requires the ZX1/ZX2 or ZX1000/ZX2000 chipset.

But then again, I've got HP-UX 11i v3 DCOE sitting here at work so I might as well try it just for fun...

Quote:
If you want to try something, maybe it'd be worth to build Blender and do some benchmarks? (Like the one on Ian [Mapleson]'s excellent site). Or, you could try to see if there's an archived version of Houdini Apprentice somewhere; although I'm not sure if it ever appeared for IA64 Linux, only for Windows I believe. (But I'm not 100% sure).

It sure would be nice to try, but I have to devote time for it. Also, then there's the Linux-kernel and surrounding binaries required to be a little bit more up to date than they're currently is.

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
All in all I think it's somewhat unfair to compare the IA64 architecture vs the x64 architecture - they're aimed at different markets. Customers who use IA64 inside Integrity machines usually have to rely on multitudes of error-correction schemes to be absolutely dead-sure that their data stays intact and doesn't fsck things up between transactions. Banking, stockmarkets, process industry, etc all rely on their equipment running 100% and can't tolerate failures. This involves very heavy testing in the design phase of these and thorough planning is a must.
Performance for these types of customers doesn't have to be the absolute first priority, neither does TDP values or other stuff - they'll happily pay if they can be sure to keep error-free data. (Is there such things?)

Alot of the blame for the latest Itanium2 chips delay were caused of errors discovered in their 6 month long testing phases they use. (They don't involve more than what? 1 month? on their IA32 stuff) That coupled with requested design features from companies with the big wallets.

What still amazes me is that SGI choose IA64 for their HPC stuff. Ofcourse the IA64 was ment to be the future replacement processor for heavy HPC tasks, but it wasn't a real performer until the later Itanium2 chips came to market. Even today with the latest generation Itanium2 I believe Intel have came to market a little bit too late for their HPC customers (SGI). It was a little unfocused at one point where you didn't actually need the IA64 features, but really NEEDED the performance... I suppose SGI saw that and came up with the Altix ICE.

Now when Altix UV hit the market they're back on focus on performance on HPC, but with added muscles (QPI and other features) to advance on HPC. The downside for SGI is that they're not alone on this bandwagon... IBM have their own system designs coming up with UV-like interconnects.

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
There's some traces of 'Xeon' talk here:

http://www.itjungle.com/breaking/bn051903-story02.html

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
I've "touched" only two types of Unisys boxes in my life so far and the first model was a large 19" rack-sized box with what was two i286 processors (or was that MC68020?). Not even worth hauling, so I never got away hauling it.
The second system was more of a cube-shaped deskside machine which ran some odd type of OS that I can't even remember what it was. Someone told me that "thing" had 10's of i386-processors in it, but I never got the chance to take a glimpse inside it to check it out until I switched jobs and the thing was decommishioned.
By that time I had a RS/6000 570F system, so my needs were fulfilled by that time.

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
What that 1U box standing against the PI?

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
Fact is, Mickeysoft can't compete with their Windows-suite on the enterprise (IA64) platforms simply because noone asks for them. In that territory the customers don't even care for Windows since all their apps are running on other platforms. Want to run notepad.exe? There are verrrry few apps out there for Win/IA64, so why bother?

Mickeysoft DO however try to target bankings and other larger firms with their SQL-server on IA64 platform, but as much as HP wants to advertise about this, they don't win marketshares in the extent they want to.

Just look at Windows NT/2000 on Alpha, Mickeysofts tryouts in the PPC/MIPS territory, rescent IA64-venture... It all boils down to the volume segment and where they can get enough money for their investments. Just about any company financial director would look at the facts and just axe it, like they've done several times before.

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
I myself has a SS20 with dual SM71s and somewhere around 200MB och RAM in it. It's even got the original 9GB SUN harddrive in it. :-)
It sits in a Aurora2 chassie donated from a dead SS5-170 many years ago, so it's got a 40x NEC CDROM in it. Graphics is still TGX as the VDIMMs are pretty rare sight.
Played a little with NEXTstep on it, but have touched it since then.

I'm torn between keeping it or just let it off to someone else, since I have too much stuff on my hands as it is already.

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
I know RAID-3 would be more suitable for sequential reads/writes, whereas random I/O sucks. RAID-5 is just too much overhead for anything other than random I/Os.

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
SAQ wrote:
A few years ago they did some research and found that RAID5 arrays tended to have a problematic failure mode much more often than others. A single disk would go down (OK, that's why I have RAID5 redundancy, right?), but then during rebuilding the array a second drive would go down. I can't remember the numbers, but it was enough of a risk to where I do not use RAID-5 any more.

Just how isolated was this sort of behaviour?

Why I'm asking is that at one of my customers we had a breakdown on a RAID-6 raidset in a HP MSA1500 array. These were a diskbox full (20 disks) of 500GB SATA drives. Everything was fine and we popped in a new drive the next morning, when we found *another* failed drive in the very same box and therefore the same raidset. Since a RAID-6 survives two drives failing, that was OK. The rebuild of the first failed drive went along and that night a *third* drive went dead - and the raidset wasn't fully syncronized yet.
Epic fail.

We've isolated this behaviour to a specific line of Maxtor drives, whereas HP now sends out only Seagate drives to replace them. So far we got a few of those Maxtors left, but I can't replace it and wait for a rebuild... a second or third drive might pop in the progress when the load rises.

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
Oh and I forgot to mention, we've got in the areas of 60TB+ of harddrive space altogether and RAID-5 is just fine.
But then we're talking SCSI or FC drives...
:O3200: :Fuel: :Indy: :O3x02L:
jade_angel wrote: As much as I prefer RAID10 for both performance and reliability reasons, RAID6 might make more sense in your case if you can't afford/use 14 disks.

If you don't mind a massive overhead in parity calculations, RAID-6 does the job.
RAID-DP (dual-parity in NetApp) gets around this problem by doing all the calculations in NVRAM and write all the data on all the involved disks *once*, and that's it.

It may be too late now, but I've heard it suggested that your drives should come from a mix of manufacturers, to reduce the odds of multiple drives puking simultaneously due to the same manufacturing fault/firmware bug/etc. Honestly I don't know how much this helps, but intuitively it makes sense.

There's a good point in that, since that would have saved us from our RAID-6 failure when three drives died.
Syncing up a RAID-6 raidset takes forever and that added load on the drives took the other drives as well...
:O3200: :Fuel: :Indy: :O3x02L:
I've got some brand new spare parts for Origin3xxx series stuff in storage at home. I'll dig into it as soon as I can.

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
I've got a couple, but they're on the other side of the pond and shipping would probably be a killer.

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
Pontus wrote: Thank you! Already in my signature. Soon there will be no space left for text :D

Speaking of which... How's my old DECsystem doing?
:O3200: :Fuel: :Indy: :O3x02L:
My fiancee didn't need or wanted a smartphone, so she got one anyway - and she loves it. :-)

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
How cool is that?
Where is that musem? Just in case I get to go to the UK sometime...

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
I actually remember playing around with 3D Studio on DOS back in the days...

_________________
:O3000: :Fuel: :Indy: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300: :0300:
I've decided to part out some of the equipment in storage because of lack of time and space for them.
I need to make room for other projects at the moment.

Six SGI Origin 350 systems as below: All six modules are gone.
(SGI calls these 2U rack servers as "modules")

(Qty 0) Origin 350 - Base Compute Module ( Had two, both of them sold )
4 x 700MHz CPUs
8 x 512MB (Premium) RAM - total 4GB
IO9 card + drivecage
2 x empty drive sleds
no harddrives (standard 3.5" SCSI SCA as in Octane and others)

(Qty 0) Origin 350 - Base Compute Module ( Had two, both of them sold )
4 x 700MHz CPUs
2 x 512MB (Premium) RAM - total 1GB
IO9 card + drivecage
2 x empty drive sleds
no harddrives (standard 3.5" SCSI SCA as in Octane and others)

(Qty 0) Origin 350 - MPX Module ( Had two, both of them sold )
4 x 700MHz CPUs
2 x 512MB (Premium) RAM - total 1GB

All systems are tested and verified working.

There are two variants of the Origin 350 bricks; Base Compute Module and MPX Module.
The Base Compute Module works standalone just like any standard system. They are fitted with an IO9 adapter card which provides gigabit Ethernet, SCSI for internal disks, IDE for system CD/DVD-ROM and provides NVRAM to keep system enviroments. There's also correct IDE+SCSI cabling for the drives and ofcourse disk sleds. Without the IO9 card the machine cannot work standalone. (These cards are a rare sight and often cost lots of money on eBay)
The MPX Module lacks the IO9 daughtercard, the drive cables and sleds. (Without this it won't work standalone and must be connected to either a Base Compute Module or a NUMAlink router.) Other than that, it's an ordinary Origin brick.

All compute modules are packed and ready to go, but I haven't packed the MPX modules yet cause lack of appropriate shipping boxes. The MPX modules is a little bit of a gamble to see if someone's interested in them. They mate up perfectly with either of the others through NUMAlink cable though. ;)

I haven't calculated shipping yet, so I might or might not be able to offer shipping through the local post office - their limit is 20kg.
The deal depends really on if you have the possibility to either pick them up (northern parts of Sweden), ship within Sweden (no weight limit using bus shipping) or arrange your own shipping.

I've got other stuff coming up also a bit later... AC-powered NUMAlink router, AC-powered L2-controller, etc. The router + L2 are both gone.


( Everything gone - nothing to see here. )
:O3200: :Fuel: :Indy: :O3x02L: