URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 135814
[ Назад ]

Исходное сообщение
"Для ядра Linux предложен драйвер с реализацией режима NVMe PCI Endpoint"

Отправлено opennews , 20-Янв-25 16:52 
Компания Western Digital разработала для ядра Linux  драйвер с реализацией NVMe PCI Endpoint Function Target. При наличии контроллера PCIe, поддерживающего режим endpoint, драйвер позволяет системе под управлением Linux изображать из себя контроллер PCI NVMe, который для других систем будет выглядеть как накопитель с интерфейсом NVMe...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62588


Содержание

Сообщения в этом обсуждении
"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 16:52 
А ваш хвалёный мак такое поддерживает? Нет? А туда же критиковать что на линуксе нет дров.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 17:05 
С каких это пор мак - хвалёный? Он же днищем всегда был закрытым и кривым. Он даже линукс не умеет, в отличие от винды.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 17:06 
С тех пор как первый хомячек купивший в тридорого мак стал доказывать какой он не немамонт.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 12:06 
Просто справедливости ради, в Windows теперь ликукс в ВМ-ке. В мвке тоже самое легко ставится. См. Rancher Desktop.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено G0Dzilla , 20-Янв-25 17:59 
Вас в детстве маководы унижали? Почему Вы первым комментом накинулись на систему, которой даже не пользуетесь?

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 18:53 
> Вас в детстве маководы унижали? Почему Вы первым комментом накинулись
> на систему, которой даже не пользуетесь?

И не только в детстве. Попробуй ипад купить. И тут ты узнаешь что без благославления белого человека - он вообще не работает!


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 20:01 
Потому что на маке такие драйвера без благословения самого Тима Кука невозможны.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено scriptkiddis , 20-Янв-25 22:03 
Ну и где он не прав?

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Соль земли , 21-Янв-25 09:53 
Сам факт того, что кто-то покупает дорогой мусор - унижает всех вокруг. Это же преступление против здравого смысла, логики и рассудка.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 20:07 
Надеюсь ты угораешь. В макбуках этот режим есть с 1991 года.

https://en.wikipedia.org/wiki/Target_Disk_Mode


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 20:40 
Нунифигасебе. Прикольно.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 21:42 
> Надеюсь ты угораешь. В макбуках этот режим есть с 1991 года.

Поздравлю, граджанин соврамши. В 1991 году - PCIe совершенно точно не было. Не говоря уж про NVMe. Там простой PCI то - спасибо если уже вылупился.

А если валить все технологии хранения в кучу - так линух умел диск косплеить дюжиной разных способов. На одноплатнике например можно usb mass storage откосплеить. Будет такая вот флешка, с Linux на борту. А NVMe интересен - тем что эффективная штука, оптимизирован на скорость.


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 21:55 
> В макбуках этот режим есть с 1991 года.

опять какая-то альтернативная интерпретация новостей, этот режим у макбуков
1) в загрузчике
2) где вы там увидели pcie ep


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено зфс , 21-Янв-25 12:32 
Так на линуксе все драйверы есть уже лет 10-15.
Вы с бсд перепутали.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 17:08 
Но зачем? смысл NVME же в скорости. Никакая программная реализация за FPGA и ASICами не угонится.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 17:17 
Ну почему сразу так критично. Как вариант соединить два хоста - из второго сделать убер (не убиваемый, не ограниченный TWB) накопитель поверх tmpfs второй машины, для кешей например. Очень годно. ddr3 хватит - она дюже дешевая сейчас. За счет pcie интерфейса не надо заморачиваться дорогими nic на несколько GB и TB1-4 интерфейсы не нужны. Профит!

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 15:06 
> из второго сделать убер (не убиваемый, не ограниченный TWB) накопитель поверх tmpfs второй машины, для кешей например. Очень годно. ddr3 хватит

проще на хосте память проапгрейдить чем здоровенный гроб в нагрузку с потреблением утюга,  смешным объёмом памяти и оверхедом от задержек pcie.


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 16:38 
> проще на хосте память проапгрейдить чем здоровенный гроб в нагрузку с потреблением
> утюга,  смешным объёмом памяти и оверхедом от задержек pcie.

