User avatar
GTR2Fan
Posts: 1601
Joined: Sun Feb 23, 2014 9:20 pm
Location: South East UK

Re: Overclocking

Tue Jan 26, 2016 12:31 pm

Wow! Do any of these in particular equate to the CAS# Latency, RAS# to CAS#, RAS# Recharge and Cycle Time settings a person accustomed to overclocking PC RAM would be more used to seeing and playing with, or am I way off field here?

If this turns out to be the case, I might settle for 500MHz (or less) at tighter timings to see if that improves memory bandwidth. :)
Pi2B Mini-PC/Media Centre: ARM=1GHz (+3), Core=500MHz, v3d=500MHz, h264=333MHz, RAM=DDR2-1200 (+6/+4/+4+schmoo). Sandisk Ultra HC-I 32GB microSD card on '50=100' OCed slot (42MB/s read) running Raspbian/KODI16, Seagate 3.5" 1.5TB HDD mass storage.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5372
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Overclocking

Tue Jan 26, 2016 12:34 pm

No, these number are more analogue drive strengths and delay numbers:

Code: Select all

   int8_t  dphy_drive_level;    // 4..0 -> 34R,40R,48R,60R,80R
   int8_t  aphy_drive_level;    // 4..0 -> 34R,40R,48R,60R,80R
   int8_t  dram_drive_level;    // 4..-1 -> 34R,40R,48R,60R,80R,120R

   uint8_t dphy_lpwr_rx;        // Non-zero for LPWR_RX in DPHY
   uint8_t aphy_lpwr_rx;        // Non-zero for LPWR_RX in APHY

   int8_t dll_offset_rd_n;      // DLL offset schmoo: Low phase Read
   int8_t dll_offset_rd_p;      // DLL offset schmoo: High phase Read
   int8_t dll_offset_wr;        // DLL offset schmoo: DQ/DQS Write
   int8_t dll_offset_addr;      // DLL offset schmoo: Address/command

User avatar
GTR2Fan
Posts: 1601
Joined: Sun Feb 23, 2014 9:20 pm
Location: South East UK

Re: Overclocking

Tue Jan 26, 2016 12:37 pm

Cool. Thanks for being so open and helpful. This is information I've never seen here or anywhere else before. :)

EDIT: Removed misleading edits relating to config.txt invocation (thanks guys) as this doesn't work. All previous testing gave good results for this system as stability data collated before my silly faux-pas was very promising. Now exploring in the 575 to 600MHz region. :oops:
Last edited by GTR2Fan on Wed Jan 27, 2016 8:09 am, edited 2 times in total.
Pi2B Mini-PC/Media Centre: ARM=1GHz (+3), Core=500MHz, v3d=500MHz, h264=333MHz, RAM=DDR2-1200 (+6/+4/+4+schmoo). Sandisk Ultra HC-I 32GB microSD card on '50=100' OCed slot (42MB/s read) running Raspbian/KODI16, Seagate 3.5" 1.5TB HDD mass storage.

jahboater
Posts: 4843
Joined: Wed Feb 04, 2015 6:38 pm

Re: Overclocking

Tue Jan 26, 2016 11:27 pm

I added those lines to config.txt with your suggested values and I'm stable at
Did you mean config.txt? It looked to me like /etc/rc.local might be the best place for vcgencmd.

milhouse
Posts: 641
Joined: Mon Jan 16, 2012 12:59 pm

Re: Overclocking

Tue Jan 26, 2016 11:42 pm

jahboater wrote:
I added those lines to config.txt with your suggested values and I'm stable at
Did you mean config.txt? It looked to me like /etc/rc.local might be the best place for vcgencmd.
Indeed, I don't think there's (currently) a method to set schmoo in config.txt.

milhouse
Posts: 641
Joined: Mon Jan 16, 2012 12:59 pm

Re: Overclocking

Wed Jan 27, 2016 1:04 am

When using default schmoo, my max stable sdram is 530/+4 (or +5 with an extra margin of safety).

These are my schmoo results for 600/+8 when running "memtester 850":

Code: Select all

