BUILD Mini-ITX C226 Haswell build

[cyberjock]

Fun fact about the current XBMC build... it won't buffer the video unless the network share is FTP.

If that's true that is absolutely pathetic.

 

[underpickled]

If that's true that is absolutely pathetic.

So FTP and HTTP are cached (meant to say "cached" not "buffered")... it will play video over the other shares, but since it won't cache, it's almost guaranteed to stutter. It only applies to v12, so presumably it will be changed in v13, but v13 has not been 100% finalized yet.

http://wiki.xbmc.org/index.php?title=HOW-TO:Modify_the_video_cache

Not looking to go off thread topic.

 

[jyavenard]

Fun fact about the current XBMC build... it won't buffer the video unless the network share is FTP.

what does that even mean?

what would "buffering" would achieve with a media player?

XBMC uses ffmpeg libs (libavcodec, libavformat, libavutil) ; ffmpeg typically access the files by blocks; the size of a block depends on the media format. And that's all there is. At best you get 2-3s of buffer (unless you use HTTP Live Streaming). Internally, the media player has no idea what the underlying file system you have: CIFS, FTP, NFS, local as the OS will mount the drive as a block device and it's completely abstracted.

However, using FTP as underlying connection is a very poor choice. Depending on the media being played, seeking may be required. And FTP doesn't allow optimal seeking: NFS, CIFS or local are a *much* better choice.

For container like MPEG-TS (or PS) there's no seek required: so ftp would be fine. But a container like mp4 (like videos created by an iphone), the codec and format information is located at the end of the file; so it needs to seek a fair bit. Playing those over FTP would give shocking experience. It would be even worse with some AVI file. The way the information is interleaved, you need one seek for every read.

Edit: I just read your later message. Even caching wouldn't help for some container when used over FTP; you would have to "cache" the entire file to get okay performance.
http is better (typically used over webdav), but it still has a lot of overhead to perform seeks.

those two methods of accessing files (HTTP, FTP) were never designed to be accessed as random block device. Any containers designed with streaming in mind will work okay over them, others won't

 

[underpickled]

what does that even mean?

what would "buffering" would achieve with a media player?

XBMC uses ffmpeg libs (libavcodec, libavformat, libavutil) ; ffmpeg typically access the files by blocks; the size of a block depends on the media format. And that's all there is. At best you get 2-3s of buffer (unless you use HTTP Live Streaming). Internally, the media player has no idea what the underlying file system you have: CIFS, FTP, NFS, local as the OS will mount the drive as a block device and it's completely abstracted.

However, using FTP as underlying connection is a very poor choice. Depending on the media being played, seeking may be required. And FTP doesn't allow optimal seeking: NFS, CIFS or local are a *much* better choice.

For container like MPEG-TS (or PS) there's no seek required: so ftp would be fine. But a container like mp4 (like videos created by an iphone), the codec and format information is located at the end of the file; so it needs to seek a fair bit. Playing those over FTP would give shocking experience. It would be even worse with some AVI file. The way the information is interleaved, you need one seek for every read.

I'm going to go ahead and assume you've never tried this with XBMC, or read my follow up with a link to the XBMC documentation. Go try streaming HD video over wifi with NFS on XBMC v12 and let me know how it works out. I switched it to FTP after reading the link in my last post and now it works with no problems.

Sent from my Galaxy Nexus using Tapatalk 2

 

[jyavenard]

I'm going to go ahead and assume you've never tried this with XBMC, or read my follow up with a link to the XBMC documentation. Go try streaming HD video over wifi with NFS on XBMC v12 and let me know how it works out. I switched it to FTP after reading the link in my last post and now it works with no problems.

when it comes to mythtv, xbmc or ffmpeg: I am fairly "knowledgeable" :)

Increasing the "cache" and using FTP only allows to do what I describe: you pretty much read a much bigger chunk of files in memory: this has the downside that it may take a while for playback to start, to get any proper response when you decide to seek within the file etc...
And as I wrote, with some container, the only way it would work properly with FTP would be to read the entire file in RAM first. Hardly an optimised fashion.

Those are just workarounds; you'd be better of solving the actual problem.

 

[cyberjock]

And the discussion over this caching is over. If either of you want to continue this discussion I'll pull these posts out and make a new thread out of them. :)

 

[Starpulkka]

Im curious is ipmi still vulnerable to easy access? As in this topic firstpage Mobo: ASRock E3C226D2I LGA 1150 Mini-ITX Edit: ok thanks for info djk29a

 

[djk29a]