Назвать однокристальный SoC типа копеечного рокчипа здоровым утюгом могут только эксперты опеннета :)


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 17:29 
> Назвать однокристальный SoC типа копеечного рокчипа здоровым утюгом могут только эксперты опеннета :)

даже не знаю зачем ты его так называешь, но шарить копеечную память через pcie это какой-то идиотизм - просто купи одноплатник с нужным объёмом чем два с маленьким, это точно будет дешевле и точно быстрей работает и потребляет меньше


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 17:39 
> просто купи одноплатник с нужным объёмом чем два с маленьким

или если ты хотел расширить память пека за счёт одноплатника - советую посмотреть сколько стоят одноплатнике на рокчипах rk3588 - за эти деньги можно ещё один пека с бОльшим объёмом памяти купить


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Кирилл , 22-Янв-25 07:39 
Про ограниченное количество планок оперативки на матери слышал? Возможно им уже есть чем заняться, а нужно больше всего.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 23-Янв-25 11:39 
> Про ограниченное количество планок оперативки на матери слышал?

а ты про ограничение контроллеров памяти слышал ? rk3588 больше 32Г не поддерживает, назови хоть одну причину чтобы за 25к покупать это а не 1Т nvme pcie5 корпоративного уровня


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Кирилл , 25-Янв-25 12:58 
> а ты про ограничение контроллеров памяти слышал ? rk3588 больше 32Г не
> поддерживает, назови хоть одну причину чтобы за 25к покупать это а
> не 1Т nvme pcie5 корпоративного уровня

У меня есть смутное подозрение, что корпоративый nvme pcie5 на 1Т стоит дороже сданного на барахолку сервера с поддержкой 1Тб ддр3.


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Кирилл , 25-Янв-25 13:00 
> а ты про ограничение контроллеров памяти слышал ? rk3588 больше 32Г не
> поддерживает, назови хоть одну причину чтобы за 25к покупать это а
> не 1Т nvme pcie5 корпоративного уровня

А ещё могут найтись задачи, для которых чисто по ресурсу подойдёт только Оптан. Сколько там стоит новый терабайтный Оптан?


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 17:30 
2.8GB/s для PCIe3.0 вполне адекватный результат. Не на порядки разница.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено letsmac , 20-Янв-25 17:34 
В оригинале есть зачем:

The NVMe PCI endpoint target driver is not intended for production use.
It is a tool for learning NVMe, exploring existing features and testing
implementations of new NVMe features.


Это просто для отладки.

RK3588 в последнее время прямо стал чипом для всего. От NAS до EDGE И NVME endpoint.


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 18:38 
>Это просто для отладки.

Всё! Расходимся, тред закрываем.


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 18:50 
Затем, что никому не хочется ждать несколько лет, пока появятся идеальные FPGA и ASIC реализации, для 99% задач достаточно просто «good enough», и это оно. Затем, что это обычный цикл развития индустрии, когда процессоры общего назначения догоняют по производительности асики предыдущих поколений и любые идеи можно реализовать в софте быстро, качественно и универсально, пока не упрутся в производительность, после чего начинают оптимизировать с другого конца при помощи асиков и fpga. Затем, что обычное железо с полки куда проще и дешевле в эксплуатации любого специализированного. Достаточно причин?

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 01:32 
> Затем, что это обычный цикл развития индустрии, когда процессоры общего назначения догоняют по производительности асики предыдущих поколений и любые идеи можно реализовать в софте быстро, качественно и универсально