FAIL: schmoo=2,3,2,0,0,-2,-2,-2,-10
FAIL: schmoo=3,3,2,0,0,-2,-2,-1,-10
FAIL: schmoo=4,3,2,0,0,-2,-2,-2,-10
FAIL: schmoo=4,3,2,0,0,-2,-2,-1,-10
FAIL: schmoo=4,3,2,0,0,-2,-2,-0,-10
PASS: schmoo=4,3,2,0,0,-2,-2,-0,-10 (3 successful passes, no failures)
FAIL: schmoo=3,3,2,0,0,-2,-2,-0,-10
So for me, schmoo 4/0 seems to be the optimal 600MHz setting.

Now to start winding down the over_voltage_sdram... memtester has succesfully completed a run with +7, and once I settle on a configuration I'll leave it running memtester overnight.

Unfortunately the Pi2 doesn't always boot with sdram_freq=600 and the default 2/-2 schmoo, so there'd need to be a way to configure schmoo in config.txt for this to be reliable.

Or perhaps an automatic solution is possible (ie. relax schmoo settings if sdram_freq > 500?)

In case anyone is wondering (like I did) what a schmoo is, I'm assuming it's a variation of Shmoo plot.

User avatar
GTR2Fan
Posts: 1601
Joined: Sun Feb 23, 2014 9:20 pm
Location: South East UK

Re: Overclocking

Wed Jan 27, 2016 7:30 am

jahboater wrote:Did you mean config.txt? It looked to me like /etc/rc.local might be the best place for vcgencmd.
D'oh! That would explain why, despite hours of repeatable testing yesterday with different values, instability kicked in with previously stable values when I moved to attempted invocation via config.txt then. Oh well, at least all of the data I collated for this system was accurate up until that point. Thank you. :oops:

EDIT: Removed misleading information from previous post to avoid confusing others.

EDIT2: Summarising the last ~15 hours of exploration and testing - schmoo=3, 3, 2, 0, 0, -2, -2, -1, -10 with over_voltage_sdram_p=5 with _i=1 and _c=1 (so all just 25mV higher than the current default auto) seems to be completely stable so far for me at 550MHz. No amount of schmoo or voltage tweaking seems to get me stable much beyond 550MHz, but I'll keep exploring for a while. Note: This is with dom's firmware_pvt2 fix.

EDIT3: Retiring from testing for now as my old 5V 3A fixed-voltage switch-mode power supply is dipping just low enough to trigger low voltage warnings with my current overclocking settings under heavy system-wide loading. It's already directly wired to the power pins on the GPIO header, so there's nothing else I can do about it right now. I wouldn't be happy submitting further claims regarding instability when my power source is known to be borderline.
Pi2B Mini-PC/Media Centre: ARM=1GHz (+3), Core=500MHz, v3d=500MHz, h264=333MHz, RAM=DDR2-1200 (+6/+4/+4+schmoo). Sandisk Ultra HC-I 32GB microSD card on '50=100' OCed slot (42MB/s read) running Raspbian/KODI16, Seagate 3.5" 1.5TB HDD mass storage.

milhouse
Posts: 641
Joined: Mon Jan 16, 2012 12:59 pm

Re: Overclocking

Sat Jan 30, 2016 4:39 pm

I settled on 600MHz with over_voltage_sdram=5 and schmoo=4/0 (with disable_pvt=1, this is with latest release firmware not the custom firmware). I ran memtester 850 for many hours without failure, and played several hours worth of video (including HEVC) without any issue. Overclocking sdram has definitely helped HEVC playback, with some 1080p HEVC material that stuttered at 450MHz now playing smoothly (OpenELEC/Kodi 17).

Configuring schmoo in OpenELEC has to be done in autostart.sh, which unfortunately makes upgrading impossible - the OpenELEC upgrade takes place with sdram @ 600MHz and default 2/-2 shcmoo, which is unstable, and results in data corruption (incorrect md5) and occasional lock ups. It's therefore necessary to disable the sdram overclock, perform the upgrade and then reinstate the sdram overclock... :(

As I upgrade daily for now I've configured a 530MHz sdram overclock that works with default schmoo.

drnjstj
Posts: 3
Joined: Sun Jan 31, 2016 11:43 am

Re: Overclocking

Sun Jan 31, 2016 11:47 am

