Ma is tanultam valamit

Videó enkódolás több szálon / több CPU magon lerontja a kódolás minőségét! Ez azért van, mert több szálú videótömörítés esetén a szálak egymástól függetlenül dolgozzák fel az adott képblokkokat: a tömörítés során nem tudják felhasználni a közvetlen előző képkockában letárolt adatokat (delta tömörítês 2 képkocka között), mert azokon pl. 1 másik szál / másik CPU mag dolgozik éppen. Ezért hatékonytalanabb lesz a tömörítés, egyedül a gyorsaságon skálázódik jól a többszálú futtatás. Azaz az ideális megoldás videótömörítésre a lehetőleg 1-szálas futtatás, de azt lehetőleg minél gyorsabb processzormagon. Többmagos processzorok esetén meg az a hatékonyabb megoldás, ha több egymástól független videófájl tömörítést futtatunk párhuzamosan, ahol minden egyes videót magát viszont csak 1-szálas módban tömörítünk.

A közhiedelemmel ellentétben SSD-t is kell defraggolni.

https://www.hanselman.com/blog/the-real-and-complete-story-does-windows…

Eleve nem érdemes letiltani az ütemezett defrag-ot ssd meghajtóknál, mert általában ilyenkor csak egy un. "optimalizáció" fut le, ami annyit tesz h. futtat egy TRIM-et, és már kész is, pár másodperc. Ezen kívül, ha engedélyezett a meghajtó valamelyik kötetén a Volume Shadowcopy, akkor havonta ütemezetten ténylegesen is defraggolja, mert a nagyon töredezett fájlokat máskülönben nem lenne képes backup-olni.

A CPUID "HTT" az vajon azt jelenti, hogy támogatja a processzor a Hyper Threading-et? Hát nem.

http://www.os2museum.com/wp/htt-means-hyper-threading-right/

---------------------------------------------------------------------------------

In a logical, ordered world, the HTT bit in CPUID would indicate a processor with Hyper-Threading Technology enabled. But of course the world with Intel inside is anything but logical.

The actual meaning of the HTT bit changed several times over the years. Tracking exactly how it changed is difficult without all editions of Intel’s CPUID documentation (initially a standalone document, folded into the SDM in 2012), but there’s enough left to get a good idea.

Hyper-threading was introduced in the 180nm Foster MP Xeon in February 2002. That was the server version of the original Pentium 4 Willamette NetBurst implementation. Back in May 2002 (the oldest CPUID document with the HTT bit included that I could find), Intel said: HTT: This processor’s microarchitecture has the capability to operate as multiple logical processors within the same physical package. This field does not indicate that Hyper-Threading Technology has been enabled for this specific processor. To determine if Hyper-Threading Technology is supported, check the value returned in EBX[23:16] after executing CPUID with EAX=1. If EBX[23:16] contains a value > 1, then the processor supports Hyper-Threading Technology.

In other words, the HTT bit never meant that hyper-threading is enabled, or even that a given CPU is hyper-threading capable. It was a misnomer from the beginning.

And indeed, as the CPUID dumps here show, Northwood P4s with and without HT had the HTT bit set; the difference was in EBX[23:16] (indicating 1 logical processor for standard CPUs vs. 2 for HT-enabled models).

Intel changed the definition of the HTT bit over time. In May 2012, Intel said: HTT: Multi-Threading: The physical processor package is capable of supporting more than one logical processor. This field does not indicate that Hyper-Threading Technology or Core Multi-Processing (CMP) has been enabled for this specific processor. To determine if Hyper-Threading Technology or CMP is supported, compare value returned in EBX[23:16] after executing CPUID with EAX=1. If the resulting value > 1, then the processor supports Multi-Threading.

When Intel introduced dual-core CPUs without hyper-threading, the HTT bit was still used in exactly the same way as for single-core CPUs with hyper-threading. That makes perfect sense (other than the poorly chosen name), because in both cases there is a single physical package with two logical processors, and software needs to treat both cases largely the same.