настолько догоняют что интел почти банкрот, а для GPU процессоры общего назначения к которым все привыкли скоро будут не нужны, ну останутся в крестьянских мобильниках чтобы к облаку присосаться


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено maximnik0 , 21-Янв-25 16:35 
У Интела эпик файл по другой причине.Они выпустили до хрена процессоров какой-то новой серии без должной проверки- а потом выяснилось (после первых жалоб) что процессоры дохнут в течение 2 месяцев.Сперва подозревали перегрев,выпустили падчи Биос,поменьше стало но все равно дохнут.В общем что то в технологии упростили и окислялись дорожки.А это эпик файл ,законы США и Европы однозначно говорят что это проблема производителя и он обязан поменять дефектные чипы.А представляете их уже и на ноутбуках напояли - какой масштаб бездны,в общем пачками менеджеры полетели,а толку то .Точное количество процессоров не говорят,но по финансам видно что дела плохие.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 16:41 
> У Интела эпик файл по другой причине.Они выпустили до хрена процессоров какой-то
> новой серии без должной проверки- а потом выяснилось (после первых жалоб)
> что процессоры дохнут в течение 2 месяцев.Сперва подозревали перегрев,выпустили падчи
> Биос,поменьше стало но все равно дохнут.В общем что то в технологии
> упростили и окислялись дорожки.

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


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 18:31 
> У Интела эпик файл по другой причине.

да интел тут просто к слову пришёлся - процессоры общего назначения в закат уходят

https://www.forbes.ru/investicii/524829-nvidia-stala-pervoj-...

https://www.ixbt.com/news/2025/01/11/imagination-technology-...


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 18:51 
> Но зачем? смысл NVME же в скорости. Никакая программная реализация за FPGA и ASICами не угонится.

Вообще, вы господа зажрались: 2.8 гигабайта в секунду - даст мастеркласс В РАЗЫ любому SATA SSD например.

То-есть теперь можно из одноплатничка на линухе запилить себе SSDшник в наглую - и он порвет в разы как минимум любой SATA девайс. В основном все упрется, имхо, в том что у таких SoC нет дофига каналов NAND'а чтоб туде _быстро_ записи фигачить.


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 19:44 
Зачем что-то рвать? Глупо сравнивать с сата. Ssd pcie/nvme и так гигабайт-два вытягивают. Гдето есть у меня парочка u2 - надо глянуть сколько они вытянут.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 21:55 
> Зачем что-то рвать? Глупо сравнивать с сата. Ssd pcie/nvme и так
> гигабайт-два вытягивают. Гдето есть у меня парочка u2 - надо глянуть
> сколько они вытянут.

Ну как бы вон то - у владельца технологии, их фирмваре их confidential proprietary. А тут, вот, из линуха прямо такое же - и даже не супертормоз. Так что интересным технологиям - быть.

Конечно такой процык под косплей SSD это весьма пафосно, он так то и с таким обвесом и весь небольшой лаптоп скосплеит с таким обвесом, но идея - прикольная.


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено chdlb , 20-Янв-25 23:28 
что ты лапочишь? все преимущество в латенси, а оно будет как раз тухлым, сложно сравнивать но точно не меньше чем у SATA, тем более что это одноплатник )))


> 2.8 гигабайта в секунду - даст мастеркласс В РАЗЫ любому SATA SSD например.

твоя линейная скорость никому не интересна, а наче добро пожаловать в мир RAID0 на HDD

а еще и стоить это будет космос в сравнении даже с каким-нибудь IB-QDR QSFP+

а на вторичке так вообще, хоть кушай задом


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 11:02 
IB FDR уже стоит как грязь на рынке. Mellanox даже разлочил 56G eth бесплатно в своих свичах.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 16:44 
> IB FDR уже стоит как грязь на рынке. Mellanox даже разлочил 56G
> eth бесплатно в своих свичах.

Угу, только в обычном компе - IB вообще совсем некуда подцеплять.

А PCIe что, он везде есть. От мизерных одноплатников до суперсерверов. Сразу. Бесплатно. Как встроенная фича процов, SoC и чипсетов. Этим он и крут. Одна из причин стремительного взлета NVMe как спеков. Это работает - везде. Без особых приседаний и затрат. В отличие от.


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 11:05 
ну почему только raid0.. я тут собирал Raid0 поверх 3 raid5... правда SAS 15k - тоже 3-4 Gb/s давало с 24 дисков. И это не raw, а xfs write. чтение побыстрее было.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 15:12 
> твоя линейная скорость никому не интересна