@milhouse.

Excuse my ignorance, could you please tell what i should put in the autostart.sh and the config.txt to get this increased speed?

These is my current stable setup in config.txt:
arm_freq=1100
core_freq=550
sdram_freq=530
over_voltage_sdram=4
over_voltage=4
force_turbo=1

milhouse
Posts: 641
Joined: Mon Jan 16, 2012 12:59 pm

Re: Overclocking

Sun Jan 31, 2016 12:58 pm

drnjstj wrote:@milhouse.

Excuse my ignorance, could you please tell what i should put in the autostart.sh and the config.txt to get this increased speed?

These is my current stable setup in config.txt:
arm_freq=1100
core_freq=550
sdram_freq=530
over_voltage_sdram=4
over_voltage=4
force_turbo=1
I added:

Code: Select all

echo powersave >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
vcgencmd schmoo 4 3 2 0 0 -2 -2 0 -10
echo ondemand >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
to /storage/.config/autostart.sh but this approach has significant drawbacks and you should wait until schmoo is supported in config.txt - the "vcgencmd schmoo" command is really only suitable for testing/experimentation, and not in a "production" environment.

Also note that the above code won't work while you are using force_turbo=1 as it won't be possible to force an sdram frequency change. So again, wait for the updated firmware with schmoo support.

jahboater
Posts: 4843
Joined: Wed Feb 04, 2015 6:38 pm

Re: Overclocking

Sun Jan 31, 2016 1:12 pm

I added vcgencmd only, to /etc/rc.local.
I don't use force turbo, so I think the ondemand governor will change the frequencies the first time you run a cpu intensive command (and if you never run such a command, you don't need the overclock!)

milhouse
Posts: 641
Joined: Mon Jan 16, 2012 12:59 pm

Re: Overclocking

Sun Jan 31, 2016 1:21 pm

The thing is, if you need "vcgencmd schmoo" to make your RAM stable, it's entirely possible the system won't make it as far as /etc/rc.local or /storage/.config/autostart.sh etc. before crashing due to sdram issues...

User avatar
GTR2Fan
Posts: 1601
Joined: Sun Feb 23, 2014 9:20 pm
Location: South East UK

Re: Overclocking

Sun Jan 31, 2016 1:27 pm

drnjstj wrote:These is my current stable setup in config.txt:
arm_freq=1100
core_freq=550
sdram_freq=530
over_voltage_sdram=4
over_voltage=4
force_turbo=1
I have my doubts that your overclock is stable. How are you testing stability?
Pi2B Mini-PC/Media Centre: ARM=1GHz (+3), Core=500MHz, v3d=500MHz, h264=333MHz, RAM=DDR2-1200 (+6/+4/+4+schmoo). Sandisk Ultra HC-I 32GB microSD card on '50=100' OCed slot (42MB/s read) running Raspbian/KODI16, Seagate 3.5" 1.5TB HDD mass storage.

jahboater
Posts: 4843
Joined: Wed Feb 04, 2015 6:38 pm

Re: Overclocking

Sun Jan 31, 2016 1:39 pm

The thing is, if you need "vcgencmd schmoo" to make your RAM stable, it's entirely possible the system won't make it as far as /etc/rc.local or /storage/.config/autostart.sh etc. before crashing due to sdram issues...
Agreed.
The thermal inertia of a heatsink might help during the boot.

drnjstj
Posts: 3
Joined: Sun Jan 31, 2016 11:43 am

Re: Overclocking

Sun Jan 31, 2016 2:04 pm

GTR2Fan wrote:
drnjstj wrote:These is my current stable setup in config.txt:
arm_freq=1100
core_freq=550
sdram_freq=530
over_voltage_sdram=4
over_voltage=4
force_turbo=1
I have my doubts that your overclock is stable. How are you testing stability?
I've used the above with sdram_freq=483 for at least half a year stable in real world usage. With the new firmware sdram_freq=530 is stable. Tried it from yesterday. Watched around 4 hours of video so far, works great so far.

drnjstj
Posts: 3
Joined: Sun Jan 31, 2016 11:43 am

Re: Overclocking

Sun Jan 31, 2016 3:33 pm