The HTT bit alone therefore means almost nothing—it might be set on a single-core CPU without hyper-threading, and it will be set on single-core CPU with hyper-threading, multi-core CPU without hyper-threading, as well as a multi-core CPU with hyper-threading. Other CPUID data must be used to distinguish between those cases, as the information associated with the HTT bit only indicates the number of logical processors, not how they are structured.

As of October 2017, Intel now says: HTT: Max APIC IDs reserved field is Valid. A value of 0 for HTT indicates there is only a single logical processor in the package and software should assume only a single APIC ID is reserved. A value of 1 for HTT indicates the value in CPUID.1.EBX[23:16] (the Maximum number of addressable IDs for logical processors in this package) is valid for the package.

Intel appears to be unwilling to change the name of the HTT bit, but the poorly chosen moniker is now fully exposed: The definition of the HTT bit does not even mention hyper-threading at all.

It’s worth mentioning that the original Willamette P4 apparently set EBX[23:16] to 1 even though the HTT bit was not set. In other words, EBX[23:16] may contain valid information on some processors even though it’s not declared as valid via the HTT bit. That was undocumented behavior, and was also found in single-core Yonah CPUs (but not Banias/Dothan Pentium M).

All in all, this is a case where the documentation was never exactly wrong, it just evolved so much that the original name of the HTT bit doesn’t make any sense anymore, if it ever did.

Miért van a windows System properties alatt a CPU neve után egy órajel érték meg utána még 1 másik, és ez a 2 általában nem egyezik meg?

https://learn.microsoft.com/en-US/troubleshoot/windows-server/performan…

The first frequency that is listed for the processor is fixed and part of the name of the processor. The second frequency is normally computed by Windows using P-states or the frequency of the time stamp counter. However, when the Intel CPPC driver is installed, the system uses CPPC to manage the frequency of the processor and not P-states. As a result, Windows uses the time stamp counter frequency to determine processor frequency. On systems with Intel-based processors that support configurable thermal design power (TDP), this may result in the second frequency listed being different from the first.

Windows 10, a fos "modern" gépházas hálókártya properties --> IP settings --> Edit --> DHCP helyett manual-ra váltás--> ipv4 bepipál, ezután kézzel beadni neki amit akarsz, pl. 192.168.1.2, subnet: 255.255.255.0 , def gw és DNS nem muszáj. Majd Save --> és.... Nem fogadja el bazdmeg! Csak egy piros szöveg a tetején, hogy "hávalaminemjó, nézd meg jobban"! Végignézem, de minden jó, egy rohadt private címes IP konfigot csak be tudok állítani! Hát a lófaszt tudok.

Lelövöm a poént: Az istenbarmák redmondban 30 év után átálltak a dotted subnetmask formátumról a prefix length notation-re. De nem ám úgy, h. ott van az example a bemeneti field fölött, hogy pl /24 nesze így írdd be paraszt! Nem, nincs semmi fogodzkodó. Cserébe a hibaüzenetnél sem bírja pirossal bekeretezni h. ezzel van a baja. Hanem tépd ki a hajad mire rájössz (nem jössz rá magastól, hanem fél óra guglizás után valami értrelmesebb ITPRO elárulja).

Pokol bugyor annak, aki ezt így kiengedte élesbe. A hülye internet népe meg ahelyett h. megfejtette volna, írják a kerülőmegoldásokat h. ez a szar settings gépház még erre se jó, classic control panelből meg működik a régi módon beállítani.

https://phisonblog.com/host-memory-buffer-2/

https://www.anandtech.com/show/16504/the-samsung-ssd-980-500gb-1tb-revi…

https://www.anandtech.com/show/12819/the-toshiba-rc100-ssd-review/2

HMB SSD: Host Memory Buffer, azaz rendszer RAM-ot használ, az SSD PCB-n nincs cache DRAM. Nvme 1.2 szabvány óta létezik. A host-tól az nvme driver elvesz max 64MB memóriát (ez ha jól tudom a mikroszoftos "storport" drájver beépített maximuma, ha más gyártói nvme drájvert használ egy SSD, azoknál talán használhat több memóriát is). Ez a 64MB RAM cache 64GB SSD storage egyidejű mapping-hez elég. Azaz ha bármikor adatra egyszerre csak kb 64GB méretben van szükség, akkor nem lesz olyan rossz a teljesítmény a DRAM-os SSDkhez képest. Ez a cache nem adat cache, azaz nem arra való, h. pl. az írást ide cachelje az SSD, mint a tradicionális HDD onboard cache-nél.

