The collected works of chervarium

I've just gotten that mplayer binary build installed on my Octane (R12k/270MHz, ESI) and it works very well, DivX4v3, over NFS and without the framedrop option :). Anyway I don't have TRAM module and cannot scale the movie fullscreen... I'd report results with more video streams latter.
The system looks quite responsive while that thing is playing.

hamei wrote:

lewis wrote: Why would having more than one drawing thread make any difference on a dual machine? The first CPU is occupied entirely with the MPEG2 codec... if I had an Origin, then yeah, but I think that can wait :)

I think you need to know more about how the scheduler works to really say. I'm not up on SGI multi-processing but in OS/2 (very thread-oriented system) the scheduler makes all those decisions in a round-robin fashion. As any task gets completed its cpu becomes available. The scheduler hands the next thread to the first available processor. Your computer DOES have more going on than this one process. You can't really say "one cpu is occupied entirely with" by any stretch of the imagination, unless that task was particularly written to do that AND the operating system would let you HAVE that much priority.

I'd be real surprised if it did. OS/2 certainly won't let you. You're in applications, not systems level ....

To hamei:
IRIX has a syscall for doing exactly these things, namely sysmp(2), which grants fine control. On multiprocessor system one may do a lot of things with processes and CPUs, for example restricting a processor from running any processes except those assigned to it, isolating CPU, disabling scheduler interrupt for a given processor (thus granting realtime priority), etc. etc.

To lewis:
I am with you captain

lewis, would you try this approach, I believe some of the bottlenecks are cleared
(notice1: code is edited since its first version! Reread)
(notice2: R10k/R12k pipeline)

lewis wrote: I tried your code before you edited it, and... nothing changed. I'm losing sight of what exactly is going on here. What you did makes a lot of sense, I really should have thought of using only one 32bit memory store like that :) Although you do have the bytes back to front. GL_ABGR_EXT is your friend. What do you mean by "R10k pipeline"? Are you relying on speculative memory fetches or something?
...

I wrote this with several paradigms in mind. First, lb/sb are slow instructions and would break the dispatch bad, so better only storing a word after 3 fetches than storing bytes. Second, binary arithmetic instead the normal one when it comes to this. It makes spaghetti code but is slightly faster. And the third one, watching the assembly output of the compiler, realigning/changing the C code, and giving back some hints (I like it portable). After some tweaking I got emitted the prefetches I wanted and the instruction pipelining I wanted (the "R10k/R12k ..."). The final thing (the one here) worked well, I got it ~5 times faster (10000 frames (~5m at 30fps) in stable 1m55s against stable 9m) performance than the first two codes.

Looks like the bottleneck then might be in the gl libraries itself... I don't have your source tree but if you don't mind to share it I would play some profiling around. I got interested into this.

Btw. I am building with MIPSpro which has better optimiser.

nvukovlj wrote: I see you're using semaphores - are they being used just as binary semaphores, or can the value go above 1 ?
Also, is the semaphore being created meant to be used accross processes, or within a process, as currently it is being initialised as a semaphore that can be shared amongst processes.

The semaphore switches at 30Hz so wouldn't make a great penalty.

brent wrote: rld: Error: unresolvable symbol in /opt/mplayer/bin/mplayer: _nanf_val
rld: Fatal Error: this executable has unresolvable symbols

You'll have to upgrade to a recent IRIX version. This MPlayer package is built against recent libraries and you won't be able to run it on 6.5.10.

Intel-OUTSIDE wrote: this is good even if cosmos hates it, it means we can get some documentation on the hardware at last.

You get no documentation for the Octane hardware. It's all wild guessing. I'll never use an operating system that'd guess what to write in any hardware registers. It is not the right way to make a port.

Intel-OUTSIDE wrote: for example, who read this thread and got the evil idea of building a quad-cpu module or a sub-pcb to link a couple of twin modules together?
i did!

No way with Octane RACER. Period.


On the asbestos - I'd suggest a good lead shielding as I prefer neutron sources :).

Well... Being an UNIX bastard I'll advocate on behalf of irssi. Clean, simple, lightweight, with relatively well designed code and having features like external perl or .so plugins - what else one may want? ;)

Well... You have two options: 1> write nick autocompletion yourself and 2> use something already written. In the latter case I'd recommend lice (ask google for lice+epic), rather configurable script, adding many functionalities to epic et cetera.
BTW I have nothing against epic except the UTF-8 support. It hit me hard when I switched to UTF-8 locale on my BSDs and it has to be almost fully rewritten to support wide chars. That's why I'm using irssi now.
Good luck.