milhouse wrote:
drnjstj wrote:@milhouse.

Excuse my ignorance, could you please tell what i should put in the autostart.sh and the config.txt to get this increased speed?

These is my current stable setup in config.txt:
arm_freq=1100
core_freq=550
sdram_freq=530
over_voltage_sdram=4
over_voltage=4
force_turbo=1
I added:

Code: Select all

echo powersave >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
vcgencmd schmoo 4 3 2 0 0 -2 -2 0 -10
echo ondemand >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
to /storage/.config/autostart.sh but this approach has significant drawbacks and you should wait until schmoo is supported in config.txt - the "vcgencmd schmoo" command is really only suitable for testing/experimentation, and not in a "production" environment.

Also note that the above code won't work while you are using force_turbo=1 as it won't be possible to force an sdram frequency change. So again, wait for the updated firmware with schmoo support.
Thanks. I will wait as you suggested.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5372
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Overclocking

Mon Feb 01, 2016 8:59 pm

Latest rpi-update firmware has a config.txt option to set the sdram schmoo before kernel boots.

This has new config.txt option sdram_schmoo.

The settings are packed together. Basically each nibble except the first is a 4-bit signed offset to the current settings.
To squeeze them in, entries 4 and 5 are streamed differently as they are just boolean.

In code:

Code: Select all

     char str[32];
     #define SE(x, n) ((x) << (4*(n)) >> 28)
     int i, len=0;
     for (i=0; i<9; i++) {
       int v = 0;
       if (i < 3)
         v = SE(c_schmoo, i+1);
       else if (i==3)
         v = (c_schmoo >> 29) & 1;
       else if (i==4)
         v = (c_schmoo >> 28) & 1;
       else
         v = SE(c_schmoo, i-1);
       len += sprintf(str+len, "%d,", v);
     }
These are the structure elements:

Code: Select all

   int8_t  dphy_drive_level;    // 4..0 -> 34R,40R,48R,60R,80R
   int8_t  aphy_drive_level;    // 4..0 -> 34R,40R,48R,60R,80R
   int8_t  dram_drive_level;    // 4..-1 -> 34R,40R,48R,60R,80R,120R

   uint8_t dphy_lpwr_rx;        // Non-zero for LPWR_RX in DPHY
   uint8_t aphy_lpwr_rx;        // Non-zero for LPWR_RX in APHY

   int8_t dll_offset_rd_n;      // DLL offset schmoo: Low phase Read
   int8_t dll_offset_rd_p;      // DLL offset schmoo: High phase Read
   int8_t dll_offset_wr;        // DLL offset schmoo: DQ/DQS Write
   int8_t dll_offset_addr;      // DLL offset schmoo: Address/command
So, Milhouse's favoured settings:

4,3,2,0,0,-2,-2,-0,-10

is a +2 on first and a +2 on penultimate. That would be encoded as:

sdram_schmoo=0x02000020

If you wanted to also make last parameter -11, then that would be -1 and:

sdram_schmoo=0x0200002f

User avatar
GTR2Fan
Posts: 1601
Joined: Sun Feb 23, 2014 9:20 pm
Location: South East UK

Re: Overclocking

Wed Feb 03, 2016 2:40 pm

Thanks for this. :)

I'm back with the Pi2B running from its own dedicated adjustable buck converter feeding exactly 5.1V (only dropping by around 10mV under heavy CPU/GPU loads) to the power pins on the GPIO header, so I feel more confident about posting results now.

A multitude of settings have been tested here but, in summary, running the latest rpi-update firmware with the following in config.txt is perfectly stable on this particular Pi2B both in memtester (passed 8 runs on 700MB) and running Quake Darkplaces at 1920x1080 for 1 hour.

Code: Select all

sdram_freq=600
sdram_schmoo=0x02000020
over_voltage_sdram_p=6
over_voltage_sdram_i=4
over_voltage_sdram_c=4
It's actually stable a few MHz higher than this, but I've backed it off a little to give the overclock some headroom. This is as high as I can go without going crazy on the voltages, and I'm delighted to have got as far as I have, especially as I was stuck at 475MHz until very recently. :P
Pi2B Mini-PC/Media Centre: ARM=1GHz (+3), Core=500MHz, v3d=500MHz, h264=333MHz, RAM=DDR2-1200 (+6/+4/+4+schmoo). Sandisk Ultra HC-I 32GB microSD card on '50=100' OCed slot (42MB/s read) running Raspbian/KODI16, Seagate 3.5" 1.5TB HDD mass storage.