Azt viszont nem egyszerű kideríteni (windows-on legalábbis), mennyi a tényleges buffer amit az nvme driver kért/kapott a host-tól. Kb egyik elterjedt 3rd party ssd utility sem írja ki. A gyártói tool-ok, pl. Samsung Magician annyit mond h. Host Memory Buffer oszt csókolom.

Elvileg Linux alatt van rá egyszerű(bb) módszer. Ha az elkövetkező években megtalálom a választ, updatelem ezt a hsz-t.

Update: végülis megtaláltam

If your SSD controller just uses the generic Microsoft StorPort driver, then yes, you can force-enable use of the Host Memory Buffer functionality via a registry key.

Under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StorPort create a DWORD entry called HMBAllocationPolicy and set the value to 2. Valid values are 0 for disabled, 1 for minimum, 2 for maximum, and 3 for device usage-based (I tried this on my end, and it just allocates the device minimum; megj: nálam a Samsung 980 nonPro is a minimumot allokálta 3-as értéknél, ami 0x1000000). Once that’s done, reboot the system, and you can check that it’s working in Event Viewer under Applications & Services Logs -> Microsoft -> Windows -> StorPort -> Microsoft-Windows-Storage-Storport/Operational. Look for event ID 513, it should look something like this:

Host Memory Buffer Allocation for \Device\RaidPort1 succeeded. 

Failure Reason: None 

Allocation Policy: Maximum 

Attemped to Allocate: 0x4000000 bytes 

Actually Allocated: 0x4000000 bytes 

Device Minimum: 0x337000 bytes 

Device Preferred: 0xC800000 bytes 

Policy Maximum: 0x4000000 bytes 

Do note that the Microsoft Storport HMB is limited to a maximum of 64MB.

Ha windows eventlog-nál hitelesebb ellenőrzés kell, van egy orosz faszi gyűjtése nvme firmware és tool-ok témában, ott van egy nvme HMB info tool. 

http://vlo.name:3000/ssdtool/

Az SHA512 tud gyorsabb lenni ugyanazon a gépen, mint az SHA256.

md5sum(1) (freebsd.org)

SHA-512t256  is	a  version  of SHA-512 truncated to only 256 bits.  On
       64-bit hardware,	 this  algorithm  is  approximately  50%  faster  than
       SHA-256 but with	the same level of security.  The hashes	are not	inter-
       changeable.

SHA-512t224  is identical to SHA-512t256, but with the digest truncated
to 224 bits.

It is recommended that all new applications use	SHA-512	 or  SKEIN-512
instead of one of the other hash	functions.

hash - SHA-512 faster than SHA-256? - Cryptography Stack Exchange

 openssl speed sha256 sha512
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256           29685.74k    79537.52k   148376.58k   186700.77k   196588.36k
sha512           23606.96k    96415.90k   173050.74k   253669.59k   291315.50

As you can see, on my 64-bit machine, SHA-512 beats SHA-256 for hashing anything more than 16 bytes of data at a time. And generally, the more data being hashed at once, the bigger the performance improvement.

Edit: As @MaartenBodewes points out in the comments, there's also SHA-512/256 which does the same computation as normal SHA-512 (with a different initial value) but truncates the output to 256 bits. This is a better option (due to the different IV) than simply truncating the output of SHA-512 to 256 bits by yourself in the case where you need the higher throughput but are limited to 256 bit outputs. Alternatively, if you really need higher throughput, BLAKE2b is an excellent cryptographic hash that is extremely fast and natively supports arbitrarily sized outputs (between 1 and 64 bytes).

