Не уверен насчет задач:
"QWAVE", # Quality Windows Audio Video Experience
и без этого этого блютус работает, но не видит мышку.
"bthserv", # Bluetooth Support Service
Device Install Service почему-то устанавливается в manual, и без ручного запуска тоже не давал добавить мышь. Но все остальное вроде ок

Третьим делом выключил гибернацию.
powercfg.exe /hibernate off

Я в свое время с гибарнацией поел с лопаты, когда оперативка просто кончилась, и то, что она ушла на кеширование файла гибернации, было видно только в Sysinternals RAMmap.

И четвертым делом потыкал в Sysinternals  Autoruns

И на выходе получил ошибку отсюда:
Automatic Device Encryption Support  Reasons for failed automatic device encryption: PCR7 binding is not supported, Un-allowed DMA capable bus/device(s) detected

Это не про user space сервис, это про
"ShellHWDetection", # Shell Hardware Detection

Исправил и это тоже, иначе какое шифрование, какое авто монтирование.

Power plan

Оказывается, по умолчанию мне система поставила Balanced power, ну куда это годится. Пришлось покрутить ручки, но про это позже.

Hyper-V for Windows 11

Я много лет использовал VMware Workstation, но есть нюанс. У Windows есть разные режимы работы с виртуализацией, и VMware Workstation, особенно в части дисковых операций, из-за множества прокладок и трансляций, скажу так – не то чтобы не дает скорости, но становится крайне процессоро-зависима. Любой ПУК в хостовой системе, и дисковые операции в Workstation начинают думать. У ESXi такой проблемы, разумеется, нет – это абсолютно другая архитектура. В любом случае Dekiru Neko wa Kyou mo Yuuutsu

Потестирую хоть как-то.

Для процессора и памяти, конечно, берем
Free Mersenne Prime Search Software - Great Internet Mersenne Prime Search, GIMPS

Для диска берем DiskSPD последней версии, DISKSPD 2.2 – брать тут.

Конечно надо было померять скорость ДО включения Hyper-v, поскольку, если вы не знали, Hyper-V работает как нормальный гипервизор, подгружая Windows уже в виде виртуальной машины, что может быть и влияет на производительность. А может, и нет. То есть, конечно, да, но не совсем.

Что там на NTFS?
Get-CimInstance -ClassName Win32_Volume | Select-Object DriveLetter, FileSystem, BlockSize| Format-Table -AutoSize

ATTO Disk Benchmark (качать тут, статья с примером тут) показывает совсем не то, что хотелось бы. Потому что он работает в один поток, и только глубина очереди как-то регулируется.  

На DiskSPD, конечно, словил ошибку:

Попутно словил ошибку -
WARNING: Could not set privileges for setting valid file size; will use a slower method of preparing the file

И решение:
OK, so that's exactly what's happening. There is certainly (always) a longer description to attach to it (see above), but DISKSPD when run w/o privilege to assert SeManageVolumePrivilege cannot invoke SetFileValidData and therefore has to write the entire file through to get it into its standard if-created-by-DISKSPD state: with valid data at the end of the file.

Решение очевидное, от админа надо запускать.

Новый диск на новом ноутбуке выдает: (Файловая система – NTFS с блоком 4k, очередь по умолчанию – 2). Файлы по 200 Гб, не похоже на тестирование кеша.
Тестирование - 60 секунд.
1 тред, 1 файл – 35.000 IOPS блоком 4к на чтение, 15.000 IOPS блоком 8к на чтение
1 тред, 1 файл – 40k IOPS блоком 4к на запись (как так вышло – не знаю), 45k IOPS блоком 8к на запись. Это как?
2 треда, 1 файл – 25.000 на поток, итого 50.000 IOPS блоком 4к на чтение, и 2 по 30.000 на запись блоком 4к
3 треда – 23.000, всего 70 на чтение, и на запись 25, 25, и 35 тысяч, итого 85k. Блоком 8к показатели аналогичны
4 треда – 4 по 22.500,  всего 90к на чтение. И 4 по 23 к на запись, итого 92к.
5 тредов – 20.000 на тред, всего 100к на чтение.  Аналогично при блоке на 8k, те же 20.000 IOPS на тред на чтение,
На запись – примерно 10.000 IOPS блоком 4к на тред при первом тесте, до того как я покрутил настройки баланса.