unixmuseum wrote:

zafunk wrote: I'd like to know what the tag line says. I made a half hearted attempt to translate it a while back, but got nowhere. So I gave up! :D

"I think dirty thoughts are very bad"?

Isn't it more like "I think porn is inappropriate" or "Porn is bad for you" said in some kind of polite way?

Here are working instructions for netbooting a miniroot (the server is FreeBSD, but it shouldn't be very different with the tux).

1) /etc/bootptab

2) /etc/ethers

3) /etc/hosts

4) /etc/inetd.conf (the tftp line usually is commented out on my host, so don't forget the killall -HUP inetd)

5) /usr/src/bin/sh/builtins.def (this step is essential as IRIX expects a Korn shell in place of /bin/sh and Bourne's shell builtin echo is not compatible with ksh, while the external /bin/echo command is. Requires rebuilding of sh after the change - make && make install && make clean)

6) ~/.rhosts (that is, /home/chervarium/.rhosts)


With the files set up like this I'd fire bootpd with (-h option 'coz my SGI/Sun workstations live in separate vlan and the only way to tell bootpd to listen on the appropriate interface is to supply -h), then'd reboot the workstation and choose the "Install System Software" from the PROM menu. I'd set the server to 192.168.13.1 and the path to /usr/data/IRIX/6.5.26/cd1 (that's the latest inst.tools CD, gunzipped and untarred from the SupportFolio files). Boots like a charm. The only drawback of this method is that it'd require (I'd never ever let anything to log in as root from the network, never).

Here's a fix of the reverse lookup issues with IRIX' dns(7P) resolver and IPv6. The problem was introduced with the deprecation of IP6.INT. (according to rfc1886) as a reverse lookup domain and the introduction of IP6.ARPA. - IRIX does still use IP6.INT., which is considered wrong in a production environment (prefix 2001::/16).

Tonight I conducted some research on the topic and the result is a quick fix (at least until SGI provides a real patch). In the strings output on /var/ns/lib/libns_dns.so the wrong IP6.INT. reference could easily be spotted - and the same string happens to be aligned with a dozen of '\x00' bytes, so modifying it to "ip6.arpa." is easy. I spent several more hours with elfdump and dis to make sure that no function does use the string with nasty fixed lengths and/or offsets... Looks like the change is safe and does even work .

squeen wrote: Wow. SGI aught to impliment it! Have you contacted them?

Even if I contact them, I have a support contract no more and will never get the official patch (given that there'll be one). I spoke with a guy from SGI in January and he sent my questions to the IPv6 group. Their answer was that everything works and there are no problems at all...

The newly introduced host and dig commands (from the BIND distribution) are compiled with bitlabels over IP6.ARPA. This is de facto an experimental feature and won't become a production standard anytime soon (the deprecation of IP6.INT. was announced in Aug, 2001 (rfc3152) and there are several memos suggesting that the complete IP6.INT. termination will happen on Jun, 1, 2005). But I can't really fix this one with a simple hex editor...

EDIT:
By the way eoe.sw.svr4net is claimed to work with IPv6 but it doesn't, therefore, if one wants/has to use rpc (and nfs) over IPv6 the only solution is to remove eoe.sw.svr4net... Maybe they'll fix it in .28 ...

s/Grobarium/chervarium/g

Why not?
Everything that's within the mighty limit of four hours in flight is fine by me.

cyclo-2,4,6-trimethylene-1,3,5-trinitramine (RDX) is the way to go

VenomousPinecone wrote: You kids and you fancy designer drugs, whatever happened to good old alcohol?

You have not done any research on the molecule I've just posted, have you .
Besides, I'm (ab)using booze with high octane/cetane number all the time .

nekonoko wrote:

VenomousPinecone wrote: Hehe, well I must admit anything with an acronym for a name sounds designer to me.

I believe RDX is a component used in explosives, not a drug

That's ritgh neko, RDX is high order explosive. It should have been obvious to everybody from the =N-NO2 groups (nitramide radical).

Sedate it for God sake.
Your vet will probably be able to help you.

Anybody from the EU willing to take part in several facsimile tests?

For the others - I'm sorry, but the VersaHell (a.k.a. Versatel) carrier is causing me a lot of troubles with their connectivity. Not to mention one of my E1 uplinks with HDLC errors and the wrongly routed calls...

Here comes the list:

(Sun) Elite3D-m6
(SGI) IP30 R12000/270MHz processor module (030-1467 boards only)
(SGI) 2xESI framebuffer
(SGI) 1xXIO2PCI bridge card for O2k

You only have to pay the shipping costs from .bg to your place (the hw is for free)...

PM me.

It's the Blade 1k UPA card. I don't think it'll fit in U2.

Yesterday I found the home page of Aad van der Steen/Universiteit Utrecht. It's not exactly SGI related page, but there are several (very) good papers on the Origin 2000 architecture/O2K performance evaluation, (super)computer architectures in general, as well as the EuroBen source code and performance comparisons. Enjoy reading .

Links:
http://www.fys.ruu.nl/~steen/
http://www.euroben.nl/reports/O2000.ps.gz
http://www.euroben.nl/reports

Go for a NEC/Mitsubishi or iiyama CRT monitor, their monitors are of a very high quality (I happen to own a 22" NEC/Mitsubishi one and I'm really happy with it). You'll only have to buy a 13W3-to-coaxial/DB15 cable/adapter. But beware, the TFT, the newest hype, is crap.

maxsleg wrote: nice machine and welcome to the 2k club Where did it come from and what do you plan to use it for?

Danke schön ! I bought the Origin on ebay.de and if I'm not wrong it belonged to Fraunhofer-Gesellschaft (the hostname was something.blah.blah.fhg.de). I've queued several molecular dynamics jobs already, so the computer is busy atm. I will mostly use it for offline signal processing and molecular dynamics.

qumefox wrote: One thing I see of note though. You might want to take 512mb out of M1 N1 and M1 N4 and put them in M1 N3, that will give you a least 1GB in every node. As it sits, M1 N3 only has 256mb.

I know, but right now I don't have much time to remove the nodes from the lower brick and swap DIMMs. It has certain impact on the calculations that run on M1N3 so I'll fix this soon.

qumefox wrote:

chervarium wrote: Danke schön ! I bought the Origin on ebay.de and if I'm not wrong it belonged to Fraunhofer-Gesellschaft (the hostname was something.blah.blah.fhg.de). I've queued several molecular dynamics jobs already, so the computer is busy atm. I will mostly use it for offline signal processing and molecular dynamics.

Wow. One that gets put to real use. Kinda makes me feel bad. My 2400 only gets run on weekends doing blender rendering. Other than that it's just a lamp.

Origins are not exactly collectibles and I'm following that simple rule. I wouldn't have bought it hadn't I had a purpose for the machine. I paid less than a thousand € for it and I was able to push it over the 6Gflops limit (with certain code optimisations). Had I gone for a PC (Intel Xeon or AMD Opteron), I would have paid much more than a few hundred €'s and I would have had to port the code to x86/x64 and tested it for correctness (which is painfully slow operation). Besides I can always buy a second rack and connect it to the system I've gotten already if I need horsepower (I happen to have a few spare NUMAlink cables handy). Simple rule of thumb, isn't it .

A 2nd hand Foundry Bigiron 4000 is also an option. It's a very good switch with a lot of expansion options, both fibre and copper.

The bootmaster is THE bootmaster (Monarch in HP terms), but after the OS is up and running the bootmaster/Monarch is just another cpu node and the operating system may schedule whatever it chooses on it. In fact, every time I have to reboot/halt my Origin 2k, the reboot is initiated from a different cpu, ID.EST, not a single node/cpu is a master anymore from the OS perspective.

SAQ wrote: Like I said, it seems to have evened out later.

I think I recall reading that (in addition to the cache bit) SGI NUMA archs try to keep things local to a node to minimize remote memory access, and since I have only one processor per node, that would necessarily mean keeping it to a single processor.

I just wasn't sure - MP SPARCstations recommend the faster processor be the first one, wasn't sure if SGI had gotten away from this (seems like they have).

On the plus side, it's noticeably faster than the old I2

Just like any other NUMA computer... The bootmaster is nothing but a normal node after the kernel is up. One can certainly "influence" the scheduling of the bottom halves of the interrupt handlers, but to what extend? There are no real interrupts in the XIO environment, there are only packets routed through the fabric.

I bought new headphones today and found something quite annoying. At gains of +10dB and above the on-board RAD generates audible high freq. tone related to the sampling rate (~1/4 the sampling frequency) on the amplified output (headphones/speakers). A quick check revealed that the same tone is present on the analog output, 'though at considerably reduced level. Strange enough it's the first time I'm noticing it.
Has anybody experienced something like this before? If so, is there a solution?
It smells like a hw problem or a nasty driver/mixer "feature" (int overflow/aliasing/...).

I can provide free accounts to those who are building the nekoware on my Origin 2400 system (16 CPU, 8GiB mem). It's been idle for some time and it makes no sense keeping it this way.