jahboater
Posts: 4843
Joined: Wed Feb 04, 2015 6:38 pm

Re: Overclocking

Wed Feb 03, 2016 11:09 pm

Hi Dom,
Thanks for doing all this, its really appreciated.
Interesting. I've done some digging and found the part of disable_pvt that seems to help. Can you test this firmware:
https://dl.dropboxusercontent.com/u/366 ... e_pvt2.zip
Does this firmware version from rpi-update also include the above disable_pvt related fix?

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5372
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Overclocking

Wed Feb 03, 2016 11:12 pm

jahboater wrote:Does this firmware version from rpi-update also include the above disable_pvt related fix?
Yes. If sdram_freq>450 on Pi2 we disable the part of PVT that caused overclock issues,
and we also bump over_voltage_sdram_p to 2 which helps a little. You may want to bump that voltage a little more if you are going above 500.

mathboy4life
Posts: 197
Joined: Fri Jan 08, 2016 7:29 pm

Re: Overclocking

Thu Feb 04, 2016 2:57 am

Dom is this code c++ it hurts my brain :lol:

Code: Select all

  char str[32];
     #define SE(x, n) ((x) << (4*(n)) >> 28)
     int i, len=0;
     for (i=0; i<9; i++) {
       int v = 0;
       if (i < 3)
         v = SE(c_schmoo, i+1);
       else if (i==3)
         v = (c_schmoo >> 29) & 1;
       else if (i==4)
         v = (c_schmoo >> 28) & 1;
       else
         v = SE(c_schmoo, i-1);
       len += sprintf(str+len, "%d,", v);
     }

jahboater
Posts: 4843
Joined: Wed Feb 04, 2015 6:38 pm

Re: Overclocking

Thu Feb 04, 2016 12:46 pm

Yes. If sdram_freq>450 on Pi2 we disable the part of PVT that caused overclock issues,
and we also bump over_voltage_sdram_p to 2 which helps a little. You may want to bump that voltage a little more if you are going above 500.
It does work perfectly, rock solid. Thanks again!

Perhaps the raspi-config overclock menu should now have some more entries for the Pi2 ...

milhouse
Posts: 641
Joined: Mon Jan 16, 2012 12:59 pm

Re: Overclocking

Thu Feb 04, 2016 5:00 pm

Here's a Python script, schmoo.py, that can be used to convert between the encoded and plain schmoo formats:

Code: Select all

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import sys

default = [2,3,2,0,0,-2,-2,-2,-10]

def SE(x, n):
  r = (((x << (4*n)) & 0xffffffff) >> 28)
  return (r - 16) if r >= 8 else r

def ES(x, n):
  y = (x + 16) if x >= 8 else x
  return ((y & 0xf) << 28) >> (4*n)

# schmoo = 0x0200002f
def encode_schmoo_offsets(schmoo):
  i = 0
  s1 = ""
  while i < 9:
    if i < 3:
      v = SE(schmoo, i+1)
    elif i == 3:
      v = (schmoo >> 29) & 1
    elif i == 4:
      v = (schmoo >> 28) & 1
    else:
      v = SE(schmoo, i-1)
    s1 += "%d," % v
    i += 1

  i = 0
  s2 = ""
  for x in s1[:-1].split(","):
    s2 += "%d," % (int(x) + default[i])
    i += 1

  return s2[:-1]

# schmoo = "4,3,2,0,0,-2,-2,0,-11"
def decode_schmoo(schmoo):
  i = 0
  v = 0
  for x in schmoo.split(","):
    if x:
      y = int(x) - default[i]
      if i < 3:
        v |= ES(y, i+1)
      elif i == 3:
        v |= (y & 1) << 29
      elif i == 4:
        v |= (y & 1) << 28
      else:
        v |= ES(y, i-1)
    i += 1
  return "0x%s" % format(v, "08x")