Как бы так сказать «я ничего не понял», не говоря, что ничего не понял?
Проблема тестирования дисков наглядно показывает рост времени исполнения.

Что удивительно, но тестирования изнутри виртуальной машины (Windows server 2025, STD, обновления от 07-2025) показывают цифры, схожие с работой из управляющей операционной системы. Как бы так еще понять, в какой Windows 11 добавили новый NVME обработчик – в 11h22, h23 или h24.

Пропущу длинное русское поле экспериментов, итого:
Для физики:
Размер файла имеет значение. Windows пытается максимально закешировать что можно, и в итоге, если у вас 64 Гб оперативки, а тестовые файлы по 20-40 гигабайт, то цифры будут странные.
Надо брать для тестов файлы в 3-5 раз больше размера оперативки, 200 Гб на файл, два файла, на 64 Гб памяти – уже сойдет.
Количество реальных ядер и CCX имеет значение, причем для дисковых операций на хосте «потоки» AMD работают куда лучше «потоков» Intel. И, особенно, на последних мобильных интелах без HT и с энерго сберегающими ядрами.
На этом ноутбуке 6 ядер, 12 потоков – так вот, до 12 потоков включительно нагрузка растет линейно.
Конкретно этот NVME обрабатывает :
На чтение, 8 тредов: 4 треда по 40k, 4 по 20. 10 тредов – 10 по 35k, всего 350. 12 тредов – 12 по 35, всего 400k. 14 тредов – 10 по 30k, 4 по 15. 16 тредов – 8 по 28, 8 по 12. 18 тредов – 6 по 25, 12 по 10. Максимум достигается при числе тредов DISKspd = числу тредов в CPU.
И это около 400k IOPS. На чтение. Блоком 4к. При глубине очереди 2.

На запись картина другая. Есть подозрение на гигагерце зависимость по ядрам, авторазгон я не выключил.

Максимум получен для 8 тредов – 8x32k, около 256k IOPS на запись блоком 4k.
При 10 тредах получается по 19k на запись, всего 190к. Но расхождения по тредам нет. 12 тредов – падение до 12k IOPS на запись на тред, всего 145k, но все еще нет расхождения.
14 тредов – 10 тредов по 12 к и 4 треда по 7к. Всего 155k. 16 тредов – 8 тредов по 10к и 8 тредов по 5.5k - всего 125. 18 тредов – 6 по 10к, 12 по 6.5

То есть максимальное число тредов по записи на физическом хосте в моих условиях не стоит держать выше, чем число физических ядер плюс два. При большой записи, конечно.

Изнутри виртуальной среды картина чуть другая

Тестовая виртуальная машина, 4 ядра, 8 Гб памяти, и, для начала, просто 2 файла по 20, не по 200, Гб.

Чтение, 2 треда: 24k IOPS на тред, всего 48k
Запись, 2 треда: 12k IOPS на тред при 2 тредах, всего 24k

Падение на чтение в 1.5 раза, падение на запись в 3 раза. Но, это тестирования НОУТБУКА, с домашним NVME SSD, и Windows 11. На Windows Server картина может быть абсолютно другой.
Чтение, 4 треда: 3 треда по 15K IOPS, 1 тред на 2k IOPS. Суммарно 47k
Запись, 4 треда – 3 по 8k, 1 на 5k, итого 30 (данные округлены)