I got myself the C224 version of the ASrock board and I was wondering if anyone else is having problems with getting a DHCP address upon bootup with this motherboard. I have to hit a shell at the console, see that igb0 and igb1 are there in dmesg, but there's definitely no IP. dhclient igb0 takes about 14 seconds to get the static DHCP address. I've tried messing with DHCP timeouts via dhclient.conf changes in a couple places, but nothing's seeming to help. It may be unrelated, but FreeNAS isn't autostarting my jails either, which means every time I reboot, I have to run dhclient, start all my jails, and remount all the shared mount points (I have 14 to deal with) via the GUI turning it off first for each one because FreeNAS thinks they were mounted (they weren't). So all that seems to be a cascading failure from not being able to get an IP address upon boot.

I used this same network setup a while ago with a different motherboard (Gigabyte GA-H87N-WIFI) with a slightly NEWER Intel NIC (i217) that didn't have this DHCP problem, so I have my doubts that there's a problem with the network.

I'm trying to figure out if I'm having a problem with the bridge I have setup to my FIOS router or if I messed up the hardware somehow (I've got a dangerously cramped and awkward area for the motherboard and accidentally burned a board out in the process of getting it mounted and tested). This seems to happen whatever I'm hooked up to.

 

[djk29a]

Im curious is ipmi still vulnerable to easy access? As in this topic firstpage Mobo: ASRock E3C226D2I LGA 1150 Mini-ITX

To be fair, IPMI tends to be insecure out of the box somewhat out of deployment necessities (bare metal provisioning for VM farms, for example, oftentimes prefer defaults so that they can be secured automatically) and so needs to be secured later not by default (this is admittedly a legitimate vulnerability window similar to how many systems get compromised within minutes after a basic install). Bruce Schneier wrote a brief write-up of some issues a while ago (including the really scary one of how root passwords are oftentimes stored in plaintext on BMCs) https://www.schneier.com/blog/archives/2013/01/the_eavesdroppi.html

The risks with IPMI can be mitigated through the same general procedures as any other network though. Use physical separation, use certs, encryption everywhere, VLANs, endpoint security, IP / MAC restrictions, etc.

 

[underpickled]

Update: Upgraded to the newest BIOS (1.70) and all's well.

 

[Gonzo]

Has anybody tried adding more than 15 GB of RAM on this board?

 

[MtK]

you mean 16, right?

 

[Gonzo]

Oops!, Yes, 16 GB

 

[djk29a]

There's only 2 DIMM slots so you'd need 16GB DIMMs. I'm not even aware that those exist in UDIMM variants but they definitely exist for RDIMMs.

 

[BrandonS]

I have built my FreeNAS box with this board using the parts below. One thing I finally got confirmation for in the manual was it wanted unbuffered memory. It also came with 6 SATA3 cables (2 right angle longer, 4 straight of varying lengths). Worked well in my LIAN LI case but I would recommend getting four extra right angle cables. I upgraded to 1.70, disabled USB3.0, turned on S.M.A.R.T., and run in AHCI. The one problem I had is when it stopped posting after canceling the first dialog of an IPMI firmware update. I had to pull the power for about a minute to get it to boot again.

So far the system without drives is idling at 31Watts and goes to about 41 Watts on boot. I'm happy I went with the 35w Haswell CPU. I will check it out again once I add my drives and put a load on the system. Overall, it looks like it is going to be pretty nice.

x1 LIAN LI PC-Q25B Black Aluminum Mini-ITX Tower Computer Case
Item #: N82E16811112339

x1 SeaSonic SS-300ES Bronze 300W ATX12V V2.3 80 PLUS BRONZE Certified Active PFC Power Supply - OEM
Item #: N82E16817151085

x1 ASRock E3C226D2I Mini ITX Server Motherboard
Item #:N82E16813157466

x1 Intel Core i3-4130T 2.9GHz LGA 1150 Dual-Core Desktop Processor
Item #:N82E16819116947

x2 Kingston 8GB 240-Pin DDR3 SDRAM Server Memory w/TS Model KVR16E11/8
Item #:N82E16820239370

x1 SanDisk Cruzer Fit 4GB USB 2.0 Flash Drive
Item #:N82E16820171586

 

[underpickled]

Oops!, Yes, 16 GB

The comment below is probably the biggest obstacle... but also I'm not sure if the board supports 16GB modules.

There's only 2 DIMM slots so you'd need 16GB DIMMs. I'm not even aware that those exist in UDIMM variants but they definitely exist for RDIMMs.

Beyond the availability question, it's worth asking why you would put 32GB of RAM in a mITX board. Either you need deduplication (at the recommended level of 5GB RAM per 1 TB of drive space, you could really do 6 TB of space at most), or you are going to have well over 16TB of space, in which case a mITX chassis is not likely to fit that many drives unless you buy 6x 4TB drives.

Just as one data point, my 6x 3TB drive setup (in RAIDZ2, about 11 TB of space) runs without any issue on 16GB of RAM, and RAM is not even close to a limiting factor. I also run a subsonic server on it which uses some RAM, but RAM is still not the bottleneck. If you really need 32 GB of RAM, I would suspect that mITX is most likely not necessary or even preferable to your application. Just my 2 cents.

 

[cyberjock]

Exactly what the_tox said. Buy physically small and it comes with limitations. Don't like it, don't buy small stuff and complain about it. ;)

Now if you'll excuse me I'll go play with my ATX sized motherboard as I never find size matters. That's even what my ex-girlfriends have said. ba-dum-tss!

 

[Richman]

Point taken. I'm not buying any used RAM unless it's a significant enough discount. However from the looks of it even used Unbuffered ECC RAM is very hard to come by so I'll probably wind up spending the $170 on 2x8GB sticks.

I was under the understanding or maybe misunderstanding that RAM that is ECC is Buffered hence the buffer is the ECC and non-ECC us unbuffered. I have never heard of unbuffered ECC RAM.

 

[fracai]

http://www.kingston.com/us/support/technical/valueram.aspx?questionid=148&afmid=41239

 

[cyberjock]

Buffering has nothing to do with ECC.

Sent from my DROID BIONIC using Tapatalk