Интересно, под Win10 показывает 3200 Мгц:

	Скрытый текст

А под убунту 3200 MT/s:

sudo dmidecode --type 17
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.
# SMBIOS implementations newer than version 3.2.0 are not
# fully supported by this version of dmidecode.

Handle 0x0023, DMI type 17, 92 bytes
Memory Device
...
    Speed: 3200 MT/s
...
    Configured Memory Speed: 3200 MT/s
...

А ведь это не одно и тоже.

Вопрос: какая всё-таки частота?

UPD 3200 Mhz, по ходу dmidecode что-то не так показывает

sudo lshw -C memory
  *-memory
       описание: Системная память
       физический ID: 22
       слот: Системная плата или материнская плата
       размер: 16GiB
     *-bank:0
 ...
          частота: 3200MHz (0.3ns)

Здравствуйте, Dym On, Вы писали:

DO>Интересно, под Win10 показывает 3200 Мгц:

Довольно подробно тут и вдобавок вот тут

Здравствуйте, Dym On, Вы писали:

DO>Интересно, под Win10 показывает 3200 Мгц:
А что вас собственно не устраивает?
1 ddr 3200MHz по 64бит (у DDR4).
chip clock rage 400MHz
bus clock rate 1600MHz
transfer rate 3200MHz
bandwidth 3.2GHz*64bit/1byte = 3.2e9*8 bauds = 3.2*(1000/1024)^3*8 Gb/s = 3.2*7.45Gb/s = 23.84Gb/s
если 2 канала то 23.84*2 = 47.68Gb/s
если 12 то 12*23.84 = 286Gb/s.
Но это только в идеальных условиях, если читать случайные адреса можно вернуться к 100Mb/s

Здравствуйте, Dym On, Вы писали:

DO>Вопрос: какая всё-таки частота?

Реальная частота 1600 МГц, именно с этой частотой память может принимать команды, но не всякий контроллер может их отправлять так быстро (это разные производители называют gear 1:1, или command rate 1T, но возможно и более редкая передача команд — например "через такт" — gear 1:2/command rate 2T). Передача данных осуществляется по обоим фронтам тактового сигнала, то есть количество трансферов данных вдвое больше, чем тактовая частота, его измеряют в MT/s (mega-transfers per second), и их как раз 3200. Маркетологи решили указывать именно эту цифру, потому что всем известно, что больше — это же лучше. Но чего они не говорят, так это то, что данные приходят "пакетами" по 8 трансферов, то есть на одну команду чтения память отвечает сразу куском памяти в 8 трансферов по 8 байт каждый, и занимает это 4 цикла тактовой частоты + дополнительная латентность CAS (column address strobe, иногда её ещё обозначают CL — Cas Latency), но, чтобы прочитать некоторую область памяти, нужно сначала "открыть" (ACTIVATE в терминах DDRx) строку, где находится интересующая область, и это занимает время t_RCD (13.75 нс, или 22 цикла частоты 1600 МГц), более того, в один момент времени можно держать открытыми только ограниченное количество строк, а потому вполне возможно, что перед тем, как открыть интересующую строку, придётся "закрыть" (PRECHARGE) ту строку, что была открытой до этого, что так же займёт дополнительное время. Теперь ты понимаешь, почему важно писать приложения так, чтобы по возможности они обращались к памяти линейно и последовательно? В этом случае блок prefetch спекулятивно будет загружать последовательные строки памяти ещё до того, как твой код дойдёт до обращения к ним, и потому к моменту собственно обращения они уже окажутся в кэше и потому будут доступны немедленно.

Интересно, что длина строки кэша в большинстве современных процессоров равна 64 байта, и именно столько передаёт память DDR4 за одну команду. И это совсем не случайное совпадение.