Причем тут вообще линейная скорость носителя? Это скорость ИНТЕРФЕЙСА (скорость обмена). И она близка к теоретическому максимуму 4GB/s (а может даже и 3.5-3.8Gb/s, если всякий служебный overhead оценить). Latency большим не будет, за миллисекунды linux прочухается (там всё равно очередь запросов идёт).

Если речь о том, что оранж будет шарить SD-карту аж на скорости 2.8GB/s... ну это уже другой вопрос... может и что-нибудь другое шарить.


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено chdlb , 22-Янв-25 10:19 
>> твоя линейная скорость никому не интересна
> Причем тут вообще линейная скорость носителя? Это скорость ИНТЕРФЕЙСА (скорость обмена).
> И она близка к теоретическому максимуму 4GB/s (а может даже и
> 3.5-3.8Gb/s, если всякий служебный overhead оценить). Latency большим не будет, за
> миллисекунды linux прочухается (там всё равно очередь запросов идёт).
> Если речь о том, что оранж будет шарить SD-карту аж на скорости
> 2.8GB/s... ну это уже другой вопрос... может и что-нибудь другое шарить.

SAS-3, SAS-4, SAS-5 в помощь
даже уже устаревающий SAS-3, 8644 - 4x12 gbit/s, аж целых 6 GB/s )))

это раз

два: где в словосочетании "даст мастеркласс В РАЗЫ любому SATA SSD например." написано про интерфейс?

ладно забей, это ж ни о чем


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 16:36 
> твоя линейная скорость никому не интересна, а наче добро пожаловать в мир RAID0 на HDD

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

> а еще и стоить это будет космос в сравнении даже с каким-нибудь IB-QDR QSFP+

Что будет стоить как космос? Кусочек текстолита с попсовым рокчипом? При таком раскладе тут же вылезет штук пять тех кто его развел на таком же кусочке - но в разы дешевле :)

> а на вторичке так вообще, хоть кушай задом

Что такое вторичка? Вторсырье чтоли? БУшные SSD и HDD - такое себе. Тем более одно дело если это мутная проприетарная фирмварь, и другое - если это тот же линух.

Грубо говоря, лично я буду испытывать намного больше доверия своей "фирмвари SSD" на основе линуха чтоб бутануть мне основной комп, с DMA-capable девайса, нежели непонятной блобвари без сорцов. Да и просто прикольно, грузить Linux при помощи - Linux :)


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 16:46 
> тухлым, сложно сравнивать но точно не меньше чем у SATA, тем
> более что это одноплатник )))

На обычных компах SATA обычно за контроллером over PCIe - и латенсей там и та, и другая. И уж тем более SATA никогда не сделает 2.8 гига в секунду. Хоть как.


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Ivan_83 , 20-Янв-25 22:25 
Затем что потребности бывают сильно разными.
Скорость там вроде на уровне SATA если не выше, у меня до сих пор механически SATA диски для хранения больших данных и мне скорости в принципе хватает.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 09:19 
Вот и я о том же. Нафига NVME, если есть сата? Чтобы геммороя отхватить чисто на физическои интерфейсе?

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 16:48 
> Вот и я о том же. Нафига NVME, если есть сата? Чтобы
> геммороя отхватить чисто на физическои интерфейсе?

Какой геморрой с PCIe как физическим интерфейсом? oO

На физическом уровне они даже так то даже более-менее похожи - и то и другое это скоростные диффпары с небольшим размахом сигнала. Но в деталях ессно отличия. И PCIe куда как масштабируемее по скорости.


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 19:08 
Чего то не нашел как одна система к другому физически коннектится. Через usb что-ли? Или в слот m2 (что за адаптер? Прямо в pcie слот (опчть таки - как). Не понимаю

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 19:41 
По логике через PCIe. Через все что может сие изобразить.

Хоть между 2 SoC на 1 плате дорожки прокинуть, хоть как карту PCIe или вон, закосить под накопитель m2 - но придется придумать как спихивать тепло и куда шустрого флеша в этом всем пристроить, null_blk такой себе стораж :)


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 20:05 
Гибкий шлейф сделай и выводи куда твоей душе угодно.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено letsmac , 20-Янв-25 20:28 
Физически  rk3588 - SOC с 4х pcie 3 + 3x pcie 2. Как хочешь, так и разводи.