Note: (some modern CPU) has SHA-extensions that provide instructions to speed up SHA-1 and SHA-256 but not SHA-512. This may again turn the advantage to SHA-256, if the instructions are used of course. AMD Ryzen also supports these instructions.

Extension Instructions for SHA-512 will be introduced in Arrow Lake and Lunar Lake in 2024.

Egy diszk (v. SSD) esetén a WWN és a serial number között mi a lényegi különbség, ha elvileg mind a 2 unique? A WWN úgy unique, hogy közben még a formátuma is ugyanaz több eltérő gyártó több eltérő eszköztípusa között. A serial number formátuma meg ahány gyártó ahány eszköztípusa csak létezik, mind egyedi formátumú serial numbert használ, így szar lenne ezeket egységesen kezelni, összehasonlítani stb?

NTFS allocation policy-ről kellene valami leírás. Rémlik h. registry-ből régen lehetett állítani h. gyors legyen (de cserébe fragmentációt nem fogja próbálni elkerülni), vagy lassabban allokálja a klasztereket, több időt töltsön nagyobb összefüggő terület keresésével, cserébe kevésbbé lesz fragmentált a kiírt file.

Létezik hogy volt ilyen (akár régen XP idején?) vagy csak álmodtam az egészet?

Természetesen semmi értelmeset nem találok már mikroszoft oldalán. Csetgpt is totál használhatatlan válaszokat ad, notsupported, nepiszkáld, neérdekeljen... stb.

"Verifying DMI pool": POST végén, bootoláskor írja (írta régen) sok gép. Sosem tudtam ez mit jelent.

Van aki tudja?

Szégyen-nemszégyen, megkérdeztem a Gpt4 barátunkat:

The "Verifying DMI pool data" message that appeared on old computers before the boot process indicated that the BIOS was performing a specific set of tasks related to system hardware configuration. Here's a detailed explanation of the activities behind this message:

DMI (Desktop Management Interface): This is a standard framework for managing and tracking components in a computer, including the hardware configuration, system settings, and other important information. The DMI is part of the SMBIOS (System Management BIOS) specification.

Building the DMI Pool: The BIOS collects information about the system's hardware configuration and builds a data structure known as the DMI pool. This data structure includes details about the processor, memory, cache, installed cards, and other components.

Verifying DMI Pool Data: During the "Verifying DMI Pool Data" phase, the BIOS checks the integrity of the DMI pool to ensure that the data collected about the system hardware is accurate and complete. This involves:

Detecting and cataloging hardware components: The BIOS identifies all installed hardware components and collects their specifications.

Verifying consistency and completeness: The BIOS checks that all necessary information is present and that there are no conflicts or errors in the data.

Updating the DMI table: If necessary, the BIOS updates the DMI table with the latest information about the hardware configuration.

Transition to Boot Loader: Once the DMI pool data is verified, the BIOS hands control over to the boot loader, which then starts the process of loading the operating system.

The "Verifying DMI pool" message was a standard part of the POST (Power-On Self-Test) sequence that ensured the system's hardware configuration was correctly identified and recorded before attempting to boot the operating system. This step was crucial for the stability and proper functioning of the system, as any discrepancies or errors in the hardware configuration could lead to boot failures or system instability.

Láttam pár YT gépösszerakós csatornán, h. veszik rakásszám ebay-ről a használt ES-es xeon platinumokat, mert az eredeti árának kb. tizedébe kerülnek. Ilyen millió forint fölötti hardvernál ez már elég szép megtakarítás ahhoz, hogy megérje foglalkozni a témával. Az ES azt jelenti Engineering Sample. Azaz a kiadás előtti még nem végleges -de már majdnem az- eszközt az intel kiadja külső cégeknek, partnereknek stb. akik így a tényleges startra már fel tudnak készülni (pl. alaplapgyártók ezzel le tudják tesztelni a BIOS-t). Működésben és viselkedésben is kb. megkülönböztethetetlenek általában a végleges piacra dobott változatoktól. A tokozáson szokott szerepelni h. Intel Confidential, nincs megnevezve a konkrét modellkód, illetve a CPUID alapján a diagnosztikai program tudja jelezni h. ez ES típus.

