Pro:



Evo:

http://www.anandtech.com/show/10754/sam ... ssd-review
http://www.anandtech.com/show/10833/the ... 1tb-review
960 EVO 250GB има 13GB 1500 MB/s кеш. И да си призная чесно не се сещам от къде мога да намеря 13GB за 8.7 секунди за му да напълня кеша.
Вариянта от 1ТБ има 42ГБ кеш, който се пълни със скорост 1900 MB/s, а се празни с 1200 MB/s. Разликата е 700 MB/s за да напълни 42ГБ ще му трябват 60 секунди. За тези 60 секунди ще запише 114ГБ данни ... някой да има на идея от къде могат да дойдат 114ГБ за една минута при работа като потребител?

Нотпад, сръчни пръсти...

Това UP to 3200 малко ме съмнява, както видяхме от сметкит на Дедо даже май е извън спецификацията на PCI х4 дори Gen.3 да е е много близко до теоретичният максимум.

би трябвало да поддържа 3.2ГБпс, иначе ще рано или късно ще стане като VW в хамериката и все някой ще се разпищи

Delivering up to 32 Gb/s data transfer speed per connector, the dual M.2 provides an ideal storage solution as it also supports RAID modes.

на дърто дъно с нейтив 4х М2 и 950Pro преди година имах 2274/949 МБ/с четене запис. Преди 2 дена ъпдейтнах биоса и падна на 798/835МБ/с абсолютно същата конфигурация. Ще трябва да погледна какво се е сбозило

Въпроса е всички тия тестове как мерят, и дали изобщо са предвидили че работят на SSD закачено на PCI. Нямам време, иначе бих изгубил да направя някои реални тестове да видим дали записват всичко за времето за което споменават. Като по млад ми беше хоби да се занимавам с бенчмаркове и овърклок, много често хващах че бенчмарковете които се правеха и пускаха без значнеие дали от производители или "независими" са доста .... ако не заблуждаващи, то при много странни, лиспващи в нормалната експлоатация, условия.

аз продължавам да твърдя, че VW не са направили нищо погрешно от инженерна гледна точка.
има стандарт, който казва:
(1) поставя се автомобила при знайни условия (хоризонтално, не се върти волана, не се пускат чистачките, никой не пали цигара с електрическата запалка, при еди каква си влажност, състав на въздуха, температура и налягане)
(2) минават се х минути при натоварване у
(3) повтаря се (2) при различни стойности на х и у
накрая на теста емисиите трябва да не надвишават (табличка)
всички тестове в реални условия не са релевантни към табличката, защото не е спазено (1)
как ще го изтълкуват в съда оная пасмина юристи е друг въпрос

---

не мога да споделям много информация за TLC флешове, но:
- интерфейса е SSTL18 (данни)
- адреси и команди са по един фронт
- максималните скорости на дейта бъса с много уговорки при DDR2 са 333MT/s при четене (от кеша) и 200MT/s при запис (пак в кеша)
- асинхронните операции са 50MT/s
- четене на страница в кеша е стотици us, запис на кеша е десетки ms (условно 100 пъти разлика)
- дейта бъса е 8 бита
- Endurance: 1000 PROGRAM/ERASE cycles (пак с условия)
- реално DDR бърста за данни е дълъг 1 страница.

за DDR памети бърста е значително по-къс (байтове).

теста силно зависи от архитектурата на процесора, нивата на кешовете, самия кеш-предсказател (който често е оптимизиран за код, а не за данни), дали PCI бъса е директно към процесора или е през суич и как всички тия кешове се натамъняват един към друг. зависи и от честотата с която процесора може да изкопира данни от един адрес в паметта към друг, като двете памети най-вероятно са от различно поколение и архитектура, и най-малкото са на различни честоти. а ако върви и ОС, почва да зависи и колко кора са и за колко време ОС е склонна да остави копиращия кор да запуши основната памет или да спре целия ОС.

това с 42GB кеш силно ме съмнява, трябва да са доста DDR3 чипове, които не знам дали се виждат по SSD платката?

та дефиницията "UP TO" не е подвеждаща точно в този смисъл. в реално желязо резултата ще е много желязо-зависим

аз не казвам, че SSD са бавни, просто не се захласвайте особено по числата в листовките.

бъркаш RAM с SLC Cache

всеки кеш е вид рам

та какво е SLC Cache и къде живее?

Хм глупост някаква, според мен няма нищо общо със скоростта, идеята най-вероятно е да спестят писането. SLC е еднобитов нанд, две състояния 1/0, пази един бит, живее много. Другите клетки сигурно с MLC или TLC, тов апоследното пази по 3 бита, да но живота му е малък. Та най-вероятно кешират в този SLC с идеята днните с кратък живот да не стигат до TLC, като се наоълнено SLC го флъшвали към TLC-то ... ала бала, трикове да изкарат малко повече цикли, отново зависи какво пиешеш, алабализми най-общо. Та тия 42 Gb може би са такъв SLC кеш, демек 42 gb които са с по-дълъг живот.