Rk35хх очень интересные процы.  Collabora обещает полную поддержку вроде к 6.14.

Шита тут - https://www.rock-chips.com/uploads/pdf/2022.8.26/192/RK3588&...


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 21:52 
> Rk35хх очень интересные процы.  Collabora обещает полную поддержку вроде к 6.14.
> Шита тут - https://www.rock-chips.com/uploads/pdf/2022.8.26/192/RK3588&...

Нафиченый процик, из него даже мини-лаптопчик напрашивается, все "взрослые" интерфейсы в наличии, как и все мобилочные. Хардварные декодеры/энкодеры, 8 ядер, .... красота :). Даже 2 GigE затолкали.


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 09:58 
Дык бери Radxa ROCK pi 5B RK3588 и делай на ней что хочешь

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 20:28 
Попробуй NVME over IP, например.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено ага , 24-Янв-25 01:50 
Через oculink адаптеры, как вариант, не понятно только нахрен это нужно

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено commiethebeastie , 20-Янв-25 21:21 
Завезите лучше raw access.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 21:53 
> Завезите лучше raw access.

Raw access к чему тебе надо и в каком виде?


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 20-Янв-25 22:53 
Может, для объединения материнских плат посредством PCI-E в кластер?

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 04:33 
По токам не вытянет. Паразитную емкость проводов на таких частотах перезаряжать стандартный pcie не потянет. Скорей всего и наводки окажутся сильно выше того что он может переварить. Нужен мощный выходной каскад чтобы длина провода превышала хотя бы полметра.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 15:41 
Всё верно, но на практике куча райзеров в интернетах. Прям полметра может и не вытянет, но порядка 20см навалом.

Есть и порядка метра (на usb3-кабелях). Что там с качеством (завалом фронтов, гонками, количеством ошибок) - хз. Вряд ли это будет pci express 5. Предложений таких много, видимо кому-то нужны и видимо худо-бедно они работают.


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 16:59 
> По токам не вытянет. Паразитную емкость проводов на таких частотах
> перезаряжать стандартный pcie не потянет.

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

Это правда вызывает особенности. Требуется кодирование которое будет убирать DC-bias чтобы заряд - в проводе не накапливался. И всякие вещи типа 8-to-10 в SATA и прочие более продвинутые - оно. Более того - становится важным волновое сопротивление "transmission line" и правильная терминация оной, дабы не было отражений. Также критично совпадение длин дорожек. Поэтому развести подобный скоростной интерфейс - не для слабых духом. Если вы просто наобум отрисуете дорожки - есть высокий шанс что это не заработает, или заработает криво. Вам потребуется посчитать параметры дорожек под волновое сопротивление, а может и текстолит особо качественный, с контролем параметров, дабы волновое сопротивление не сильно отличалось от того что вы планировали. У дешевого текстолита - разброс от партии к партии, и можно и обломаться.

А серьезные занятия такими вещами, особенно в топовых режимах - заставят вас хотеть экзотичный дорогой шмот, типа анлизаторов eye diagram линка. Это конечно не валяется на дороге. И стоит дофига - это навернутый и нишевой шмот.

> Скорей всего и наводки окажутся сильно выше того что он может переварить.

Если скоростную дифпару рисовать наобум и ламой - что угодно может быть. Но вообще не боги горшки обжигают. И нарисовать дифпару грамотно - в пределах сил человеческих.

> Нужен мощный выходной каскад чтобы длина провода превышала хотя бы полметра.