Дальше начинается колдовство и магия. Файлы по 200 Гб, 2 файла.
чтение, 4 треда на файл, всего 8 тредов: 6 тредов дают по 16к, 2 треда по 2к. Итого 100k IOPS изнутри виртуалки на 4 процессора.
Чтение, 5 тредов на файл, всего 10 трелов. 7 тредов по 15к, 2 по 1к. Итого 110к
Чтение, 6/12. 9 по 18к, 3 по 2.5. Итого 170к. Идет, к слову так, блоками по 3 группы «больших» IOPS.
Чтение, 7/14. 10 по 14к, 4 по 1к. Итого 150к.
Чтение, 8/16. 12 по 20k IOPS, 4 по 2. Итого 260K IOPS на чтение изнутри VM на 4 ядра.
Чтение, 9/18. 13 по 18..22, 5 по 1.5. Итого 280k.
Чтение, 10/20. 15 по 21, 5 по 2. Итого 330k.
Чтение,11/22. 343k IOPS
Чтение, 12/24. 18 тредов по 22k IOPS, 6 тредов по 2к. Итого почти 400k IOPS на чтение. 
То есть, 4 процессорная виртуальная машина на 24 треда выдала почти столько же IOPS, сколько физика при 12 тредах.
Для физики параметры были: -t6 -w0 -b4k -W10 -o2, и два файла по 200 Гб, то есть 12 тредов итого.

Файлы по 200 Гб, 1 файл. Чтение внутри виртуальной машины.

1 тред – 31k IOPS , 2 треда = 2x24 = 48, 3 треда 2x25+ 1x12 = 62(k IOPS), 4 треда – 3 по 16 и 1 тред на 2, итого 50.
5 тредов = 3 по 16 и 2 по 1.5, 6 тредов – 4 по 15 и 2 по 1.5, всего 62. ,7 тредов -  5 по 14.5 и 2 по 1.8. 8 тредов – 6 по 13 и 2 по 2.5, итого 83k
9 тредов – 6 по 12, 3 по 1.2 , итого 75. 10 – 85k IOPS, 11 – 92k IOPS, 12 – 102k IOPS
Логика какая-то странная.

Дописал текст, и увидел внутри виртуальной машины active power scheme: Balanced
Похоже, надо дополнительно смотреть на параметр:
ag  Group affinity – affinitize threads in a round-robin manner across Processor Groups, starting at group 0. This is default. Use -n to disable affinity.

Или выделять не по 4 ядра на виртуальную машину, при физических 6, которые может еще надо как-то делить, а по 3. Или по 6.
Я в курсе про CCXs (Core Complex), но как-то странно это все.

Дожил, неужели NUMA имеет значение. Но не в 10 же раз разницы из-за Numa (CCX/CCD). И самое главное, не понятно, как изнутри 4 процессорной VM – дисковые задачи раскладываются на физические ядра и процессорные треды / потоки. Как 24 треда разложились на 18 быстрых и 6 медленных. И как из этой конструкции получить например 12 средних. Как вообще CPU scheduler что-то куда-то кладет в такой конфигурации. И не отпилить ли root.

Еще оказалось очень полезно посмотреть на итоговый размер файлов виртуальных машин. Поскольку тесты шли по 30-60 секунд, то максимально за это время записалось всего по 1.5 – 2 гигабайта. Но я еще посмотрю более детально.

Литература

скрипт DisableUnnecessaryWindowsServices
Windows Server 2025 Storage Performance with Diskspd
Sample command lines
Command line and parameters
Execution time longer than the parameter execution time on WSL Ubuntu #203

В следующих сериях:
Опыты на виртуальной машине на 3 ядра.

CPU affinity
Опыты на Debian внутри Hyper-V, опыты с Proxmox nested. Stay tuned!

Бонус

# 01

$pciStats = (Get-WMIObject Win32_Bus -Filter 'DeviceID like "PCI%"').GetRelated('Win32_PnPEntity') |

foreach {

# request connection properties from wmi

[pscustomobject][ordered]@{

Name = $_.Name

ExpressSpecVersion=$_.GetDeviceProperties('DEVPKEY_PciDevice_ExpressSpecVersion').deviceProperties.data

MaxLinkSpeed =$_.GetDeviceProperties('DEVPKEY_PciDevice_MaxLinkSpeed' ).deviceProperties.data

MaxLinkWidth =$_.GetDeviceProperties('DEVPKEY_PciDevice_MaxLinkWidth' ).deviceProperties.data

CurrentLinkSpeed =$_.GetDeviceProperties('DEVPKEY_PciDevice_CurrentLinkSpeed' ).deviceProperties.data

CurrentLinkWidth =$_.GetDeviceProperties('DEVPKEY_PciDevice_CurrentLinkWidth' ).deviceProperties.data

} |

# only keep devices with PCI connections

Where MaxLinkSpeed

}

