The collected works of mapesdhs - Page 3

What are the correct environment variables to set for Python btw? What would they be for a normal
installation with Python 2.5.2? Anyone care to post their .cshrc entries for V2.5.2?

Ian.

No such luck...



Ian.

nekonoko writes:
> You guys are not reading this thread in its entirety:

Whoops! I had read that a while back, but forgot.


> Perform that step and it should work.

Yep, works ok! But as before, it's a lot slower than V2.44 (1 min 17s on quad-1gig Tezro with V2.48, vs. 1 min exactly with V2.44).

Ian.

japes wrote: ... All the old SCSI hard drives I have in my Indy's are far louder than the power supply fan.

There are better alternatives:

- Seagate 18GB 50pin (ST318418N): very, very quiet indeed. Actually annoying sometimes when testing stuff, keeps
fooling me it's not even powered on. I honestly can't hear it making any noise when the system is power on (R5K/180,
XZ, 256MB). There's one on eBay USA for 56 UKP which is much less than my price (I have two, one is spare).

- IBM-branded 9GB Seagate U160 ST39236LC (with adapter). Unbelievably low-noise. I've yet to find a quieter SCA
drive than this one. I don't know if the generic ST39236LC is just as quiet, or if the IBM version is special in some way.
Couple on eBay USA for approx. 25 UKP.

Ian.

The Keeper wrote:
> Just keep in mind that if you're looking for total silence, you need not just specific models, but also a brand new drive. Not used, not refurb,
> but brand spanking new. Anything with moving parts can start making noise when those moving parts move.

That's being overly fussy IMO. The Seagate 18GB 50pins I have really are ridiculously silent. Friend of mine from SUN was over today,
I got talking to him about drive/system noise, so I put together an Indy with a Sony PSU and the 18GB Seagate - he agreed, almost no
noise at all. One can just about her a faint whir as the drive spins up, but afterwards there's basically zip. I make a lot more noise just
typing.

Sure, used drives can develop odd noises, etc. and lose any nice quietness, but it's equally possible to get used drives that work flawlessly.


> And, generally speaking, I'd try to avoid multiple adapters from different manufacturers if you can help it. ...

Never had a problem with this myself. It's just a single conversion afterall. I'd be much more wary of SCSI/IDE conversion.

Ian.

I finally received the Onyx3800 I bought from Jesse ( hirudin ). The system is (almost) a 36-CPU (all R14K/600MHz 8MB) 2-pipe IR3 (2RM10
per pipe) with HD option + VBOB, four P-bricks, one X-brick. The original config was in 6 racks; Jesse kept 2 racks, I bought the contents of the
other 4 racks...



Just needs an I-brick now, which I've ordered from elsewhere; should arrive in a week or two.

It was an interesting experience getting it all unloaded, with oodles of help from a friend of mine, Gavin Saxby, who works at SUN (thanks Gavin!).
Mega thanks to Jesse for his excellent padding of the brick ends! No damage at all in transit. I used the WTA ( World Transport Agency ) to ship the
bricks by sea from Jesse in CA (Titan Packaging did the crating) door-to-door to me in the UK. My thanks to Anita Davies and Nick Thompson at
the WTA for all their help. If you need to ship any seriously heavy SGI stuff, the WTA are very good. The crate was 87" (L) x 49.5" (W) x 44" (H),
ie. just over 3 cubic metres. Total pallet weight was 1633 lbs (741kg). The shipping cost was 2139 UKP.