Это совсем не так работает. Но вы даже это не понимаете.


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 20:28 
Дорогой, вы таки посмотрите на досуге что такое импеданс (волновое сопротивление) и вопросы насчет емкости (распределенной) немного отпадут. На эквивалентную схему немного повтыкайте, рисунки обычно проще воспринимаются.

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


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 22-Янв-25 01:38 
> Дорогой, вы таки посмотрите на досуге что такое импеданс (волновое сопротивление) и
> вопросы насчет емкости (распределенной) немного отпадут. На эквивалентную схему немного
> повтыкайте, рисунки обычно проще воспринимаются.

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

Внезапно, на высокой частоте - абсолютно валидно что импульс в проводе например, короче провода. Это "transmission line". Допустим телевизионный коаксиал многократно длиннее дециметровых волн, но это не мешает ему передавать сигнал. И, конечно, никто целиком эту многометровую чушку не перезаряжает. Все возмущения "локальны" и не превышают длину волны. У SATA, так, для сведения - twinax - дифференциальная версия идеи. Но transmission line с правильным волновым сопротивлением - можно делать и из дорожек печатки. Даже у кучи параллельных проводов - некое волновое сопротивление есть, особенно с gnd между ними, и оно может быть достаточно близко к нужному.

> От того что выходной каскад дифференциальная пара суть сильно не меняется -
> нужны токи, которых стандартному контроллеру pcie не по плечу.

Как я уже сказал - при такой технологии вообще нет требования перезаряжать всю длину длинного кабеля. И кодирование без DC bias делается - специально чтобы заряд в линии не накапливался "вдолгую".

Проблема там скорее будет - с затуханием сигнала. На высокой частоте потери очень злые. И в какой-то момент ресивер просто перестанет видеть достаточный размах.

> Волновое (терминальное) сопротивление известно, требуемый размах сигнала на
> приемнике тоже - вот и прикидывайте какой там  импульс тока для этого нужен

Трансивер PCIe by design делает такой импульс. Просто по спекам PCIe. Иначе это вообще работать не будет. Ни на каком расстоянии.

Длина линии в это вообще не входит как таковая. Но вот потери на энной дистанции могут внести свои коррективы. У трансивера минимальный размах - больше чем минимальная чувствительность ресивера, но если линия длинная и сигнал ослаб - вот тут уже ой. При достаточном ослаблении это перестанет надежно работать. А вот ослабление конечно же пропорционально длине transmission line, чудес не бывает. Это не значит что трансивер что-то не выдал. Это значит что серьезный процент сигнала про@#$%лся по пути.


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 06:29 
Endpoint встречаю этот термин в разных местах. И каждый раз в зависимости от контекста это разные вещи. Объясните смысл.

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 08:15 
> Объясните смысл.

конечная точка


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено _ , 22-Янв-25 18:28 
Гениально!
;-)

"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 09:55 
Это часто встречается в асимметричных шинах (с мастером и/или арбитражем). В таком случае, есть кто-то главный на шине, остальные слушают и повинутся (master/slave spi). Еще  пример - usb хост, в противовес всем остальным usb девайсам (причем эндпойнтов может быть несколько на девайс). Некоторые девайсы могут перенять роль хоста (otg).

на pci шине аналогично - есть контроллер pci (чипсет/процессор), который заведует всем этим хозяйством, остальные девайсы - эндпойнты.

вот как-то так. эндпойнтов, встроенных в железо как интерфейс - как грязи. вот программный - это уже интересней. для usb это есть уже давно, я так usb камеру эмулировал лет 15 назад.


"Для ядра Linux предложен драйвер с реализацией режима NVMe P..."
Отправлено Аноним , 21-Янв-25 17:04 
> Endpoint встречаю этот термин в разных местах. И каждый раз в зависимости
> от контекста это разные вещи. Объясните смысл.

Это и правда - используется несколько по разному, в звисисмости от контекста. В самом простом виде - это конечная точка назначения. Скажем в TCP/IP можно считать что ip:port - это конечная точка назнаячения пакета, значит тоже - endpoint.

У других интерфейсов и протоколов понятия могут отличаться в деталях но общая идея остается.