Az egyetlen rizikó ezekkel a processzorokkal kapcsolatban, h. mivel nem végleges kiadások, nem széleskörű használatra szánták őket, így lehetnek bennük olyan működési hibák, amiket a végleges revision-ben esetleg már felismertek vagy akár ki is javítottak. Erről azonban publikus dokumentáció nem szokott elérhető lenni. Így marad a remény, h. az ilyen típusú processzort is helyesen fel fogja ismerni az alaplap és a bios, és jól fog működni az OS alatt + a használt programokban.

Ráeresztesz egy benchmark-ot, vagy prímszámolós stressz-tesztet, azzal csak részben lehet meggyőződni arról h. a processzor stabil, nem hibázik, és nem fagy meg terhelés alatt. Viszont lehet h. olyan részében / utasításban van benne hiba, amit a benchmarkok és stressztesztek nem vagy csak lájtosan tesztelik. Ezért a legbiztosabb teszt az lenne, ha egy program a processzor által ismert és támogatott összesnutasítást tudná aktiválni és kipróbálni, hátha azáltal kiderül ha bármi ilyesmi bug van a processzorban.

Kérdés: létezik vajon ilyen általános célú processzor tesztelő alkalmazás x86-ra?

Láttam h. van az intelnek egy Processor Validaton Tool nevezetű programja. De ahogy néztem, az kimerül abban h. leellenőrzi a CPU brand string GenuineIntel-e, futtat rajta néhány SSE, meg AVX stressztesztet, és ha ezek eredménye sikeres, akkor a processzor átment a vizsgán.

Mikor a ventillátorokból fújja ki az ember a port sűrített levegővel, kompresszorral (gpu, cpu, chipset) akkor előtte a lapátokat rögzíteni kellene, ÉS lehúzni minden csatlakozást a nyákról!

1) a fizikai erőhatás miatt: ha túlságosan erős levegővel fújatod közelről, az abmormálisan nagy fordulatszám kinyírhatja a csapágyazást, illetve a lapátok eltörhetnek. Ez eddig tiszta sor, józan paraszti ésszel.

2) Viszont ami már nem biztos h. nyilvánvaló: ha a ventillátor áramot kap --> ez forgatja a lapátokat. Ez visszafele is működik: ha te forgatod a lapátokat, az feszültséget indukál visszafele irányba a FAN csatlakozón. Nagyon megpörgetve a lapátokat elég nagy feszültséget is. A FAN csatlakozó-n -ha nincs valami diódás védelem- nem számítanak visszairányú áramra. Ezért tönkreteheti a csatlakozót, esetleg a chipset-et, vagy bármit ami a FAN-t vezérli az alaplapon.

SD kártyákhoz van egy senki által soha nem is hallott, nem ismert, és főleg soha nem is használt tool az SD Card Association (továbbiakban SDA) weboldalán:

https://www.sdcard.org/downloads/formatter/

The SD Memory Card Formatter formats SD Memory Card, SDHC Memory Card and SDXC Memory Card (respectively SD/SDHC/SDXC Cards) complying with the SD File System Specification created by the SD Association (SDA).

It is strongly recommended to use the SD Memory Card Formatter to format SD/SDHC/SDXC Cards rather than using formatting tools provided with individual operating systems. In general, formatting tools provided with operating systems can format various storage media including SD/SDHC/SDXC Cards, but it may not be optimized for SD/SDHC/SDXC Cards and it may result in lower performance.

SD/SDHC/SDXC Cards have a “Protected Area” for SD Card security purposes. The SD Memory Card Formatter does not format the protected area in the SD/SDHC/SDXC Cards. The protected area shall be formatted by an appropriate PC application or SD host devices that provide SD security function.