$pciStats | Format-Table -AutoSize

Get-CimInstance -ClassName Win32_Volume | Select-Object DriveLetter, FileSystem, BlockSize| Format-Table -AutoSize

$Path001 = 'C:\DiskSpd\amd64\'

$Sp = $Path001 + "diskspd.exe"

cd $Path001

$Version = "007g1"

$Drives = @("C")

$FilesTemp = "Data4del"

$File001 = "deleteme_01.dm"

$File002 = "deleteme_02.dm"

$File003 = "deleteme_03.dm"

$Logs = @()

# $Threads = @("-t1","-t2", "-t3", "-t4","-t5","-t6","-t7")

$Threads = @("-t4","-t5","-t6","-t7","-t8","-t9")

# $Write = ("-w0","-w30", "-w100")

$Write = @("-w0")

#$BlockSize = ("-b4k","-b8k")

$BlockSize = @("-b4k")

# $Outstanding = @("-o2","-o4","-o8","-o16")

$Outstanding = @("-o2")

$Size = "-c200G"

$Time = "-d30"

foreach ($Drv in $Drives){

foreach ($Bl in $BlockSize) {

foreach ($Wr in $Write) {

foreach ($Outs in $Outstanding){

foreach ($T1 in $Threads){

$TimeNow = get-date -UFormat "-%d-%m-%Y-%R" | ForEach-Object {$_ -replace ":","-"}

Write-Host "TT " $TimeNow

$Out001 = $Drv + ':\' + $FilesTemp + '\' + $File001

$Out002 = $Drv + ':\' + $FilesTemp + '\' + $File002

$Out003 = $Drv + ':\' + $FilesTemp + '\' + $File003

$Stat = $Drv + ':\' + $FilesTemp + '\' + $Version + $TimeNow + "_" + $T1 + $Drv + $Outs+$T1+'.log'

$Logs += $Stat

Write-Host "testing mode " $T1 $Wr $Bl $Outs 'time' $Time

&$Sp $T1 $Wr $Bl -W10 $Outs $Time -Suw -D -L $Size $Out001 $Out002 > $Stat

}}}}}

Если на электронику, содержащую в своем составе электролитические конденсаторы длительное время не подавать питание, то при последующем ее включении вы можете стать свидетелем, как из нее выйдет белый дым, и она перестанет работать.

Вы никогда не сталкивались с такой ситуацией, что при подаче питания на электроприбор, то есть при его включении, после длительного перерыва в работе, например, более года, он внезапно выходит из строя? Хотя до последнего выключения он работал исправно. А это имеет место быть. И чем больше был перерыв в работе электроприбора, тем больше вероятность его выхода из строя при включении. Нет, я не утверждаю, что при включении электроприбора в данной ситуации он обязательно выйдет из строя. Но! Вероятность этого события при этом  увеличится.

Давайте разберемся, почему это происходит. Почти все электроприборы, от компьютера, до стиральной машины содержат в своем составе электролитические конденсаторы. И в этой статье речь пойдет о них, как об основных виновниках выхода из строя электроприборов. Чтобы понять физические процессы происходящие при этом в электролитических конденсаторах, рассмотрим их устройство.

Электролитический конденсатор состоит из герметичной колбы, в которую запрессованы две обкладки свернутые в спираль. Положительная и отрицательная. Положительная обкладка выполнена из алюминиевой фольги, покрытой тонкой пленкой оксида алюминия, которая исполняет роль диэлектрика в конденсаторе между обкладками.

Отрицательной обкладкой является жидкий электролит, которым пропитана бумажная лента и которая имеет гальванический контакт с неоксидированной (непокрытой пленкой оксида алюминия) алюминиевой фольгой, обеспечивающей надежный контакт между отрицательным выводом конденсатора и электролитом, благодаря их большой площади соприкосновения.