if len(sys.argv) != 2:
  print("Usage: %s 4,3,2,0,0,-2,-2,0,-11 or %s 0x0200002f" % (sys.argv[0], sys.argv[0]))
else:
  if sys.argv[1].find(",") != -1:
    print(decode_schmoo(sys.argv[1]))
  else:
    print(encode_schmoo_offsets(int(sys.argv[1], 16)))
Remember to give it execute permission: "chmod +x ./schmoo.py"

Then:

Code: Select all

$ ./schmoo.py 4,3,2,0,0,-2,-2,0,-10
0x02000020

$ ./schmoo.py 0x02000020
4,3,2,0,0,-2,-2,0,-10

$ ./schmoo.py 4,3,2,0,0,-2,-2,-3,-9
0x020000f1

$ ./schmoo.py -1,3,2,0,0,-2,-2,-2,-10
0x0d000000
etc.

User avatar
GTR2Fan
Posts: 1601
Joined: Sun Feb 23, 2014 9:20 pm
Location: South East UK

Re: Overclocking

Thu Feb 04, 2016 7:38 pm

This is a brief summary of my testing over the past couple of days. Insomnia has its advantages. It shows a nice 1mV/MHz correlation for required RAM voltage for a given frequency from 500 to 600MHz when using sdram_schmoo=0x02000020...

Code: Select all

Pi2B RAM overclocking using rpi-update and sdram_schmoo=0x02000020

RAM voltages  Stable
p    i    c	MHz

2    0    0	500
3    1    1	525
4    2    2	550
5    3    3	575
6    4    4	600

Stability tested with at least 3 runs of memtester 700 and 1hr of Quake Darkplaces.
Each tested frequency had at least 8MHz of headroom before instability started to creep in, so the correlation between frequency and required voltage on this particular Pi2B seems to approximate fairly well to a straight line within these frequency limits. If this turned out to be roughly the case in general, that could make for a very simple auto-overvolting algorithm up to the limit that a more cooperative Pi2B is sensibly capable of.

As long as you made it clear that absolute stability wasn't guaranteed above 500MHz, I think you'd have your backs covered. ;)
Pi2B Mini-PC/Media Centre: ARM=1GHz (+3), Core=500MHz, v3d=500MHz, h264=333MHz, RAM=DDR2-1200 (+6/+4/+4+schmoo). Sandisk Ultra HC-I 32GB microSD card on '50=100' OCed slot (42MB/s read) running Raspbian/KODI16, Seagate 3.5" 1.5TB HDD mass storage.

User avatar
GTR2Fan
Posts: 1601
Joined: Sun Feb 23, 2014 9:20 pm
Location: South East UK

Re: Overclocking

Fri Feb 05, 2016 4:26 pm

Apologies for the double post, but it's a change of topic relating back to earlier posts in this thread regarding dtoverlay=sdhost.

As the 32GB Sandisk Ultra HC-I microSD card here has been performing flawlessly nearly 24/7 since overclocking it with dtoverlay=sdhost,overclock_50=100 a couple of weeks ago, I thought I'd publish performance figures to show how it compares to the USB-connected 3.5" 1.5TB hard drive it shares a home with in my custom Pi2B Mini-PC/Media Centre.

Code: Select all

Pi2B - 32GB Sandisk Ultra HC-I vs 3.5"
1.5TB Seagate Barracuda on USB2.0 (Ext4)

Block Size	  SDHC	 HDD     Gain

16MB read      42.35	25.67	1.65x

16MB write     12.40   26.92   0.46x

4KB read       12.11    3.84   3.15x

4KB write       3.05    1.10   2.77x

All figures in MB/s
I have tried running the OSes from the hard drive, but it's like wading through lumpy porridge compared to running them from this particular overclocked microSD card. It really is quite snappy! :)
Pi2B Mini-PC/Media Centre: ARM=1GHz (+3), Core=500MHz, v3d=500MHz, h264=333MHz, RAM=DDR2-1200 (+6/+4/+4+schmoo). Sandisk Ultra HC-I 32GB microSD card on '50=100' OCed slot (42MB/s read) running Raspbian/KODI16, Seagate 3.5" 1.5TB HDD mass storage.

Return to “Advanced users”