Na most azt leszámítva h. oké, a Protected Area-t leformázhatja az OS beépített format tool-ja (akár windows, akár mac, linux, vagy pl. céleszközökben levő format SD card opció). De a "lower performance" az vajon mi lehet? Az alignment-et rosszul lővi be, és write-amplification jellegű rossz sebességű írás üzemmódban fog menni? Azért az elég látványosan gyenge sebességet eredményezne pl. a speed class szerinti értékeket sem érné el, így hamar kibukna. Ez lehet valami Windows XP korabeli FUD, amit azóta sem akartak eltávolítani az oldalukról, mert jobb az ha retteg a véletlenül odalátogató, és így lesz összesen 10 ember a bolygón, aki ezzel a tool-al formázza majd le az sd kártyáit?

Továbbgondolva ugyanez a logika akkor megállja a helyét USB pendrájvra, neadjisten még a teljes SSD SATA/Nvme termékvonalra is?

Több portos USB-C töltőknél előfordul (kb. majdnem mindegyiknél), hogy a korábban már rádugott eszköz(ök) töltése 1 pár másodpercre teljesen megszakadhat, ha egy eddig kihasználatlan szabad portjára is rákötsz egy újabb eszközt. Renegotiation a kifejezés, amit nézni kell ebben az esetben. Természetesen nem a termékek adatlapján, mert azok mélyen hallgatni szoktak erről a viselkedésről. Maradnak a független tesztelők, és review-k.

Általában az olyan töltők érintettek, amik az USB-PD szabvány szerinti fix feszültségértékek (5V, 9V, 12V, 15V, 20V, és fölötte az extended értékek 48V-ig) mellett támogatják a dinamikus PPS (Programmable Power Supply) protokollt is.

Miért/mikor gond ez? Leginkább akkor, ha 1 ilyen multiport töltőt üzemszerűen használni akarnál pl. időszakos telefontöltögetés mellett olyan eszközzel is, aminek nincs beépített akkuja és a töltőt használná tápegységként. Pl egy Raspberry ilyen esetben simán újraindul a táp elvétele miatt.

Rákötsz egy külső (eltávolítható) drive-ot windows-ra, a windows search azonnal elkezdi indexelni kérdés nélkül. A root directory szinten a properties-ben hiába veszed ki a pipát az "Allow files on this drive to have contents indexed in addition to file properties" elől, akkor is csámcsog csatlakozás után a searchindexer processz a drájvon, mérettől függően egész sokáig. Sok esetben a leválasztást is aktivan blokkolja, hacsak le nem stoppolod a service-t, vagy ki nem lövöd a processzt. Ami utóbbi meg ugye szétcseszheti az indexet a többi drájvon. Illetve az előbbinél meg mi van ha attól még a többi drive-on használnád az indexelést?

Elvileg ha az indexing services beállításaiban felveszed a külső drive-ot mint exclude, akkor nem fogja indexelni. De kozmetikai működés, h. ez az exception csak akkor látszik, ha a drive ténylegesen csatlakoztatva is van a rendszerhez. Ha lehúzod, eltűnik az UI-ról az exception listából. De állítólag attól még ott van az, csak az idióta UI nem mutatja.

Viszont ezt lehet megcsinálni minden windows OS-nél, amire rácsatlakoztatod ezt a külső drive-ot. Ha több gépről is pl. 1 ilyenre csinálsz lokális backup-ot, akkor mindegyik gépen fel kell venni ezt az exception-t.

Windows-ban a diskpart tud volume-okat, v. teljes disk-et is read-only állapotúvá állítani.

https://superuser.com/questions/491756/what-do-the-readonly-attributes-…

----

Attributes DISK [set | clear] READONLY stores the attribute in the Windows registry, not on the physical disk. This means it is only valid for the currenlty running Windows installation and it won't be carried, set and enforced on other OSes.

Attributes VOLUME [set | clear] READONLY stores the attribute on the physical disk. This means it WILL be carried, set and enforced also onto other OSes, including Linux (I had to manually remount the disk in rw mode, plus it didn't touched the stored attribute, so I had to manually remove it in Windows).

BE CAREFUL with administrative access, though:

while the DISK attribute prevents ALL writes on the entire disk (i.e. both the volume(s) filesystem and the partition table), the VOLUME attribute prevents writing ONLY to the volume(s) filesystem, leaving the partition table STILL writable (i.e. you can still delete a read-only volume).