При длительном перерыве в работе, то есть при отсутствии на конденсаторе напряжения в течении этого времени, происходит постепенное разрушение диэлектрика (оксида алюминия) при его взаимодействии с электролитом в отсутствии напряжения на обкладках конденсатора. Это приводит к утончению диэлектрического слоя, к увеличению тока утечки и как следствие, увеличению вероятности пробоя конденсатора при подаче на него номинального напряжения. Этот эффект начинает проявляться при перерыве в работе конденсатора длительностью более года.

Специалисты в таких случаях рекомендуют проводить тренировку (формовку) конденсаторов, суть которой заключается в подаче на конденсатор в течении длительного времени постепенно увеличивающегося напряжения, с контролем тока утечки. При этом, подача в начале тренировки малого значения напряжения, не приведет к пробою конденсатора, и начнется процесс восстановления диэлектрического слоя (оксида алюминия) благодаря процессу электролиза. И по мере восстановления диэлектрического слоя, напряжение на конденсаторе увеличивается до номинального. Скорость увеличения напряжения определяется по значению тока утечки.

Рекомендации одного из производителей электролитических конденсаторов по проведению тренировки (риформинга).

Еще выдержка из технической документации производителя конденсаторов EPCOS.

Проведем практическую проверку этого эффекта. В качестве подопытного возьму недавно купленный на радиорынке электролитический конденсатор на 3300 мкФ., с номинальным напряжением 25 В., дата изготовления сентябрь 2016 года.

Предполагаю, что с даты изготовления, и до сегодняшнего дня на него никто не подавал напряжение. И потому для эксперимента он подходит, как нельзя лучше. Подам на него с лабораторного источника питания 25 В., и после его заряда в разрыв включу амперметр (прибор Ц-43101) для измерения тока утечки.

Отсюда видно, что ток утечки составил 35 мкА. (вся шкала прибора 250 мкА). Оставляю его под напряжением на 1 час, и повторю измерение.

В этом случае, как мы видим, ток утечки составил 7 мкА. Итого ток утечки уменьшился в 5 раз. Отсюда вывод, вышеизложенное явление подтверждено на практике.

Но не будете, же вы выпаивать из своих компьютеров и телевизоров конденсаторы для их тренировки, после их длительного перерыва в работе. Поэтому включайте свою электронику (подавайте на нее питание) хотя бы раз в год. А иначе после включения, особенно если в вашей электронике применены дешевые конденсаторы из них может выйти белый дым.

Во время моей учебы, мой преподаватель по предмету «радиокомпоненты» как то спросил у нас: так на чем работает вся электроника? Многие начали отвечать, что работает на упорядоченном движении заряженных частиц, и так далее. На что преподаватель в шутку сказал, что вся электроника работает на белом дыме. Пока белый дым находится в электронике, она работает. Как только белый дым выходит из электроники, она перестает работать. Так и в данном случае с нашими электролитическими конденсаторами, подобное может произойти.

Кроме того, электролитические конденсаторы подвержены высыханию. И это их основная проблема, каждый второй ремонт электроники по моему опыту заканчивается заменой именно этой детали. Высыхание происходит из-за плохой герметизации корпуса. Вследствие чего электролит постепенно испаряется, а поскольку он является одной из обкладок конденсатора, то и получается, что испаряется одна обкладка конденсатора. И емкость уменьшается до нуля. Опять же это зависит от качества конденсаторов. С качественными конденсаторами вероятность подобного значительно меньше. Но, к сожалению, при покупке электроники возможности изучить применяемую в ней элементную базу, какие там стоят конденсаторы не всегда возможно.

Подобных недостатков лишены полимерные конденсаторы.

Поэтому, выбирая комплектующие компьютерной техники, старайтесь выбирать комплектующие, выполненные на полимерных конденсаторах. Тем более, что во многих комплектующих визуально открыт доступ к используемой элементной базе. И легко, например, увидеть на материнской плате, какие конденсаторы применяются.