nekonoko wrote: If someone can confirm that it still works as expected I'll move it to 'current'
confirmed.
new in beta:
neko_x264-0.50.564.tardist - H264/avc encoder
The collected works of schleusel - Page 2
confirmed.
new in beta:
neko_x264-0.50.564.tardist - H264/avc encoder
nekonoko wrote:new in beta:
neko_x264-0.50.564.tardist - H264/avc encoder
Wow, that sounds great - definitely will give it a try.
don't be too exited about it.. it seems to be quite a dog on mips, but still helpfull to have around for smaller things i guess
Although its much more comfortable to use it through ffmpeg or mencoder, so you can transcode from other codecs directly.
Any chance for even a rough build of mplayer for x264 playback in the near future? That's the only missing piece
Yes, i'll upload an initial neko_mplayer (and an overdue update to neko_ffmpeg) this week - doesn't make much sense to wait much longer
I did a few small changes to vo_sgi that i was hoping to get feedback for from vegac, but he seems to be a busy man currently - so i'll just leave those in for now, enough chances to revert things later if needed
I uploaded a very bare svn build (all external features disabled, only linked against system libs) two weeks ago, feel free to give it a try: http://www.kanera.de/mplayer-svn/
This one is built with the /opt/mplayer prefix so it will pick up the osd fonts and mplayer.conf of the old package if you have it installed. Just make sure to move the old codecs.conf out of the way.
nekonoko wrote: Doesn't like my h264 content much (lots of frame decoding errors)
ah.. yeah, it does that when it drops frames. Apparently thats normal, the h264 implementation isn't very robust wrt framedrop yet
Still works ok though, just bitches. To check if that is the cause you can try with -noframederop (kills a-v sync of course).
One way to speed up h264 decoding a bit on files that almost play well is to turn off deblocking with -lavdopts skiploopfilter=all (doesn't hurt quality with high quality h264 files). A little benchmark with a 848x480 h264 trailer thats just beyond trouble-free on the 600MHz Fuel:
codec only (no display/audio): -nosound -benchmark -quiet -vo null
with deblocking:
BENCHMARKs: VC: 27.245s VO: 0.014s A: 0.000s Sys: 0.182s = 27.442s
without deblocking (-lavdopts skiploopfilter=all):
BENCHMARKs: VC: 25.149s VO: 0.014s A: 0.000s Sys: 0.127s = 25.290s
with display and audio: -benchmark -quiet
with deblocking:
BENCHMARKn: disp: 791 (19.78 fps) drop: 148 (15%) total: 939 (23.48 fps)
without deblocking:
BENCHMARKn: disp: 840 (21.00 fps) drop: 99 (10%) total: 939 (23.47 fps)
So in this case it reduced framedrop from 15% to 10%, not impressive but it helps in those borderline cases.
testfile was: http://images.apple.com/movies/wb/the_fountain/the_fountain-tsr_h480p.mov , found in some thread on the mplayer devel mailinglist lately.
nekonoko wrote: Looks like I need to find a 700 or 800MHz CPU for my Fuel.
Get the 2 GHz one for proper 720p or (god forbid) 1080p playback
Well, i'm sure there is still a bit room for optimizations.. h264 doesn't go through any of the functions that dexter touched so far
nekonoko wrote:
Okay, figured out the Firefox-2.0 problems and new static MIPSpro build is in 'beta'. Better late than never
Brilliant! Works beautifully so far, thanks
squeen wrote: A weirdness though on IRIX & Linux mplayer playback of the .mp4 created with ffmpeg using HDTV 1280x720 sized frames. The playback window is stretched. xwininfo report 1536x720. Why? Quicktime plays it back at the proper aspect. Weird.
Hmm, do those files contain bogus aspect information for some reason? (Mplayer should print the aspect ratio it thinks the file has). You can use -noaspect to prevent mplayer from honoring such aspect information or -aspect to override it.
I doubt there is any chance to get 1920x1200 out of an O2. I built a 1680x1050 mode for O2 lately, as somebody requested one in a different thread but i have yet to get any feedback for it. I have no idea if it works as i don't have access to an O2 or a 1680x1050 display:
http://www.kanera.net/modes/crm/1680x1050_60-205bw.nfo
it is based on a similar mode i compiled for VPro before but i had to lower the TotalPixelsPerLine a bit or vfc would refuse to compile it for CRM at all. So if it works at all, its probably pretty close to what you can get out of the O2.
As for Octane, any VPro will happily do 1920x1200. V6 and V10 would have to run it at 8 bytes/pixel though, as it would need ~36 MB framebuffer at 16 bytes/pixel. At 8 bytes/pixel there should be ~10 MB left for textures, actually more than what is left at the usual 1280x1024 at 16 bytes/pixel..
Cheers,
Timo
http://www.kanera.net/modes/crm/1680x1050_60-205bw.nfo
it is based on a similar mode i compiled for VPro before but i had to lower the TotalPixelsPerLine a bit or vfc would refuse to compile it for CRM at all. So if it works at all, its probably pretty close to what you can get out of the O2.
As for Octane, any VPro will happily do 1920x1200. V6 and V10 would have to run it at 8 bytes/pixel though, as it would need ~36 MB framebuffer at 16 bytes/pixel. At 8 bytes/pixel there should be ~10 MB left for textures, actually more than what is left at the usual 1280x1024 at 16 bytes/pixel..
Cheers,
Timo
SGIFanLongTime wrote:
Ah I got it to load the file ! Just needed to rename .nfo to .vfo.
Ah, my fault then. For some reason i seemed to remember they were called .nfo on the O2.
Quote:
Display works, but when you try to move windows, or click on the toolchest it freaks out.
Well, it might well be the case that 1680x1050 is just asking to much of the O2. As i mentioned, i already had to trim it a bit to be able to compile it for O2 at all (see below)..
Quote:
Also looking for how the VFO was compiled that I tested previously.... Any details would be extremely helpful. thanks.
The easiest way to create generic modes is using the blocksync template as described in the vfc guide and some older forum threads. The resulting modes usually are ok for CRTs, for LCDs you might need to build a more specialized mode though. At this point you need to provide your own .vfs source file to be compiled. Thankfully, this can be pretty easy if you use an existing XFree/X.org modeline as a template. Lets use the above 1680x1050 mode as an example:
The mode was ment for a Samsung 205BW display. Asking google for a fitting modeline provided:
Code:
ModeLine "1680x1050" 146.8 1680 1784 1960 2240 1050 1053 1059 1089
See the two groups of 4 values each. These describe the horizontal and vertical field.
The .vfc listed in example 5-1 in the techpubs vfc guide can be used as a template to fill in the needed values based on the modeline. This is pretty straight forward:
FramesPerSecond is 60 as we want a 60hz mode
horizontal fields:
ActivePixelsPerLine is 1680
TotalPixelsPerLine is 2240
HorizontalFrontPorch is 1784-1680 = 104
HorizontalSync is 1960-1784 = 176
HorizontalBackPorch is 2240-1960 = 280
vertical fields:
ActiveLinesPerFrame is 1050
TotalLinesPerFrame is1089
VerticalFrontPorch is 1053-1050 = 3
VerticalSync is 1059-1053 = 6
VerticalBackPorch is 1089-1059 = 3
(VerticalFrontPorch, VerticalSync and VerticalBackPorch are reflected in the repeat counts in the Field specification in the .vfs)
To compile the resulting .vfs for an O2 you would use (assuming you named it 1680x1050_60.vfs):
Code:
vfc -c board=O2_Board.def,chip=O2_Chip.def -o 1680x1050_60.vfo 1680x1050_60.vfs
O2_Board.def and O2_Chip.def define the compilation rules for the O2 (they are located in /usr/gfx/ucode/vfc/rules)
In this case this fails with the following error:
Code:
Your value for TotalPixelsPerLine (2240) must not exceed the maximum of 2160.
So we're obviously hitting an O2 specific limit here. To make it compile i reduced the TotalPixelsPerLine to 2160 by reducing the HorizontalBackPorch to 200. The resulting source file is: http://www.kanera.net/modes/crm/1680x1050_60-205bw.vfs . This one was used to compile the mode you tested.
Hope this was of some help
Cheers,
Timo
subedai wrote:
Ive been curious if it is possible to get a 1600x1050 dell running on a octane V6 or would i be better off to fork out the extra couple of hundred for a 1600x1200 one?
unfortunately, V6 and V8 are a special case thanks to their pixelclock limitation (as discussed in many older threads). There is no chance to use 1680x1050 with those and 1600x1200 will only work if you find a display that will still sync at 70hz or higher on the analog port (60hz will not work)
V10 and V12 don't have that problem anymore..
SGIFanLongTime wrote:
So does that mean you build a 1600+ res wide screen driver for the V12? I have one of those boxes as well, would love to try to go wide screen on it...
Sure, V12 does 1680x1050 without a problem. I compiled two different 1680x1050 modes for Vpro some time ago:
http://www.kanera.net/modes/vpro/1680x1050_60.vfo was built for a Dell 2005FPW
http://www.kanera.net/modes/vpro/1680x1050_60-2.vfo was built for a Samsung 205TW
A 1920x1200 mode is already shipped with IRIX
Quote:
Also always wondered what happens when you plug in a dual head DVI add-on, I expected that you would automatically get enabled for the new resolutions but maybe that's a silly assumption for me....
The dual channel option is pretty much plug and play. You need special dual screen modes for it though. There are quite a few included with IRIX (see the 2@.. files in /usr/gfx/ucode/ODSY/vof). Dual Channel 1680x1050 won't be possible though - the width per channel needs to be a multiple of 64 in Dual Channel modes
Dual 1920x1200 (already included with IRIX) is not a problem though. I'm quite happy with dual 1600x1200
SGIFanLongTime wrote:
I can imagine how good the V12 will look at that rez with DVI on "30.
Hm, probably not too impressive..
Native resolution of the 30" is 2560x1600 (needs dual link DVI which no SGI provides) - using anything lower will be interpolated and look fuzzy, regardless of whether you are using DVI or analog..
SGIFanLongTime wrote:
wow extremely useful info to have since I haven't made my company fork out the cash yet for the 30 inch.... Do you know at what size monitors start requiring the dual link DVI ? Could I possibly get away with a 27? or would I have to scale back to a 24"
1920x1200 is the limit for single link DVI. Thats the native resolution of both the 24" and 27" screens, so which one you choose is purely a matter of taste: higher DPI (24") vs. larger size (27")
subedai wrote:
Ah so no 1680x1050 even if i go to 8bpp?
No
Any mode with a pixel clock between 109 and 193 MHz will simply be discarded by irix on v6 and v8 in my experience, so you can't even try to use it. The 1680x1050 mode is ~146 MHz.. right in the middle of that range
stuart wrote: (P.S. I notice that one of the available resolutions is 2@1920x1200 - does a 128Mb V12 really have enough memory to handle this resolution?
Sure, 2*1920*1200*16 bytes is "only" ~73 MB framebuffer too
It won't work in combination with the hardware accum buffer as the odyssey driver doesn't seem to like framebuffer + accum buffer + system buffer to approach 100MB but thats already the case with 2*1600*1200..
(P.P.S. At what resolution is dual-link DVI required? Does the V12 DCD option provide dual-link?)
It doesn't provide dual-link. 1920x1200 still works on single-link, for 2560x1600 (30") you'll need dual-link
loonvf wrote: CPU I already have and PSU comes from a PC.
Caution. This won't work without modifications. The Fuel does use an ATX PSU with EPS12V connector but the pinout is non-standard, see: http://forums.nekochan.net/viewtopic.php?f=3&t=10849&st=0&sk=t&sd=a&start=29
mia wrote: While I will be waiting for this new case, I plan to study the cooling part. I intend to replace the original heatsinks, I have not yet decided if this will go water cooling or air cooling.
Keep the environmental monitoring of the L1 controller in mind here..
You'll have to resemble the original cooling quite precisely (i.e. 6 fans with certain minimum rpm - see the list in the fuel hardware aggregator thread: http://forums.nekochan.net/viewtopic.php?f=3&t=9046 ) or you'll have to disable the monitoring if you want the machine to stay powered on for longer than 60 seconds
anotherlin wrote: However, how do I turn off L1's environmental monitoring during boot time ? I didn't have time to do much tests (got to go to work) but the Fuel shuts itself down during boot time auto-test.
Hmm, your replacement fan only has 56% of the throughput of the original fan - I suppose you are aware of that?
Anyway, I had a similar problem with the fan I currently use in the PSU. It is running too slow during boot time for the env monitoring to like it so the machine always powered off 60 seconds after power-on. I'm working around it by using an init script that switches off the env monitoring during shut-down and back on 5 minutes after booting. This will of course only work if the fan in question actually runs fast enough after that period and has the drawback that a dead fan will only be detected if the machine is booted into IRIX for at least those 5 minutes.
If you want to try this anyway, here is the script:
Code: Select all
#!/bin/sh
# Begin $rc_base/init.d/l1env
IS_ON=/etc/chkconfig
CONFIG=/etc/config
if $IS_ON verbose; then
ECHO=echo
else
# For a quiet startup and shutdown
ECHO=:
fi
case "$1" in
start)
if $IS_ON l1env; then
$ECHO "Starting L1 controller environmental monitoring in 5 minutes..."
/sbin/sh -c "sleep 300; /usr/sbin/l1cmd --scdev /hw/module/001c01/L1/controller env on"&
fi
;;
stop)
if $IS_ON l1env; then
$ECHO "Stopping L1 controller environmental monitoring!"
/usr/sbin/l1cmd --scdev /hw/module/001c01/L1/controller env off
fi
;;
restart)
$0 stop
sleep 1
$0 start
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
;;
esac
Save this script as /etc/init.d/l1env and make it executable:
Code: Select all
chmod +x /etc/init.d/l1env
Then create two symlinks to start it during boot (runlevel 2) and stop it during shutdown (runlevel 0):
Code: Select all
ln -s /etc/init.d/l1env /etc/rc0.d/K35l1env
ln -s /etc/init.d/l1env /etc/rc2.d/S95l1env
Finally, enable the script via chkconfig, so it will be executed on the next reboot:
Code: Select all
chkconfig -f l1env on
To set this up you'll need to be able to boot the machine first of course. So either put back the old fan to do so or use a serial cable to talk to the L1 directly and switch off the env monitoring without booting into IRIX.
This news bit
(german) talks about planned upgrades of the new northern german "HLRN-II" Altix installation - which currently consists solely of Altix ICE x86 clusters.
The interesting part is the second passage. It talks about two additional planned "Ultra Violet" SMP systems each consisting of 2176 CPUs (136 blades with two 8-core Nehalem-Xeons each) and 8.7 TB of memory in only five large nodes - using NUMALink 5
Wonder if this will mark the end of their IA64 lineup (wouldn't be all that surprising i suppose
) or if they'll offer both variants..
The interesting part is the second passage. It talks about two additional planned "Ultra Violet" SMP systems each consisting of 2176 CPUs (136 blades with two 8-core Nehalem-Xeons each) and 8.7 TB of memory in only five large nodes - using NUMALink 5
Wonder if this will mark the end of their IA64 lineup (wouldn't be all that surprising i suppose
) or if they'll offer both variants..
TeeTylerToe wrote: you've got core 2 xeons with 4 cores at 3GHz+ with I think 2 flop/cycle, or 14Gflop per socket.
Actually even 4 double precision FLOPs/cycle if you include the SIMD units i think (2 x87 + 2 SSE2/3), i.e. 48 GFLOPs/s theoretical peak for the 3GHz Quad Core.
Sorry, no chance
2560x1600_60hz means a pixel clock frequency of > 300 MHz, while the single-link DVI port on the V12 is limited to 165 MHz. Using a VGA adapter won't help either as the VPros in general are limited by a slow 220 MHz DAC. I doubt the 30" display would accept 2560x1600 on the analog port anyway though..
hmm.. It should theoretically be possible to produce a 2560x1600_30hz mode which would reduce the needed frequency to around 160 MHz, i.e. should even be possible through single-link DVI. But i'm almost certain the 30" display would refuse to accept that one
2560x1600_60hz means a pixel clock frequency of > 300 MHz, while the single-link DVI port on the V12 is limited to 165 MHz. Using a VGA adapter won't help either as the VPros in general are limited by a slow 220 MHz DAC. I doubt the 30" display would accept 2560x1600 on the analog port anyway though..
hmm.. It should theoretically be possible to produce a 2560x1600_30hz mode which would reduce the needed frequency to around 160 MHz, i.e. should even be possible through single-link DVI. But i'm almost certain the 30" display would refuse to accept that one
D-EJ915 wrote: If you can rotate the screens or use portrait resolutions with the DCD the Eizo 30" lets you split the screen in half and drive each side off a different input. Not sure if any other ones do that or not, I know the IBM 22" did something similar in one of the versions but each side would have been a 30" monitor...
Nice - didn't know there was a 30" that could be driven by two single-link channels.
That ridiculously high DPI IBM display (or the rebadged ViewSonic version) was actually supported on the Tezro. Only on the rackmount version though as it is driven by four single-link channels, i.e. you need dual V12 pipes each with the DCD in place
.. 3840x2400 on 22" - just sick
So i appears to be possible to produce such complex modes for the V12 - if you find somebody with the vfc skills to do so. I was even too stupid to build regular DCD modes when I tried it..
modology wrote: I dont quite get it. Does it mean I have to get the second V12 DCD in order to do so? You mentioned 3840x2400 on 22"-hmm....is it even possible?
Yes, you'd need two V12 boards and two DCD option boards to get the four (single-link) DVI outputs needed to drive the display. Each of these four channels would then provide one 960×2400 stripe or 1920×1200 tile which the display internally combines to 3840x2400:
http://en.wikipedia.org/wiki/IBM_T220/T221_LCD_monitors
As the desktop Tezro only supports one V12 board plus DCD for a maximum of two channels this combination is only possible in a dual module rackmount Tezro. And even if you have all that hardware, you'd likely still need SGI to set it up for you as the video mode files etc. needed for that aren't included in stock IRIX..
if you want an elegant solution and feel adventurous, you could try to get
MPD
working on IRIX - especially if you're planning to run the machine headless. I didn't try it on IRIX myself yet, so no idea if it will build and work cleanly.. it doesn't have direct support of irixal audio output, the libao support should hopefully do the trick though.
As for performance, there shouldn't be a problem - it doesn't seem to be any more demanding than a simple mpg123. I'm currently running it on an old IBM NetVista N2200 thin client connected to my hifi setup in the living room. It boots Debian off a 2GB compact flash card and mounts the audio collection on my file server via NFS (using a random USB wifi dongle for connectivity as i couldn't be bothered routing ethernet to that corner). It uses a lowly 233MHz Cyrix MediaGX CPU (shouldn't be much faster than your 200MHz R4400) and doesn't have any problems at all with mp3 (up to 320 kbit/s or vbr), ogg and FLAC..
There are loads of different frontends (console, GUI or web) for feeding it with playlists, I'm currently using Sonata and am quite happy with it.
As for performance, there shouldn't be a problem - it doesn't seem to be any more demanding than a simple mpg123. I'm currently running it on an old IBM NetVista N2200 thin client connected to my hifi setup in the living room. It boots Debian off a 2GB compact flash card and mounts the audio collection on my file server via NFS (using a random USB wifi dongle for connectivity as i couldn't be bothered routing ethernet to that corner). It uses a lowly 233MHz Cyrix MediaGX CPU (shouldn't be much faster than your 200MHz R4400) and doesn't have any problems at all with mp3 (up to 320 kbit/s or vbr), ogg and FLAC..
There are loads of different frontends (console, GUI or web) for feeding it with playlists, I'm currently using Sonata and am quite happy with it.
a fully equipped BlueGene/P rack (4096 PPC450 cores), which i suppose this concept is mostly targeted against, is rated at around 40kw too..
But i agree, this is obviously just vaporware for now.. and the gizmodo interpretation of it even more so
But i agree, this is obviously just vaporware for now.. and the gizmodo interpretation of it even more so
R-ten-K wrote: A fully loaded blue gene takes significantly more space than a 3U rack.
Obviously
But, as was pointed out, the SGI press release appears to be talking about 10k cores in a full rack, i.e. something comparable in size to the BlueGene rack. Not 10k cores in a single 3U module as the gizmodo bit claims..
JacquesT wrote: Anyway, I've download a teaser sample of a MP4 video file from here , but as soon as I play it back with mplayer I get garbled video, audio plays fine. I get video OK with the -vo gl or gl2 flags, but I end up with error messages about currupt frames, with serious frame drops.
the skewed display is a known problem with vo_sgi with many h.264 videos. You can work around it by using external colorspace conversion (-vf format=rgb24), which makes it essentially behave exactly like vo_gl2 on your VPro.
Any ideas? I can covert the video with mencoder to a .mov, but at 2fps its a bit barking to convert the whole thing...
OR is my box just too slow to play the file?
In short: yes
I tried it on my 600MHz Fuel and with disabled audio (i.e. without dropping frames) I get around 4fps (vs. 63fps on my laptop
) so as soon as you add audio it will drop just about everything. After converting it to Xvid4 the Fuel plays it without issues at around 50% CPU though, so your Octane should still do fine there.
JacquesT wrote: Will try the Xvid4 conversion. Did you use 'mencoder'?
no, i was lazy and used avidemux and the original libxvidcore on Linux. Using mencoder or ffmpeg (libavcodec) should work just fine too though..
mapesdhs wrote:Code: Select all
V: 189.3 1894/1894 70% 19% 0.0% 0 0 0%
- current video position: 189.3 seconds
- 1894 of 1894 frames played
- 70% CPU usage for decode
- 19% CPU usage for display
- 0% CPU usage for audio playback
- 0 frames dropped
- no automatic post processing done
- 0% cache fill
if audio is enabled, even more information is shown. Here is the full list:
http://www.mplayerhq.hu/DOCS/HTML/en/faq.html#id2811815
The CPU usage for display with vo_null is because by adding -vf format=rgb24 you enforced colorspace conversion even without displaying anything.
If you really want to benchmark the codec only, skip that one.
These percentage scores are momentary values, the -benchmark output gives overall results instead:
Code: Select all
BENCHMARKs: VC: 132.943s VO: 36.990s A: 0.000s Sys: 1.198s = 171.131s
BENCHMARK%: VC: 77.6848% VO: 21.6152% A: 0.0000% Sys: 0.7000% = 100.0000%
- 132.943s for decode
- 36.990s for display
- 0.000s for audio playback
- 1.198s used by the OS
- 171.131s total
i.e. 1894 frames / 171 seconds = 11 fps for decoding and colorspace conversion but without video and audio playback.
The second line gives percentage scores of the same.
The command I used to play the file was:
Code: Select all
mplayer -vo gl2 -vf format=RGB24 -osdlevel 0 -benchmark -nosound -vo null speeder_teaser.mp4
The -vo gl2 is overridden by the -vo null, the -vf format=rgb24 enforces the extra colorspace conversion (with gl2 this shouldn't be needed anyway. I just mentioned it as a workaround for the display problem with vo_sgi mentioned above). For comparison, here are the numbers from my Fuel:
- decode only (-osdlevel 0 -benchmark -nosound -vo null):
Code: Select all
BENCHMARKs: VC: 193.406s VO: 0.041s A: 0.000s Sys: 0.989s = 194.435s
BENCHMARK%: VC: 99.4706% VO: 0.0210% A: 0.0000% Sys: 0.5084% = 100.0000%
= 9.7 fps. As you can see, without the -vf format=rgb24 filter, nearly no time is spent for VO.
- decode + colorspace conversion (added -vf format=rgb24, same as you did):
Code: Select all
BENCHMARKs: VC: 195.205s VO: 56.811s A: 0.000s Sys: 1.071s = 253.086s
BENCHMARK%: VC: 77.1297% VO: 22.4473% A: 0.0000% Sys: 0.4230% = 100.0000%
= 7.5 fps. So I assume you tested on a 700MHz machine?
- decode + gl2 display (-vo gl2 -osdlevel 0 -nosound -benchmark):
Code: Select all
BENCHMARKs: VC: 194.845s VO: 258.793s A: 0.000s Sys: 1.383s = 455.021s
BENCHMARK%: VC: 42.8210% VO: 56.8750% A: 0.0000% Sys: 0.3040% = 100.0000%
= 4.2 fps..
And the inevitable comparison.. decode only on a 1.8GHz Core2Duo (Linux):
Code: Select all
BENCHMARKs: VC: 17.044s VO: 0.007s A: 0.000s Sys: 0.290s = 17.341s
BENCHMARK%: VC: 98.2833% VO: 0.0417% A: 0.0000% Sys: 1.6750% = 100.0000%
= 109 fps
H.264 is really not the stuff to feed the irix mplayer with..
tillin9 wrote: Is there a SCSI to SATA bridge known to work in SGIs? Most (affordable) SSDs have just a normal SATA interface.
I'd expect the acard bridges to work just fine (didn't test this myself though). There is even a SCA version designed to take a 2.5" drive , which is what you'd need to fit it internally in an O2.
P.S. I want to put a nice cheap 128GB MLC SSD -http://www.newegg.com/Product/Product.aspx?Item=N82E16820231221 in my O2.
be aware that there seem to be some quite dramatic random write performance problems with the current "cheap" MLC drives though - the new (and much more expensive) intel MLC drives being the exception: http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=1
sybrfreq wrote: mmm... that black one is HOT
yeah, I was going to mention that i'd still prefer that T60 but was fearing i might get lynched
bri3d wrote: So basically the Fuel V12 is for Fuel, and not much else.
and Tezro..
two HD15 inputs (switchable), no 13W3..
joerg wrote: Well, the following mirros are (currently?) out of orders
1. de.mirror.nekoware.net (Dennis)
that one is back online and up to date again now.. thanks dennis!
Sorry for digging out this old thread but I could use one or two pairs of o300 rails too (preferably in Europe).
Did anybody get a chance to try those SUN rails?
Did anybody get a chance to try those SUN rails?