After the truck arrived , and despite some brave attempts , the driver wasn't able to reverse the truck up my drive, so he moved the crate
onto the tail lift ( not easy! Took about 15 mins but he managed it eventually ), rested the lift on the road, and then we had to whoosh it round and
up onto the initial rise of the driveway using the pallet mover, heaving the crate bit by bit all the way along to be as close to my
garage as possible (using a large plank from the truck and two old table tops I had as 'bedding' for the pallet mover; both the table
tops were trashed of course, but who cares, they're only chipboard - a worthy sacrifice for a greater cause, hehe.) Eventually did it though!...



Once the driver left (squinting heavily in this picture as the sun was in his eyes; I gave him a pack of Jaffa cakes for his troubles - above
& beyond the call of duty!), Gavin & I spent 2 hours unpacking everything...











Here's a short movie showing Gavin beginning to remove the lid (8MB QuickTime, done with my wierd digital camera. Play with mplayer or xanim, force no-audio; I'll convert it to a better format later.

With space in my garage prepared , we moved all the bricks inside, positioned more or less where I hoped they should be for eventual cabling...



The cables are just in a heap at the moment, will sort them out later.

Here's another image taken after I put the Onyx2 back into position - it fit nicely into the gap at the end:




Once I receive the I-brick, then begins the highly enjoyable task (ahem) of cabling things together, though I don't intend to use any
more than 3 or 4 C-bricks as I doubt the power supply to the garage could handle more than that (I'll see how it goes).

Lastly, in the modern spirit of recycling, the giant pallet base was collected on Thursday (12/Mar) by a guy who wanted to use it for making a raised garden bed,
while the side panels were collected by someone for use in his modern smokeless wood-burning stove. (hooray for the local Freecycle network!).

Cheers!!

Ian.

PS. The base pallet alone weighs more than 100kg. With hindsight, it would have been better to use two separate smaller pallets, but never mind.

It was a lot bigger in the original rack units (4 of them) but they're way too big for me to store, and would have added a lot of extra weight.

Infact, some of the bricks seem overly huge given their contents, eg. the X-brick. With the right tools, one could probably mod some of
the bricks to make them a hefty bit smaller.

Ian.

pentium writes:
> Oh my god that is far larger than I would of imagined!

It's tiny compared to what an O3K is capable of being (2048 CPUs, 16 gfx pipes, etc.)


> How much did that cost you to ship?

Details are in my 1st post (you did read the text, yes?

Ian.

japes wrote: Anything interesting in all those P-bricks? Seems like a lot of PCI slots for what was a 48 cpu machine.

They all have a bunch of single-port 2Gbit FC cards, 4 cards per brick I think.

I'm not sure offhand if the X-brick has anything in it. The G-brick has the HD-GVO option, but the VBOB is indoors atm.

Ian.

What's the model number of the IDE/SATA bridge? And how does a diskperf run on the drive?

Also, would the SAS3041XL-S work ok aswell?

Ian.

Yes, it's low profile. Infact it looks identical to your picture. Thanks!!

Ian.

Thanks for all the info! This certainly opens up a much greater range of storage possibilities. I wonder how XLV
would fair with a bunch of modern drives on one of these? Hmm...

Ian.

One thing I was told from a guy at a local Novell office was that it's definitely worth trying to nab a SATA 10K.
They replaced the disk in their winblows server with such a drive and it turned into a speed-boot demon.

The LSI card I was watching ended a bit high for me (and why the heck did the seller have to end the auction
at 4:39am??), but there are others.

Ian.

tbcpp wrote: Seems like I've heard the 2.5 should come out in July 09, but I may be wrong there. Anyway, tons of new awesome features in this version.

Sounds great!!

Hate to ask btw, but what is it about successive versions since 2.44 that's mean the render has become slower? (now by quite
a margin)

Ian.

hamei wrote: Ian, Ian, Ian ... you've been around for ages. You should speak developerese by now ! "tons of new awesome features in this version" = "slower than dogshit."

8D

Ah well, I suppose with lots of threads there'll be a point at which the slowdown is countered ok.

Does this version support network rendering using multiple hosts? Would be a laugh if I linked up a few of the systems I have, see
what it could do...

Ian.

tbcpp wrote: I compiled versions 2.46, 2.47, 2.48a, and the svn trunk, and didn't see much of a slowdown. ...

The biggest drop was after 2.44, some 11% down.

Ian.

Here's the simple test I did using a dual-300 Octane2, the same scene with different releases:




I've not tried the test with 2.48a yet, but here's a comparison of 2.44 vs. 2.48a using my Fuel/900:



It's... well... kindof a huge difference, more than 30% slower.

Surely it makes sense to get the single CPU efficiency sorted out first before trying to go parallel? At least, that's what
a Cray guy once told me about this sort of thing.

Ian.

sybrfreq writes:
> I would think (as a layman ) that it would be better to just throw more processors at the problem than try and hack up the
> code for better single processor speed, considering today's (and yesterday's) multi-core machines and that the speed losses
> came as a cost of more features.

IMO that idea is a microcosm of why the world's going right down the toilet... :}

So how bad does one allow the basic rendering inefficiency to become? 50% worse? 100% worse? Unless the code does a
decent job of rendering with a single core, having lots of threads is just being lazy IMO. Come on guys, I thought the idea of
all this sort of thing was to write good code, not just any-old-code-will-do...

This is the same slippery slope that gfx cards have dived down - nobody bothers writing efficient engines, just let ever
faster hardware boost the speed.

And hey, aren't we trying to save the planet and all that? (at least yesterday anyway What we're effectively saying here is
that it's ok to knowingly use a significantly greater amount of power to achieve the same render time, when a bit of effort
would cut those times by more than a quarter.

I say get the basic rendering system working well first, then think about threading it out. As it stands, what we have right
now is a build that means a dual-300 Octane is no better than a single-400 Octane. Not good IMO.

By definition (I would have thought) any extra efficiency in the code will automatically be passed on to all threads when running
on multiple cores. That's a major saving in time, energy & hence money.

People often moan about MS apps getting all bloaty. We should be on our guard against freeware sw going the same way.

Ian.

I'm getting a bit sick of seeing the Itanic label. IA64 is actually a decent CPU these days. The orig release was
poor, but not now , despite the delays. At 1.66GHz, the Itanium2 is perfectly capable of being 100% faster than
a 3GHz XEON 5460, and it can beat the 4.7GHz Power6 on some codes (depends on the task; for others, it's slower of course,
but its performance is remarkable given the low clock).

If the current IA64 was a poor performer, then the harsh nickname would be suitable, but this is simply not the case.

i7 is clearly better though, so it makes sense for SGI's next shared memory system to use the i7 XEON.

Ian.

jan-jaap wrote: Yeah, but I can buy a dozen XEONs for the price of one Itanium2, so the FLOPS/$$$ ratio is still miserable.

And your XEON shared memory system is where, exactly?

Point is, for those codes that benefit from the arch, Altix 4K is a good system. i7 will be better though, and as you say cheaper.

Ian.

Just mkdir /CDROM2 manually?...

Ian.

As in using /CDROM2 as a mount point for a 2nd device? Yes.

One thing though: be careful about using such a 2nd unit for installing software. swmgr gets confused
by /CDROM2, fails to properly track CD sources. Always use the /CDROM device with swmgr.

Ian.

Just some general info for you all...

T'was my bday on 19th May, so I asked for some dosh from parents/brother, bought myself a 1TB SATA for
my PC (movie archiving), though I'll test it when I can in a Fuel with an LSI card, see how it fares.

Anyway, my PC has a 146GB Maxtor Atlas 15K II as a system disk, same model I use in almost all my
SGIs and the main drive I recommend for those who want the best in an SGI (plenty available if anyone's
interested! ;D). I thought a performance comparison with the SATA might be interesting, the classic
space vs. speed issue so often discussed. How well does the old SCSI drive compare? I like the Maxtor
because of its fast access time (ideal as a system disk, ie. searching files, etc.), but despite its
age (released November 2004) it holds up rather well against the SATA, except for burst read where
presumably the faster/larger cache RAM in the modern SATA has an advantage. The following is from
testing with HDTach, standard read test, in order of max sustained speed:



Note the average sustained speed is almost identical between the Samsung and the Maxtor (shows how long it's taken
for IDE/SATA to catch up), but check out the average access times! Also rather interesting, I first tested the Samsung
using the PC mbd's onboard Marvell RAID controller, which gave a substantially lower Burst rate (155MB/sec) and a
slightly lower average rate that matched the Maxtor (89.3). Looks like the choice of SATA controller in a PC is important
(the mbd's NVIDIA controller is much better).

For a real world test, I copied a 6.7GB VOB file from the Maxtor to the Samsung, which completed in 80 seconds, avg
speed 84MB/sec.

The Samsung isn't the fastest SATA around, but it's pretty high up the scale and is a decent tradeoff between speed and
price (in UKP, 65 + 6 shipping from CCL Online).


Are there any gotchas I should watch out for though when testing the Samsung with the Fuel?

Ian.

Dr. Dave writes:
> Regarding newer drives, high platter densities mean that the areal transfer rates have gone way up on consumer drives lately
> - but as your test has noted the access times (and latencies) would still be better on the 15k drives. The 10k SATA drives are
> likely in the middle.

Yup, that makes sense.

Btw, an update on the 'best' 15K drive for SGIs. Ok, so I'll admit I'm surprised. Today I received a Fujitsu 300GB 15K SCA SCSI
(which will now be the new system disk in my Fuel), a drive I bought 'cos the price was good and I needed more space in my
Fuel. First, here's the diskperf for a Maxtor 15K II 146GB:



Ok, pretty good, but now check the Fujitsu (the model is MBA3300NC):



Good grud! This is the first SCSI disk I've come across that can sustain more than 100MB/sec, but it's way over 100! Wow!

So, I guess I'd now have to say this Fujitsu is the best possible SCSI disk for an SGI, but they're hard as hell to find (certainly
for a decent price anyway - I was damn lucky for sure), whereas I have more than 50 of the Maxtors available...

If anyone comes across a drive that beats the above Fujitsu, please let me know! Hmm, before I fit it into the Fuel, I'll connect
it to my PC and run HDTach, see what it comes up with. Should be interesting...


> As for testing gotchas, I'd be concerned that for large contiguous files the SATA drive will post good numbers,
> but for small file accesses with lots of random seeks, the 15k SCSI drive will likely still win out by a fair margin.

Absolutely true, which is why I'm fortunate in this regard since I'll be using the SATA disk to store large files,
typically 500MB to 2GB, so the slower access time isn't an issue.


> As a note, I always try to use a 15k drive as the root drive on any of the later-model SGI's I have ...

Despite the lower sustained max speed, a 15K helps in Octane aswell, boosting file searches, etc. by more than 30%.
Any O3K machine just gets more out of them given the use of an U160 bus, though of course Octane can aswell if
the disk is connected via better SCSI card.


> ... doesn't have to be more than 18GB or so to give you ample room for just about anything you'd want to do if you
> set it up this way, and 18GB 15k drives are pretty cheap.

(I even have a couple of 9GB 15Ks available! Wierd huh? I didn't know anyone made 9GB 15Ks)

An 18GB 15K is certainly cheap, but it's not very fast. Infact an 18GB 15K is typically slower than a reasonable
36GB or 73GB 10K for sustained read/write. For example, here's a typical 18GB 15K Seagate (all these tests were
done with a Fuel/600):



That's pretty horrible. Would the access time really be all that good? I'm not so sure. Either way, compare the above
to a Fujitsu 73GB 10K:



Blows the 18GB 15K away completely.

I'm sure the 18GB 15K was nice when drives were typically no more than 18GB max capacity, but at least for sustained read/write
they've long since been surpassed by newer 10K drives.

If I get a chance, I'll try one of the 18GB 15Ks with HDTach aswell, see what it says about average access time.

(EDIT: tested! Susained 18GB 15K speed isn't that good, but the access time, 6ms, is still way better than the SATA, and not that
much slower than modern 15Ks. See the table in my previous post, ammended with extra results)


> So keeping this in mind, probably the two tests I'd try is a huge contiguous file transfer, and maybe a 'find' function across the
> disk to replicate random seek timing effects, using a SATA drive which has a duplicate filesystem to ensure the tests are

Yes, I already have a 'find' test, consists of searching all of the contents of /usr/share (pre-copied onto a target drive before
a reboot prior to the test), 715MB of data, more than 54000 files, ie. searching for a non-existent file forces the search to
scan the entire archive. System is rebooted before each test of course. I've not tried this test with any newer models such as the
Maxtor mentioned earlier, but here's an example comparison of a 10K vs. a 15K in a Fuel/500:



ie. about 40% faster with a 15K.


> ... though since it uses only the portion of the disk that the temp file is on, the numbers only represent a portion of the
> transfer curve for the platter.

If the disk is blank via a freshly done mkfs, where on the drive will the file be placed when one does a mkfile to create
the test file? On the slowest part of the platters, or the fastest? Do all disks default to writing data in the same place when
they're initially empty?

Either way, I'm slowly building up a collection of diskperfs for various drives. When I have a decent number, I'll add the
info as links from my disks-for-sale page, and keep the entries shown even when I've none in stock (text will be in
italics) so the reference info is still accessible.

EDIT:

Just discovered one of my Seagate 146GB/15Ks is pretty fast too (faster than the Maxtor), ie. the ST3146855LC:



Seems to be slightly faster than the Fujitsu.

Dr Dave, I added a few more results to the table in my last post (have a look). It seems you were right; though the
sustained rates with the older 15K drives is much less, the access time remain nice and fast.

Ian.