Диска ми даваше 900/600MB/s, закачен на PCIe 2.0 x2, не директно към процесора, а към чипсета. След закачане на PCIe 3.0 x4 отиващи директно в процесора, започна да дава 1800/900, което е доволно близо до декларираното от производителя. Тоест от моята камбанария нямам повод да се съмнявам в декларираното за новите модели, поне докато не се сдобия с такъв и тествам лично.

...ама ще се сдобия единствено ако 256-цата ми омалее, защото както споменах общото впечатление от системата при средностатистическа всекидневна работа не забелязвам да се е променило толкова значимо при почти двойно увеличение на скоростта на диска, че да си струва инвестицията в нещо по-бързо, само заради скоростта му. Няма шанс скоро да започна да обработвам 4К видео или нещо от сорта, та да ползвам въпросната скорост пълноценно.

...от друга страна нищо чудно в скоро време да мога да тествам такова по служебна линия. Пускаме WEB продукт, имаме към 2000 клиента и трябва да се мисли за сървъри, сториджи и прочие полюции, че според изчисленията сметката никак не се връзва ако наемаме сървъри някъде.

Ами помисли за сървъра, кой е по-добрият вариант. Не е лошо да имаш твой но трябва да е на локейшън,ако тръгнеш при теб да докарваш нужната свързаност с висок ъптайм си е зор работа дори е в места с добра свързаност, трябват ти поне 3-ма доставчика.
2000 клиента не са много, зависи разбира се какво ще правят, въпроса отива по скоро към това как е написано това което ще търкаляте, едва ли има универсално решение.
За SSD-то, това че не усещаш разлика не е случайно, и с 4 k да работиш пак няма да усетиш кой знае каква разлика, точно защото тия скорости са доста .... фиктивни, да постига ги но са неизползваеми реално. Ако ще правя web съръв който трябва да държи и на трафик към масива аз бих заложил на SAS решение, няма как да правиш нещо с PCIе SSD-та, трябва си истински RAID, там много внимавай какъв контролер ще избереш.

Всеки клиент е със собствена база данни, SQL Server, MySQL, или Postgresql. Понеже нещото е HR и Payroll, вътре има между 10 и примерно 3000-4000 слижутеля, за всеки от които се пази всичко като документи за текуща и предходна година, а някъде се държат и архиви за по-назад.

Сега, те всичките ще минат на това доста напред във времето, отделно дето доста няма да са на наш хостинг, ами ще се деплойва на техен сървър. Ама да речем половната ще са при нас, предимно дребните. Абе смятай го примерно по гигабайт максимум на клиент, kато база данни, като болшинството ще е 200-300MB на клиент и по-малко. Трафик свързан със самия сайт няма кой-знае какъв, и е на малки парчета, ама всеки месец има кажи-речи пълно претакане на базите данни и допълване с нови данни. Тя практиката ще си покаже кое-що. В началото със сигурност ще сме на нает сървър, после ще го мислим като видим как се справя.

С 2 думи тепърва ще настъпваме мотиките, защото с такива решения не съм си имал работа. Софтуера е писан да е максимално гъвкав по отношение на инфраструктура и е правен с мисълта да може да се модва лесно по отношение на това, поне доколкото ми позволява пипето към момента.

Хммм, мотиката е е с дебела дръжка. 2000 клиента с отделни бази данни на един сървър може да се окаже проблем. Postgresql май е най-добре като натоварване но това са бая бази данни. В случая не мисля че точно сториджа ще е грижа, все пак данните не се предполага да са много и тежки, поне така си мисля де. Може от към CPU да имаш грижа, зависи какви заявки и колко клиента ще пуснат едновременно. Според мен, не че съм голям спец по базите, най-важно са заявките и структурата на базата, там така може да се омаже че и с една база да му се стъжни на сървърчето, говоря от личен опит.

Правил съм го да може да работи и на "ферми", тоест откъм WEB сървъра като започне да се задъхва - добавя се сървър и толкоз. Откъм базите данни ми е малко мътна, но принципно може да се конфигурира всеки клиент да е на различен инстанс или сървър за базите данни. Заявките до базите съм ги ограничил до крайност, сторед процедури няма, няма и сложни манилулации. Единствено при въпросното месечно преджуркване има по-дълги транзишъни, ама пък тях съм ги ограничил като количество едновременно изпълняващи се още на ниво WEB приложение. Практически нещата, дето изискват CPU ресурс са на 99% в WEB частта, а там ще може да работи във ферма и да се разширява колкото е нужно. В бозите само се чете и пише, тоест искат се бързи дискове и много RAM, не толкова бързи CPU-та.

...това на прима виста де. Със сигурност не съм предвидил всичко. Докато не го пуснеш в реални условия, няма и как.